How to prove your scraper is really using a proxy

Check the IP the target sees

The simplest proxy test compares the server IP to the IP observed by a target endpoint. If the scraper requests an IP echo service through the proxy and the response still shows the server IP, the proxy is not active for that tier.

Run that check separately for direct HTTP and browser render. A common production mistake is wiring the proxy into the HTTP client while the browser process launches without proxy settings.

Browser tiers need special attention

In a browser system, proxy configuration may happen at launch time, context time, or connection time depending on the browser backend. With a shared remote browser, a per-request proxy field can be ignored unless the remote browser process is created with that proxy.

That is why egress verification belongs in post-deploy checks. Health checks can pass while the browser tier is quietly using the instance IP.

• Compare direct server egress against scraper-observed egress.
• Test direct HTTP and forced browser render separately.
• Log the method used for each scrape result.
• Treat proxy-active as a measured fact, not an assumed config value.

What good looks like

A clean deploy check should show the direct server IP once, then a different observed IP for a direct scraper request, and another proxy IP for a forced browser request. The exact proxy IP may rotate; the important part is that it is not the server.

Once this is automated, proxy regressions become ordinary deploy failures instead of quiet data quality problems.