Record the conditions first
A result needs context: app version, operating system, device, connection type, selected location and test time. Remove account identifiers and public IP addresses before publishing a test report. A result from one phone is not evidence for every supported device.
Compare like with like
Use the same device, network and measurement endpoint for a baseline without the VPN and for the VPN run. Repeat measurements and report the range as well as a typical result. Note competing traffic and avoid selecting only the fastest run.
- Measure the baseline connection.
- Connect to the selected VPN location and verify the connected state.
- Repeat the same latency, download and upload measurements.
- Repeat at another time and document limitations instead of generalising a single result.
Check connection behaviour separately
Record whether connecting, disconnecting and changing networks work as expected. A button changing colour alone is not proof that traffic uses the tunnel. Where possible, compare the externally observed address before and after connecting.
DNS and IPv6 checks need their own recorded observations. Do not label a connection leak-free simply because a speed test worked. Check each platform and app version separately.
Separate functional checks from security audits
A successful connection test does not establish how long a service retains data or prove that a system cannot be compromised. Those questions require a different kind of evidence.
If an independent audit is published in the future, its scope, date, reviewer and limitations should be linked directly. This methodology page is not a substitute for such an audit.
Report problems with useful context
Contact support with your app version, device, selected location, approximate time and a description of what happened. Do not send passwords, payment details or private browsing history. A repeatable set of steps is more useful than an unsupported performance claim.