"400 Target website error" and one observation of a pool

A 400 Target website error from a proxy is the gateway telling you that the exit it picked could not reach the site you asked for. On a residential pool that happens some of the time, and the next attempt on another exit is usually fine. So one such answer says something about one exit, not about the proxy, and a checker that marks the proxy red on it has taken a single observation of a third party as evidence.

That is a mistake we had already made once, with detectors, and the proxy check in Mosaic is written around not making it a second time.

What a proxy 400 Target website error is saying

The status comes from the proxy, not from the website. A residential gateway is a front door to a pool of other people's connections. You authenticate at the gateway, it hands your request to an exit somewhere in the pool, and the exit makes the connection to the site. When that last hop fails, the gateway still has to answer you, and some gateways answer with a 400 and a short reason such as "Target website error".

That wording is the seller's, not a standard. Other gateways report the same kind of failure as a 504, which is what the seller in the story below sent. What they share is the cause: the exit you got was bad, briefly or for good, and the gateway itself is working, because it answered.

Why one bad answer is not a broken proxy

Our proxy check is in src/main/proxy/check.ts, and its header says the same thing in a sentence: a residential pool will hand out a dead exit some of the time, and the next attempt is fine. Marking the proxy red on the first of those is the mistake this project already documented for detectors.

The detector version of the lesson is that live sites disagree with themselves. We once ran an untouched Google Chrome through Pixelscan's fingerprint check twenty times on one Mac and got "Masking detected" three times, which is in Pixelscan calling stock Chrome masked 3 times in 20. A verdict that comes and goes is neither a pass nor a fail. A proxy pool is the same kind of third party. It does not answer the same way twice, and one answer is one sample.

So a transport failure in our check is retried, up to three attempts, and the result says how many it took. A check that passed on its third try shows attempts: 3. We do not hide that, because a proxy that needs three tries every time is worth knowing about too.

How it works: Provider minting

Retrying the same session asks the same dead exit

The first version of that retry was wrong in a way that took a real report to find. A launch was refused four times with "Proxy returned HTTP 504" while the provider's own status dot, a few centimetres away on the same screen, was green. Both were true.

On a sticky port the session token picks the exit, and every retry went out on the same token. We hunted the case on purpose: forty fresh sessions at the seller, with one bad exit turning up on the twenty-ninth.

session 889053 -> 504    the attempt the launch refused on
session 889053 -> 504    retry 1
session 889053 -> 504    retry 2
session 889053 -> 504    retry 3

session 758767 -> 504    a fresh one, unlucky
session 195609 -> 200
session 131797 -> 200

The status dot was green because the provider check mints its own session to ask, which is a different exit, and a working one. Three attempts on one token are one attempt with a longer wait. Now a failure costs a different session instead: the replacement is minted from the same provider with the same pick, so a country you chose is still the country you get. How sessions die and what that looks like from the browser is in sticky session expiry symptoms.

Two limits apply. Only a session Mosaic minted may move. A session you pinned by hand is never quietly relocated: the launch is refused and says why, because a profile that comes out somewhere it was not asked to be, without a word, is worse than a refusal. And a rotation that worked is written back, so the next launch does not start by failing on the dead token again.

Some errors are the gateway's final answer

Retrying everything would be its own mistake. A gateway that rejected the password will reject it the second time. We measured one of these: putting -session- on a rotating CatProxies port comes back Can not use -session- on rotating ports, and retrying that three times turned an instant, useful answer into a forty-second wait for the same sentence.

So the check keeps a short, named list of answers it treats as settled and returns at once: an invalid request configuration, an option the port cannot use, rejected credentials, failed authentication, a refused CONNECT, and a proxy type that cannot be used upstream. Everything else is treated as bad luck and earns another exit. The comment above that list explains why it is short. Getting it wrong in the generous direction costs three attempts; getting it wrong in the strict direction reports a pool's dead exit as a broken proxy.

What to do when you see the 400

1. Send the same request again on a fresh session. With many sellers that means a new session id in the username; with a rotating port it means simply asking again.
2. If the fresh session works, the gateway is fine and the old exit was bad. If the old session was sticky, stop using it.
3. If fresh sessions fail the same way several times, look at the request: the target address, its port, and whether the site is up from somewhere else.
4. If the gateway names your credentials or the session option, fix that and do not retry.

For a proxy minted from a provider, Mosaic does the first two for you before any profile opens, because a profile never starts behind a proxy that has not answered and tunnelled. A pasted proxy with a fixed address is retried as it is, which on a rotating port already means a new exit. What else that check measures, the exit's country, whether CONNECT works and whether the exit holds still, is in how to check a proxy before you use it. How one pasted gateway line becomes a separate session for every profile is on proxy providers.