Public pages only. We send a GET request, read enough of the response to classify it, and never store or show you the page body.
Why the same URL answers two different ways
A website does not see your code. It sees a connection from an address, and it knows a great deal about that address before your first byte of HTML is written. Addresses that belong to hosting companies are easy to identify: they arrive in large contiguous blocks, they are registered to businesses that rent servers, and almost no ordinary shopper has ever visited from one. Addresses that belong to consumer internet providers look like customers, because they are.
That single distinction is the reason the same request can return a product page from one address and an interstitial from another. It is also the reason that a person who has been blocked cannot easily find out what would fix it. Trying a different proxy means buying a different proxy.
What this test actually does
It issues the same GET request from three of our own vantage points at the same moment: a datacenter address, a residential address in the United States, and a residential address in Germany. They run concurrently on purpose. Run sequentially, a site having a bad second would look like a site treating the addresses differently.
Every vantage point sends an identical request. Same method, same headers, in the same order. If we varied the user-agent between them, the test would be measuring two things at once and could not attribute the difference to the address, which is the entire question.
What counts as blocked
Not simply a response that is not a 200. A 404 is a real answer and the same answer everybody gets; calling that a block would make every mistyped URL look like bot management. This test reports a block when the site withheld the page because of who asked: a 403 or 429, a 503 carrying a challenge, or the case people misread most often, an HTTP 200 whose body is an interstitial rather than the page. A scraper that only checks status codes records that last one as a success and quietly stores challenge pages as data.
What it will not do
It never returns the page body. You get a status, a size, a timing, a content fingerprint and a classification. That is deliberate, and it is what makes a tool like this safe to publish: it answers the question completely while being useless as a way to read pages through somebody else's server. It also only accepts ports 80 and 443, refuses hosts that resolve to private addresses, and never follows redirects.
Reading the three results
- Datacenter blocked, residential served
- The clean case, and the one where changing the type of address is genuinely the fix. The site is filtering on address reputation and your requests are otherwise fine.
- Everything served
- The site is not filtering by address at all. If your own requests are being refused, a different proxy will not change that, and the cause is usually your request rate or how your HTTP client looks on the wire. That is what the request fingerprint tool is for.
- Everything blocked, residential included
- When a site refuses a clean residential address on the very first request, it is not judging the address. It is judging the TLS handshake, the header set and the behavior, and no proxy fixes that on its own. Anyone who tells you otherwise is selling you something.
- Blocked in one country, served in another
- Geographic filtering, or geographically different content. Country targeting rather than proxy type is the variable that matters for that URL.
Common questions
Does this prove your proxies would work for me?
It proves what happened for that URL, at that moment, from those addresses, with those headers. That is a genuinely useful data point and it is not a guarantee. Sites change their posture, and a result that holds at one request per test may not hold at ten thousand a day.
Why can I only test public pages?
Because the alternative is an open proxy. The tool accepts no credentials, no custom headers and no ports other than 80 and 443, which keeps it a diagnostic rather than a way to reach things you are not otherwise able to reach.
Is there a limit?
A few tests a minute per visitor, and a daily ceiling on the residential half, because those requests spend real bandwidth. If the residential comparison is unavailable the page says so rather than quietly showing you a one-sided result, which would look like a finding.
What if I need to check hundreds of URLs?
Then you need proxies and a script rather than a web page, and you can work out which kind with the proxy requirement check.