Diagnose a slow VPN with a comparison you can repeat

To find out why your VPN is slow, compare the same device and test tool with the VPN off and on. Keep the network, device position, and background activity consistent, then change one variable such as the server. A single low result cannot identify the cause. First decide whether the problem is a slow download, a delayed call, or a page that takes too long to open. Those experiences can need different checks. Recording the conditions makes it easier to identify which change actually helped.

Which kind of slowness should you measure?

Record transfer rate for downloads, and include latency and its variation when investigating calls or games. If only the start of a page load is slow, observe that website separately. Download speed alone cannot describe the quality of all these tasks.

Download and upload rates are commonly reported in megabits per second. Ping measures a request's round-trip time in milliseconds. Variation in latency describes how that time changes between samples. If your tool does not report a metric, leave it unmeasured. Record the units beside each result so different measurements do not get mistaken for one another later.

Also record a short observation of the actual task: whether the page opened, a call dropped, or a file transfer remained slow. These are observations to make on your connection, rather than outcomes to assume. Avoid sensitive accounts and confidential files during testing, and account for a speed test's data consumption on mobile connections.

The explanation of the VPN connection helps describe the additional route. Knowing that traffic travels through a tunnel still cannot identify the slow part of your connection. A controlled comparison helps separate the possibilities.

What needs to stay consistent between tests?

Keep the device, Wi-Fi or wired connection, device position, and test destination unchanged. Pause background downloads and any synchronization you can safely interrupt. Compare the VPN-off and VPN-on conditions close together so changing network conditions have less opportunity to distort the result.

Proton VPN's speed guide, checked September 7, 2026, identifies the base connection, route to the server, and server load as contributing factors. It also recommends closing background data-transfer applications. That removes a competing variable from the test; it cannot establish that other apps explain every slowdown.

If the test tool chooses a destination automatically, record which one it selects. Connecting the VPN may cause it to choose another destination. Keep that destination fixed where possible. Otherwise, document the difference as a limitation. Changing both the test destination and VPN server makes the result harder to interpret.

Use the connection IP check to record the observed exit. That establishes what the browser saw at that moment; it does not measure network capacity. If the underlying internet connection is unstable, investigate that first and interpret VPN results in that context.

How should you record the comparison?

For each condition, write down the time, VPN server, protocol, and results from the same tool. Fill the table with your own measurements. Leave unmeasured fields empty: estimated figures or results from somebody else's connection cannot diagnose your device.

Test conditionTime and test destinationVPN server and protocolDownload and uploadLatency and actual task observationVPN offRecordNot applicableRecordRecordCurrent VPN configurationRecordRecordRecordRecordChange only the serverRecordRecordRecordRecordChange only the protocolRecordRecordRecordRecord

This is a recording template, with no sample results or suggested normal speeds. Its rows keep the changes separate. You can stop before completing every row if the underlying internet connection already explains the problem.

Check each condition more than once so a momentary fluctuation does not determine the decision. The useful number of runs depends on the variation and the problem being investigated. If the readings vary substantially, report that variation. Selecting only the highest reading gives an incomplete and optimistic picture.

You can repeat the comparison at another time, provided you label it as a separate set. Comparing a morning result without the VPN with an evening result through the VPN mixes the effect of time with the effect of the tunnel. Note whether other people or devices were using the same connection.

Should you change the server or protocol first?

If the underlying connection works, try another server with the same protocol first. Then change the protocol separately if the app supports it. This order helps distinguish the two effects. A closer server is a useful candidate, though geographic distance alone cannot establish route quality.

Proton's guide suggests a closer server and one with a lower load. If the app displays load, record it with the test time because it can change. A server number or city name alone cannot establish the quality of your connection to that location.

The official OpenVPN 2.6 manual describes UDP as the preferred mode and explains TCP as an option where UDP cannot be used. That is a reason to inspect the available settings, but the protocol name cannot predict your measured speed.

Use the setup instructions to locate supported settings for your device. If another protocol is unavailable, avoid inserting uncertain values into a connection file or server configuration. A useful change must be supported by the product and version you use, and you should be able to undo it.

What if the speed test looks good but pages stall?

When downloads test well but a website or transfer stalls, investigate the specific failure instead of treating it as general VPN slowness. The destination, DNS resolution, and packet size can need separate checks. Record when the stall occurs and which tasks still work.

The OpenVPN manual's "mssfix" section describes a connection that starts successfully and then stalls during active use as a possible symptom of broken path MTU discovery. MTU concerns the packet size the path can carry. That symptom cannot establish the diagnosis alone or supply one setting value for every device.

If one website is affected, try another destination under the same conditions. Record whether the issue also appears in other apps. This comparison narrows the scope of the problem. Avoid permanently disabling a firewall or device protection just to improve a speed-test score.

The article on what a VPN actually protects distinguishes tunnel protection from a website's behavior. A faster server cannot guarantee a fix for a destination or account problem. Judge each change against the task that originally failed.

What should a useful slow-connection report include?

Send the comparison table, app version, network details, and a brief description of the affected task. A report identifying the task, server, and time gives a clearer starting point than one screenshot of a low speed. Remove sensitive information before sharing it.

Tell support whether you kept the device and destination fixed. Include an automatic destination change as a limitation if it happened. That detail can make the next request precise, perhaps requiring only one comparison to be repeated.

Resume the downloads and synchronization you paused after testing. Keep a setting that improved the task you care about across repeated relevant observations. Record the date and conditions so you have a clear reference if the slowdown returns.