Skip to main content
SwiftSpeedTest
Speed TestQualityStabilityBufferbloatPlan auditCalculatorProvider testsDataSlow InternetGuides
Speed TestQualityStabilityBufferbloatPlan auditCalculatorProvider testsDataSlow InternetGuides
Security

Internet speed test for VPN users

Compare VPN-on and VPN-off results under controlled conditions, isolate the bottleneck, and improve performance without bypassing security policy.

Paired baseline methodGateway and routing diagnosisSecurity-safe decisions
Start Speed TestView setup guide
Speed TestResults

Test your internet speed

Measure download, upload, and latency instantly—no installs.

Download
—
Upload
—
Latency
—
Actionable insights
See how your results stack up for streaming, gaming, and remote work.
Run again after tweaks to confirm Wi-Fi and device improvements.
Start Speed Test

Runs in your browser. No account or download required.

Published by Swift Speed Test. See our testing method, sourcing standards, limitations, and corrections policy.

Setup checklist

Get faster, steadier results

Follow these focused steps, run a fresh speed test, and compare the numbers against your goals.

There is no universal acceptable VPN slowdown

  • Use your own paired baseline. Encryption, gateway distance, tunnel routing, protocol, device load, inspection, and provider capacity all affect the result, so a blanket loss percentage is not a defensible pass/fail rule.
  • Judge the protected task. A lower peak Mbps result can still be adequate; recurring call freezes, upload stalls, or large loaded-latency increases are more actionable than the percentage alone.
  • Respect policy. Disable a work VPN or change gateways, protocols, routes, or split-tunnel rules only when the owner or administrator permits it.
  • Updated July 24, 2026. This guide replaces unsupported fixed slowdown claims with a repeatable comparison and documented routing decisions.

Controlled VPN test checklist

  • Use the same device, browser, local connection, power mode, and physical location for every comparison.
  • Pause unrelated downloads, backups, streaming, and updates. Record whether security inspection or endpoint protection remains active.
  • Run one VPN-off baseline only when it is safe and allowed, then connect the VPN and manually keep the same SwiftSpeedTest endpoint when possible.
  • Run each state at least twice and alternate the order on a final pair. This reduces the chance that changing network demand is mistaken for VPN overhead.
  • Record gateway city or region, tunnel protocol, connection mode, and time along with download, upload, idle latency, loaded latency, jitter, failed probes, and confidence.

Decision table: calculate and interpret the delta

  • Throughput change: calculate (VPN-off Mbps − VPN-on Mbps) ÷ VPN-off Mbps × 100 for download and upload separately. Label a negative result as an improvement, not a loss.
  • Latency change: subtract the VPN-off latency from the VPN-on latency. Compare idle and loaded latency separately; a clean idle result can hide congestion under transfer load.
  • Both states are poor: test Ethernet versus Wi-Fi and investigate the device, router, access link, or ISP before blaming the tunnel.
  • Only VPN-on is poor:test an approved nearby gateway, another approved protocol, and the organization's destination- specific diagnostic. The likely scope is the tunnel path, gateway, inspection stack, or VPN capacity.
  • Peak Mbps is acceptable but calls fail:prioritize loaded latency, jitter, unsuccessful probes, and the application's own call statistics instead of buying bandwidth on headline speed alone.

Decision table: isolate gateway, protocol, and routing

  • Nearby gateway good; distant gateway poor: geography or the longer route is implicated. Use the nearest approved gateway unless the destination or policy requires another region.
  • One gateway is poor at the same time: gateway load or its upstream path is a stronger hypothesis than the home connection. Save paired results for the VPN operator.
  • One approved protocol is consistently better: keep the protocol that matches organizational security and compatibility requirements; do not assume one protocol always wins on every device or path.
  • Only selected cloud apps are slow: inspect routing, proxy, TLS inspection, DNS, and application service health. A generic speed-test path may not traverse the same controls.
  • Performance changes after reconnecting: record the new gateway address or region. Reconnection may have changed the route, so it is evidence—not proof that a reboot “fixed” the network.

Split tunneling is an administered security decision

  • Microsoft explains that force tunneling sends all traffic over the VPN, while split tunneling sends only configured routes through it; that choice affects capacity planning and security expectations. See Windows VPN routing decisions.
  • For Microsoft 365, Microsoft recommends narrowly scoped exceptions for documented Optimize endpoints rather than a casual app-by-app bypass. Read the Microsoft 365 split-tunnel overview and Windows implementation guidance.
  • Do not create personal exclusions for work apps, sensitive destinations, security tools, or DNS. Ask the administrator to validate routes, policy, logging, and leak protection.
  • After an approved route change, repeat the paired test and also test the actual application. A faster generic test does not prove that protected corporate traffic still follows the intended route.

Safe improvement order

  • Fix the local path first: use Ethernet or strong Wi-Fi, close competing transfers, connect power, and rule out device thermal or CPU limits.
  • Choose the nearest approved gateway that still reaches the required resources and region.
  • Compare only protocols exposed and supported by the VPN administrator or provider. Preserve authentication, encryption, kill-switch, DNS, and endpoint-protection policy.
  • Escalate with paired evidence when the approved settings do not resolve the issue. Include the destination app, gateway, protocol, timestamps, call statistics, and both VPN-on and VPN-off results.
  • Use an application-specific network diagnostic when available because a browser throughput endpoint cannot validate every corporate route or inspection service.

Sources, security boundary, and limitations

  • NIST describes IPsec as a framework for protecting communications over IP networks and provides implementation guidance in SP 800-77 Rev. 1. Performance testing must not be used as a reason to weaken required protections.
  • SwiftSpeedTest measures the browser-to-selected-endpoint path. A corporate application can use different routing, proxying, DNS, inspection, peering, or service infrastructure.
  • A comparison is strongest when its device, endpoint, order, workload, and time are controlled. It is not a certification of VPN security or service quality.
  • See the SwiftSpeedTest methodology for transfer sizing, loaded-latency probes, confidence, privacy, and known limits.

Troubleshooting topic cluster

More internet troubleshooting guides

Continue with the most relevant explainers from this topic.

  • Why is my internet so slow?Use Ethernet versus Wi-Fi tests, time-of-day checks, and traffic clues to find the bottleneck.
  • Internet connection diagnostic reportRun a full browser measurement and export a privacy-safe support report with loaded response, confidence signals, next steps, and a controlled retest protocol.
  • Internet speed vs advertised speed testCompare the median of eligible measured runs with your advertised plan and Broadband Consumer Label, then export an evidence-aware support summary.

Retest and log improvements

Run SwiftSpeedTest after each change. Note the download, upload, and latency shifts to lock in better performance.

Re-run test now

© 2026 SwiftSpeedTest. All rights reserved.

Open dataShare resultsWebsite widgetSupport reportProvider testsSpeed historyPlan auditCompare resultsQuality testStability testBufferbloat testGaming testStreaming testWork-from-homeSlow internetWi-Fi vs EthernetGood speed resultsSpeed calculatorHow it worksGuidesRSS feedPrivacyTerms