About Regional Proxy Exit Check
Regional Proxy Exit Check sends a request through one proxy you supply, but originates it from a remote region you select rather than from your own connection. Each region takes several samples and reports the HTTP status, the success rate across them, the negotiated protocol, and a stage-by-stage timing breakdown, so you can see how the proxy behaves for clients that are not sitting where you are.
A proxy is a two-legged path, and where you test from changes one of the legs. The first leg runs from the client to the proxy and is subject to that client's routing, its transit providers, and any geographic filtering the operator applies. The second leg runs from the proxy to the target and barely changes. Testing only from your own machine measures your first leg and quietly assumes everyone else's looks the same — exactly the assumption that breaks when users on another continent report the same proxy is unusable.
How to use this developer tool
- Enter a single proxy in the same formats the batch checker accepts — a URL with a scheme, or host:port:user:pass.
- Pick the region group representing the clients you care about; the label lists the country codes it covers.
- Set a target URL you are authorised to request. An endpoint that echoes the address it saw is the most informative choice.
- Run the check and read results as they stream in. Each region reports several samples rather than one, so a partial success rate is itself a result.
- Compare the stage timings across regions: first-hop DNS and TCP describe the route from that region to your proxy, while TTFB describes the whole chain.
- If a region fails, re-run it once, then compare against a batch check of the same proxy from our own network to isolate which leg is at fault.
Worked example: one proxy, seen from several regions
The proxy passes a direct check, but its usability depends heavily on where the client is. Several samples per region separate a genuinely broken route from one unlucky request.
Proxy http://demo:s3cret@203.0.113.9:8080
Region East Asia
Target https://example.com4/4 regions completed · 3 reachable · 1 failed
JP 200 h2 3/3 samples dns 2 ms · tcp 61 ms · tls 130 ms · ttfb 268 ms
KR 200 h2 3/3 samples dns 3 ms · tcp 74 ms · tls 151 ms · ttfb 302 ms
SG 200 h2 1/3 samples dns 2 ms · tcp 88 ms · tls 190 ms · ttfb 1420 ms
HK — — 0/3 samples FIRST_HOP_CONNECT_FAILEDThree distinct readings. Japan and Korea are clean. Singapore completed one sample in three with a time to first byte far above its handshake times, the signature of an overloaded or rate-limited proxy rather than a broken route. Hong Kong never reached the proxy at all, so the failure is on the first leg and nothing about the target is implicated.
Reading the stage timings in a regional result
Each stage measures a different segment of a two-leg path, and knowing which segment a number belongs to is what makes a slow result actionable.
| Stage | What is measured | What a high or failed value points to |
|---|---|---|
| First-hop DNS | Resolving your proxy's hostname from the selected region | A name whose record resolves slowly or not at all from there. Using a literal address removes this stage entirely. |
| First-hop TCP | Opening the connection from the regional exit to your proxy | The distance and routing quality of the first leg. A failure means the proxy was never reached from that region — geographic filtering, a client allow-list, or routing. |
| TLS | Completing the handshake with the target through the proxy | Roughly twice the round-trip cost of the full chain. A failure means the proxy connected but the secure session could not be established. |
| TTFB | First byte of the target's response arriving back | The end-to-end cost. When TTFB is far above TLS, the connection is fine and something is slow to respond: the target, or a congested proxy. |
| Success rate | Completed samples out of those attempted | Anything between the extremes means intermittency — packet loss, a pool whose members differ, or a rate limit engaging after the first request. |
Troubleshooting
The proxy passes a batch check but fails from every region here.
Why it happens The proxy authorises clients by IP address and only our batch-check origin is on its allow-list, or the operator geo-filters which client networks may connect.
Fix Switch the proxy to credential-based authentication for the test, or ask the operator which client ranges are permitted. A first-hop failure in every region alongside a successful direct check is a strong signal of an allow-list.
The exit address the target reports is not in the region you selected.
Why it happens This is the design, not a fault. The selected region is where the request enters your proxy — the first leg. The address the target sees is your proxy's own exit, wherever it egresses.
Fix If you want the target to see a specific country, that has to come from the proxy you chose. Use this tool for the other question: whether clients in that region can use the proxy at all, and how well.
A region reports that the regional exit is temporarily unavailable.
Why it happens The probe capacity for that region was not reachable at that moment. This describes our probe fleet, not your proxy.
Fix Re-run after a short wait, or select a neighbouring region group. A result naming the provider or the exit rather than a connection stage is not evidence about your proxy.
Latency is much higher than a direct check of the same proxy showed.
Why it happens You are measuring two chained legs instead of one. A request from Tokyo to a proxy in Frankfurt to a target in the United States pays every hop, plus a full TLS negotiation across the chain with no session reuse.
Fix Compare regions against each other within this run, and compare the run against a direct batch check. The difference between the two is the first leg's cost.
The success rate is partial in most regions.
Why it happens Shared and rotating proxies assign a different upstream per connection, and many operators rate limit per client, so the first sample succeeds and the next two are throttled.
Fix Repeat at a quieter time and compare. Consistent partial rates across several runs mean the proxy cannot sustain concurrent use, which is a capacity finding worth raising with the provider.
When this tool is the right choice
- Checking whether a proxy is usable for clients in a specific part of the world, not just from where you are.
- Separating a first-leg problem — the route from a client region to the proxy — from a second-leg problem between the proxy and the target.
- Confirming that a proxy an overseas team relies on is reachable from their side before you hand it over.
- Taking several samples from one region so intermittency shows up as a partial rate rather than a coin flip.
When to use something else
- Filtering a long list of proxies. Batch Proxy Checker takes up to 100 entries at once and reports the failure stage for each.
- Testing a website that does not involve a proxy. Site Check requests a URL directly from multiple regions.
- Verifying what your own browser exposes. Browser Leak Check inspects WebRTC candidates and DNS resolvers locally, which no server-side probe can see.
Privacy and data handling
The proxy address, any credentials it contains, the selected region, the target URL, and your settings are sent to this site's server so a remote probe can perform the request on your behalf. They are used for this check and are not assembled into a user profile, though they pass through ordinary server request handling and logging. Two other parties see part of this: your proxy operator sees connections arriving from the selected region's exit address, and the target sees a request arriving from your proxy's exit. Use only proxies and destinations you are authorised to test, prefer rotatable credentials, and redact screenshots containing a username or password. Proxy checks are limited to 500 per visiting IP per UTC day, an allowance shared with Batch Proxy Checker.
Related developer tools
Frequently asked questions
Does the selected region change my own connection?
No. Your browser's network is untouched. The region determines where the remote probe originates from when it connects to your proxy — a way of testing the proxy from somewhere other than your own line.
Why does a proxy pass in one region and fail in another?
The first leg differs by region: routing, peering, transit quality, the operator's geographic filters, and any client allow-list all vary by where the connection comes from. A first-hop connect failure is a first-leg problem, while a TLS or request failure implicates the second leg.
Does this prove the proxy is anonymous?
No. It reports what one target returned for one request path at one moment. Anonymity depends on the headers the proxy adds or removes, whether the original client address leaks, what the destination infers from TLS and timing, and what the operator logs.
Why does each region take several samples?
Because one request cannot distinguish a broken route from an unlucky packet. A partial success rate is a real and common state for shared proxies, and the only way to see it is to make more than one attempt per region.
How is this different from Batch Proxy Checker?
The batch checker tests many proxies from our own network and reports precisely where each fails. This tool tests one proxy from several client regions with repeated samples. Use the batch checker to find out whether a proxy works at all, and this one to find out for whom.
How many regional checks can I run?
Proxy checks share an allowance of 500 per visiting IP per UTC day across both proxy tools, and the allowance is shared by everyone behind the same public address. Choose the region group deliberately rather than sweeping through all of them.
Can I test a proxy that is not mine?
Only with authorisation. Every check makes real connections to the operator's infrastructure and to the target, using credentials you supply. Testing someone else's proxy or credentials without permission is misuse of both services.