A residential proxy gets detected as a proxy because it is one. The address belongs to a home ISP, but it is relaying somebody else's traffic, and the companies that sell IP intelligence watch residential pools for exactly that. We met a clear case of it while chasing what looked like a fingerprint bug: on one residential exit in Wichita, two detectors would not load at all.
What a residential proxy detected as a proxy looks like from inside a test run
We had one profile paired to that Wichita exit and ran it through our detection catalogue three times. Two rows came back the same way every round:
row through the exit no proxy, same machine
fingerprintjs unreachable x3 HTTP 200, attention
incolumitas unreachable x3 HTTP 200, pass
Unreachable is a status our runner keeps apart from pass and fail. It means the site did not serve a page, so nothing about the profile was measured. Both sites were up the whole time, because they answered straight away when we asked from the same computer with no proxy in the path. What changed between the two columns was the address.
The plain reading is that the exit was known. The IP was flagged by several vendors at once, and two of the sites in our catalogue would not serve it a page. That is an ordinary fact about residential pools. An address in a pool carries strangers' traffic all day, and the lists that track pools see it doing so.
Paste one gateway line. Every profile mints its own exitIn Mosaic: Provider minting. One gateway line, a separate exit for every profile. Free holds 3 profiles. Pro is $49 a month for any number.
Mosaic is a desktop app
Email yourself the link and open it on your computer.
How it works: Provider minting
Why it nearly cost us days
The same profile was failing Pixelscan with "fingerprint inconsistent", and our control browser passed. The control was an untouched Google Chrome for Testing of the same major, and at the time our control tool launched it with no proxy at all. So it compared two browsers and two countries in one go. The control passing looked like proof the fault was ours.
We tested four explanations against that result, and all four died:
hypothesis what we changed result
the chip patched to the host's own Apple M4 Max fail
the canvas seed canvas: 'off' fail
the proxy detached entirely fail
every surface --disable-spoofing on all 18 fail
The third row was our own mistake. Taking the proxy off left the profile claiming America/Chicago from a European address, so every result after it carried a contradiction we had introduced. A field-by-field diff of the thirteen values Pixelscan's collector gathers showed it: every capability field identical to the stock browser, and the timezone reading America/Chicago against the stock browser's Europe/Brussels. (Why that one field decides Pixelscan's verdict is in our Pixelscan timezone sweep.)
Once the stock browser was given the profile's own exit, the answer took one line. Chrome for Testing from the same Wichita address was read as "fingerprint inconsistent" too. And when we minted a fresh session for the same profile, with the same seed and the same chip and only the exit moving, the Pixelscan row went flaky: unreachable, fail, pass.
Three separate measurements pointed the same way. The verdict was about the address, not the profile, and the two unreachable rows had been saying so from the first round.
What we changed in the control
The control now builds a relay to the profile's own proxy, from the same relay.ts the launcher uses. (Chrome's --proxy-server switch cannot carry a username and password, which is why profiles get a local relay at all.) If the control cannot reach the profile's proxy, it refuses to run and says why. It no longer quietly produces a comparison across two countries.
A control has to differ from the thing it controls in exactly one way. "Which browser" is one way only while the exit, the timezone and the language are held the same. Leave the address loose and the control does not narrow the explanations, it adds a country to them.
What to do when your residential exit is flagged
Read the rows that did not load before you read the ones that failed. If several unrelated detectors refuse the exit while answering your own connection, the address is the finding, and every verdict on that run is about the IP first.
Then change one thing. A new sticky session on most residential providers means a new exit, so mint one and run the same profile again. If the verdicts move with the session while the profile stays fixed, you have learned something about the pool, not the browser. This is also why we mint a separate session for each profile from a proxy provider: two profiles on one session share one address, flags included (forty profiles, forty exits is that rule in detail).
Mosaic's proxy check helps with part of this. It queries public DNS blocklists, reads whether the exit sits on a residential ISP or a hosting range, and looks at its reverse DNS. What it cannot read is a commercial proxy database, because those are sold, not published. So a clean result from us means the exit is not on the public lists, and the Wichita address is a reminder that a detector's vendor may still know it. The steps for checking an exit by hand are in how to check a proxy before you use it.
