The test does not open the sites you normally use, and it does not check whether a subscription expired. It only answers: right now, with the method in Settings, how many milliseconds this node returned, or whether it timed out. A low number means the probe target was closer or quieter then. A high number or timeout can mean the probe is limited, the path is congested, or the probe address does not fit this route. The site you actually visit may still work.
So the test is a ranking tool, not a health check. If the provider marks a node as usable, open a site you actually use before you switch, even when the number looks high. Conversely, a very low number does not matter if Global Routing is on Config and rules send that domain to Direct. What you feel is unrelated to the test.
Where the number comes from
You can change the latency-test address and method in Settings. After you change the probe target, old and new numbers are not comparable: the path is no longer the same. Comparing several nodes is useful only at the same moment, on the same network, with the same probe settings. A rise or drop hours later does not prove the configuration was broken.
A gap between Wi-Fi and cellular numbers is common. Confirm which network you are on before you judge the node. Some office Wi-Fi networks interfere with probes, while cellular is closer to daily use. Do not bounce between the two networks and blame the node for the difference.
Setting locations are on the Settings page. Names follow the installed version.
Common misreads
- Treating one timeout as a permanently dead node and deleting it at once. If the provider list still includes it, the next update brings it back. Without a backup, you may drop a route that still works.
- Retrying the same node in a tight loop and treating a brief congestion spike as a wrong parameter. Repeated probes can also trigger provider rate limits and make the number worse.
- A very low test while Global Routing stays on Config, and rules send the target to Direct or another policy group. Change the comparison method. See Global Routing.
- Every node times out, and Direct also fails on sites you normally use. That is a local network or destination problem. More tests will not add information.
- Reading a failed test as a failed subscription update. Updates use the subscription URL. Tests use the probe address. See subscription updates.
A more reliable workflow
- When you pick a node, start with entries the provider marks as usable, then use the test as a reference. Do not tap only from lowest number to highest.
- If the test looks wrong, select that node and open an address you actually need. If it loads, keep using it.
- If that address also fails, keep it fixed and compare Direct, Proxy, then Config. Direct failure: check the local network first. Proxy failure: change the node. Config-only failure: check rules and DNS.
- If the VPN icon is missing, go back to permission. Without a tunnel, the test has no operational meaning.
- If everything times out and Direct also fails, check the system clock, the current Wi-Fi or cellular network, and whether another VPN is active.
Policy groups and On Demand
A policy group may pick an exit by latency. The test number feeds that logic, but the auto-chosen node can still fail on the site you need—the probe address is not that site. If the group’s exit is unstable, pin a node manually and watch a real page load. That is clearer than running full-list tests again and again.
On Demand connects or disconnects on certain networks. If the tunnel just dropped during a test, the number will look worse. Check the switch and the status bar first, confirm the tunnel is up, then test. The widget and the in-app switch control the same connection. Do not flip both and then read the number.
When you can ignore the test
After the first subscription import, the list often has no numbers yet. You can still connect to the node the provider recommends. For certificate or TLS errors, check the system date first, not the milliseconds. High battery use or heat usually means Proxy was left on, or rules send a large share of traffic into the tunnel. That is a different problem from one node’s test number.
The same node’s number rising and falling across the day is usually load and the local network, not rewritten parameters. If you did not edit server fields and did not update the subscription, do not refill the address and port after one spike. Refilling is how a working node becomes a broken one.
A batch test probes many servers in a short window. On a long list, later rows may hit a busier local network, so numbers look worse toward the bottom. “Worse as you go down” does not mean those nodes are worse. To compare, select only the few you plan to use and finish the test within the same minute.
A timeout may show as a mark instead of milliseconds. That is not the same as “the provider deleted this node.” Deleted nodes usually leave the list after a subscription update. A timeout with a successful update and the same count means the entry is still there; only the probe failed.
For games or calls that need UDP, the latency test is an even weaker stand-in for real use. It usually reflects round-trip on the probe path, not whether the current protocol and node support UDP. If those apps fail, ask the provider about capability and compare with Global Routing. Do not stare at milliseconds alone.
UI locations are in the illustrated tutorial. A feature summary is on Features. This site does not provide nodes. Without a configuration, there is nothing to test. Do not treat the test page as a download entry. Install only from the App Store.