The Test button in the ProxyHive browser extension sends one HTTPS request to an IP echo through the proxy you picked, without moving your tabs onto that proxy, and times how long the response headers take to come back. It answers three questions well: does this proxy accept my login, does it carry a request, and what exit IP and country does it hand out right now. It does not tell you whether a given site will accept that exit, how the proxy holds up under load, or what its success rate is. Those need a benchmark, and we have a method and a script for that.
Everything below is read from the extension's source, version 0.3.0, so you can check the claims rather than take them.
What one test sends
A test is a single GET to an IP check service that answers with JSON naming the caller's address. If you linked a dashboard account, the extension asks that dashboard's own echo, which for a ProxyHive account is the one our proxy checker reads. With nothing linked it asks https://api.ipify.org?format=json.
Three details keep the test honest:
- It is tagged. The request carries a random one-off parameter, so the extension can route that exact request through the proxy under test while every tab carries on as before.
- It skips caches and cookies. The request is sent with the cache disabled and without credentials, so an old answer cannot stand in for a new one and no site cookie rides along.
- It has a deadline. After 8 seconds without an answer, the test is called off and reported as timed out.
When the echo answers, the extension records the outcome, the round trip in milliseconds, the exit IP and, when the echo supplies one, the country.
How the number is timed
The clock starts just before the request is sent and stops when the response headers arrive. The JSON body is read afterwards and is not part of the figure. So the number in the Latency column covers, in order: reaching the proxy, any login challenge the proxy sends before it lets you in, the proxy's own connection to the echo, the TLS handshake with the echo, and the echo's reply starting to come back. Your own internet connection is in there too, at both ends.
You can reproduce the same measurement in a terminal. time_starttransfer is curl's name for the moment the first byte of the response arrives, which is the point the extension stops its clock:
curl -sS -x http://USERNAME:PASSWORD@HOST:PORT \
-o /dev/null \
-w 'tunnel+tls %{time_appconnect}s first byte %{time_starttransfer}s status %{http_code}\n' \
'https://api.ipify.org?format=json'
We ran this with curl 8.18 against a local authenticating test proxy on 2026-11-06 to check the syntax. With a wrong password, curl stops at the proxy and prints curl: (7) CONNECT tunnel failed, response 407, the terminal's version of the extension's Login refused.
What the result words mean
A test that does not end in a latency figure ends in one of these:
| Shown | What happened |
|---|---|
| Working | The proxy answered the IP check |
| Login refused | The proxy refused the username and password |
| Unreachable | Nothing answered at the proxy address |
| Connection refused | The proxy accepted the login but refused to open the connection |
| Timed out | No answer within the 8-second limit |
| Wrong scheme or TLS | The port did not answer as an HTTP or SOCKS proxy; check the scheme and port |
| IP check failed | The proxy works, but the echo service did not answer as expected |
| Cannot test | The browser cannot test this proxy right now (see below) |
IP check failed is worth a second look: it is a working proxy and a broken echo, not the other way round. The proxy error codes guide covers the HTTP side of these failures, 407 included.
Why results go stale
A latency figure is a snapshot, and the extension treats it like one. Results live for the browser session only, so a restart clears them. A result is marked stale after 30 minutes, and at once if you change the proxy's address or username, because a test of the old login says nothing about the new one. A stale figure stays visible with its marker rather than vanishing, so you can see what you knew and when.
Thirty minutes is a judgement, not a law of networking. Routes change, pools rebalance and your own connection has busy hours. If a decision rests on the number, press Test again first.
Chrome tests one at a time, Firefox up to four
The two browsers expose different tools to an extension, and the tester uses what each one offers.
Chrome has one proxy configuration for the whole browser. To test a proxy without moving your tabs, the extension briefly installs a PAC script that sends the echo's host through the proxy under test and leaves the routing of your sites as it was, then puts the old configuration back. Two tests at once would need two configurations, so tests queue and run one by one. A Test all over 40 proxies that all time out could take 40 times 8 seconds, a little over five minutes; responsive proxies are far quicker.
Firefox lets an extension choose a proxy per request. The tagged test request is routed through its proxy while every other request follows your normal rules, so up to four tests run at once.
A few situations stop tests in both browsers, and the row says which: while a PAC script routes the browser, while the kill switch is on, and in Chrome while another extension controls the proxy setting. Chrome also cannot send a username and password to a SOCKS5 proxy, so such a proxy shows Cannot test there; the HTTP port of the same proxy tests normally.
What the Test button cannot tell you
One request is evidence of one thing. These are the questions it leaves open:
- Whether your target accepts the exit. The echo is not your site. A proxy can pass every test and still meet a block page, a captcha or a 403 on the site you care about. Load the site through it and look.
- A success rate. A rate needs hundreds of requests per target; one request is a sample of one. Our benchmark guide shows how many you need to tell 90% from 85%.
- The slow tail. A p95 comes from a distribution, and a single test has none. The proxy that answered in 40 ms once may spend a fifth of its requests near the timeout.
- Throughput. The echo's reply is a few dozen bytes. It says nothing about how fast a large page or a file comes through.
- Rotation. A rotating gateway can hand out a new exit on every request. One test sees one of them; the next test may see another.
- Anyone else's experience. Your connection and location are part of every figure. A teammate in another city will get different numbers from the same proxy.
- Leaks. Whether a page can still find your own address through WebRTC is a different check. Run the proxy checker while connected.
Use it for what it is good at
The Test button is a triage tool, and a good one.
- After an import. Test all sorts a new list into proxies that work, logins that are wrong and ports that are not what the label says, before you rely on any of them.
- Before a session. A quick test tells you the proxy you are about to connect is up now, not at lunchtime.
- Side by side, roughly. Proxies tested from the same browser within a minute of each other are at least measured the same way. A gap of hundreds of milliseconds that repeats means something; a gap of ten does not.
When the question becomes "which proxy should carry this job", graduate: run the same targets through each candidate with the benchmark script, or put two exits side by side on the same site and look at what each one is served. The setup guide covers installing the extension, and the extension page shows the Latency column in both themes.