Is that site blocking your IP, or your code?

Why the same URL can answer two different ways

A website sees a connection from an address before it sees anything else, and it can look that address up. Addresses that belong to hosting companies arrive in large contiguous blocks and are registered to businesses that rent servers. Addresses from consumer internet providers are the ones ordinary visitors use. Some sites treat the two differently, which is one reason the same request can return a product page from one address and an interstitial from another.

It is not the only reason. Request rate, headers, the TLS handshake, cookies and session state all affect how a site answers, and this test varies only the address. It tells you whether the address made a difference for this URL at this moment; the other variables are yours to check.

What this test 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 so that a site having a slow second does not look like a site treating the addresses differently.

Every vantage point sends an identical request: same method, same headers, in the same order. If the user-agent varied between them, the test would be measuring two things at once and could not attribute a difference to the address.

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 from the address that asked: a 403 or 429, a 503 carrying a challenge, or 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 stores the challenge page 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, which answers the question without turning the tool into a way to read pages through our servers. It also only accepts ports 80 and 443, refuses hosts that resolve to private addresses, and never follows redirects.

Reading the results

Each outcome below is one request per address, at one moment. It shows what the site did; the reason is a likely explanation to confirm with your own traffic.

Datacenter blocked, residential served

The address affected this URL's response. This is the outcome where changing the type of address is most likely to help. Before choosing a plan, check that the same holds at your own request rate and with your own headers, since a site that serves one residential request may still limit a thousand.

Everything served

None of the three addresses was refused for this request. If your own requests to this URL are being blocked, look at what differs between your traffic and this test: request rate, headers, session state and how your HTTP client looks on the wire. The request fingerprint tool shows the header part of that.

Everything blocked, residential included

The site refused all three addresses on their first request. That usually points at something other than the address: the TLS handshake, the header set, or a page that refuses all automated traffic. It can also mean the URL itself is gated. Changing the address type alone is unlikely to be enough here; compare your client with the request fingerprint tool and try the URL from a real browser.

Blocked in one country, served in another

Geographic filtering, or geographically different content. Country targeting is the variable to test next for that URL.

Common questions