Volunteer VPNs and commercial VPNs put trust in different places
A volunteer relay and a commercial account are different arrangements. Follow who runs the endpoint, what the policy covers, and what the client can prove.
The label on a VPN service says less than the arrangement behind it. A volunteer network can aggregate relays run by people with no relationship to each other, while a commercial service usually presents one account and one published policy over infrastructure it may partly rent. Neither shape is automatically more private. What differs is who controls the endpoint you connect to, and who could therefore answer a question about it.
Three parties, not one
Three parties sit behind any connection, and they are not always the same organisation. The directory operator decides which endpoints you can find and hands out profiles; the software developer decides how your client speaks the protocol; the server operator runs the machine your traffic leaves from. Only the last one is in a position to record or retain anything, and in a volunteer arrangement that person may be a stranger to the other two.
| Party | What they control | What changes when it changes |
|---|---|---|
| Directory operator | Lists endpoints and distributes profiles | Which relays you can find at all |
| Software developer | The client and its protocol implementation | How you connect, not who receives the traffic |
| Server operator | The machine your traffic exits from | Records, abuse handling and upstream network |
A commercial arrangement usually merges the three into one company, though it may rent servers from a hosting provider. Read what the provider says it operates, because the phrase our network and the phrase our policy can cover different systems. Where a partner is involved, the policy has to name it or it does not reach your traffic.
How an endpoint disappears
A volunteer relay exists because its host keeps it running. When that person stops, the entry leaves the directory, and nothing in that arrangement promises the relay will be there tomorrow.
A directory entry is an option, not a guarantee: choosing another entry means choosing a different operator, not reconnecting to the same service. Commercial services fail in the same way for different reasons, whether capacity, a regional restriction or a hosting partner's outage. What changes is who you can ask about it. Neither arrangement owes you continuity just because the profile still loads.
What the policy actually covers
Volunteer projects publish logging and anti-abuse rules too, and those rules are the interesting part. Volunteer describes who hosts the relay, not a promise that nothing is recorded, and a project with published abuse handling is telling you that records exist somewhere.
Commercial policies have the opposite problem: they are detailed, and the detail is what you have to read. A policy covering the provider's own servers does not automatically describe a partner's infrastructure. A jurisdiction statement is not a description of practice. Look for the section that names the systems in scope, and treat a policy that stays vague about scope as marketing rather than evidence.
Decide with a record, not a label
A client that connects proves protocol compatibility and reachability, and nothing about records, because records are made at the endpoint and above it. That is why a green status icon is such a weak signal: the same client pointed at a careful relay and at a careless one looks identical. The decision record therefore has to be built from what you can justify about the specific operator, not from the interface. Write down the technical visibility of the path, the categories of data involved, and the trust the operator has earned; if any of those is a guess, the decision is not finished.
If you are only comparing connections, log the endpoint and the result you measured instead. A relay in one country, a resource that was reached and a response that was measured describe what you tested without attributing one host's behaviour to a whole project.
Keep software and protocol compatibility separate from service practice throughout, because different parties decide them and they fail in different ways. Add two fields to the record for that reason: the client version you ran, and the protocol it negotiated. Then the next comparison starts from evidence rather than from a label. A record that names the endpoint, the client and the result is the only part of this decision you can defend later.