400 Bad Request Error Through a Proxy

What the error means

The 400 code means the server cannot or will not process the request because of an error on the client side: invalid syntax, a broken message structure, invalid headers. That is how the HTTP standard (RFC 9110) and the MDN reference describe it.

Through a proxy, this code can be sent by the proxy itself. In the Prokso code table, 400 means the proxy received a request in the wrong format: most often the program connects to the wrong port or uses the wrong protocol.

If the proxy accepted the request and passed it on, the 400 comes from the site. Then the proxy has nothing to do with it: the site did not like the request itself, meaning the URL, headers, cookies or body.

Causes

• The protocol does not match the port. Port 823 accepts HTTP, port 824 accepts SOCKS5. If a program speaks SOCKS5 to port 823, the proxy receives data it cannot understand.
• The proxy line is corrupted. An extra space, quotes, a password cut off or the parts in the wrong order: the program builds a request the proxy cannot parse.
• Headers or cookies are too large. Servers limit header size. For example, nginx answers 400 when a single header does not fit into the allocated buffer.
• The URL is encoded incorrectly. Spaces, non-Latin characters or special characters in the URL without encoding, doubled “?” and “&” signs.
• The body does not match the headers. Content-Type says JSON, but a form is sent; Content-Length does not match the actual size.

How to fix it

1. Check the port and protocol pair: 823 for HTTP, 824 for SOCKS5, ports 10000-20000 are a sticky IP for both protocols. More about protocols on the SOCKS5 proxies page.
2. Copy the proxy line from the dashboard again and, if needed, convert it to the required format in the proxy format converter.
3. If the error is shown by the browser on a specific site, clear the cookies for that site and open the page again.
4. In a script, encode the URL parameters with the library's built-in tools instead of gluing the string together by hand.
5. Compare the headers and body with what the site or its API expects: content type, encoding, required fields.

How to check that it works

Check the line in the proxy checker. If the proxy works there and 400 comes from only one site, the cause is in the request to that site, not in the connection.

Two-minute diagnosis

First paste the line into the proxy checker. If the proxy works there, the cause is in your app or its settings. If not, test the line from a terminal:

curl -v -x "http://USERNAME:PASSWORD@gw.prokso.com:823" https://api.ipify.org

• A < HTTP/1.1 407 line right after CONNECT means the proxy answered. The name after the code, for example NO_USER, points to the cause.
• The proxy answered CONNECT with 200 and then another code arrived - the proxy works, and that answer came from the website.
• No answer at all, only a timeout - the connection never reached the proxy: check the host, port and network.