What Does a VPN Server Score Actually Tell You?

Server scores are numbers a publisher computed for its own list, and each one means whatever that publisher decided it means. Two directories can rank the same endpoint differently without either being wrong. Read the definition before you let a rank choose an exit for you.

The checks below cover what to read, what to measure yourself, and what to write down. They assume a client that already supports the protocol a candidate offers.

Read the Definition Before the Rank

Start with the definition page rather than the table. A score built from reported uptime, session counts or throughput estimates orders endpoints by those quantities, which is a statement about load and reachability instead of privacy. Note how stale the inputs are, because a figure refreshed monthly describes a different machine from one refreshed hourly. Where no definition exists, the number is an ordering device with unknown inputs, and it deserves exactly that much trust.

Scope matters as much as input. A value measured between the publisher's probe and the endpoint says nothing about the path from your network, and a number describing bulk transfer does not predict interactive latency. Freshness and scope together decide whether the figure applies to your decision at all.

Trust, Compatibility and Speed Are Three Questions

An endpoint that accepts your traffic is not thereby a good place to send it. A directory entry lists operational connection details, which is not a certificate about logging, ownership, or what the operator does with metadata. Compatibility is a separate question: protocol, cipher set and client version either match or they do not, and no score changes that. Speed is third, and it is the only one of the three you can measure from your own machine.

Keeping the three apart prevents the most common mistake, which is picking a fast endpoint and reading that as evidence of good practice. A slow but straightforward endpoint is a better default than a quick one whose operator you cannot describe.

A directory may also publish fields that fit none of the three. An operator's own description, a protocol list, or a country label are claims and metadata, and they arrive with the credibility of whoever typed them.

Measure the Candidate From Your Own Network

Once a candidate passes the first two questions, measure the path you would actually use. The commands below check reachability, path quality and a completed request, in that order. Run them at the hour you would use the service, since a home uplink and a public relay both change with load.

ping -c 20 203.0.113.77
mtr -r -c 50 203.0.113.77
curl -sS -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' --max-time 8 https://example.com/
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/203.0.113.77/1194' && echo port-open

Read the output as three separate answers. A ping that never replies may mean the endpoint filters ICMP rather than that the service is down, so pair it with the port check. The path trace shows where delay accumulates, and a completed request with timing proves the chain works from your address. None of those values is a permanent property of the endpoint.

Write the Comparison Down

Record the candidate, the time of the measurement, the three results, and why you moved to the next one. That turns a list of remembered ranks into a comparison somebody else can repeat. It also breaks the loop where you keep switching countries and conclude that everything is slow.

A failed candidate deserves a note too, since an endpoint that refuses one protocol at one hour is a fact about that test rather than a verdict on the whole directory. Write the refusal down with its timestamp, and the next comparison starts from evidence.

Re-check the chosen endpoint after any client upgrade, because the compatibility answer can change while the score stays identical. Treat the number as an ordering hint and your own measurements as the evidence.