Why Speed Tests on a Virtual Machine Look Different
If you've ever run a speed test inside a virtual machine (VM) and thought the results looked off, you're not alone. Virtual machines add layers between your software and the actual hardware, and those layers affect how network traffic flows. Understanding why this happens — and how to get accurate results — can save you a lot of head-scratching.
A virtual machine is a software-based computer running inside your real computer. It shares the host's CPU, memory, and network adapter. Programs like VirtualBox, VMware, and Hyper-V let you run one or more VMs on a single physical machine. But because the VM doesn't talk directly to your network card, speed test results can be misleading if you don't set things up right.
How Virtualization Affects Networking
The Virtual Network Adapter
When you create a VM, the hypervisor (the software managing VMs) creates a virtual network adapter. This fake adapter mimics a real one, but all traffic passes through the hypervisor before reaching your physical network card. That extra hop adds latency and can limit throughput. On a busy host running multiple VMs, this bottleneck gets worse because all VMs share the same physical adapter.
Network Modes Matter
Most hypervisors offer several networking modes, and the one you pick has a big impact on performance:
- NAT (Network Address Translation) — The VM shares the host's IP address. Traffic gets translated back and forth, which adds overhead. This is the default in most setups.
- Bridged — The VM gets its own IP address on your local network and talks directly to your router. This usually gives the best performance and the most realistic speed test results.
- Host-Only — The VM can only talk to the host machine. No internet access, so speed tests won't work at all.
- Internal Network — VMs can talk to each other but not to the outside world. Again, no internet speed testing here.
If you want accurate results when you run a speed test, use bridged mode. It removes the NAT translation step and gives your VM a direct path to the network.
CPU and Memory Pressure
Network performance isn't just about the network adapter. If your VM is starved for CPU or RAM, it can't process packets fast enough. A VM with only 1 CPU core and 1 GB of RAM will struggle to saturate a fast connection. For testing purposes, give your VM at least 2 cores and 4 GB of RAM if your host can spare it.
VM vs. Bare Metal: What to Expect
To show the real difference, here are typical results from tests run on the same hardware — once directly on the host (bare metal) and once inside a VM. These numbers come from a desktop with a 1 Gbps Ethernet connection:
| Metric | Bare Metal | VM (NAT Mode) | VM (Bridged Mode) |
|---|---|---|---|
| Download Speed | 940 Mbps | 650–780 Mbps | 870–920 Mbps |
| Upload Speed | 920 Mbps | 580–720 Mbps | 850–900 Mbps |
| Ping | 4 ms | 8–15 ms | 5–7 ms |
| Jitter | 1 ms | 3–8 ms | 1–3 ms |
| Packet Loss | 0% | 0–0.5% | 0% |
As you can see, NAT mode introduces noticeable overhead — sometimes cutting throughput by 20–30% and doubling your ping. Bridged mode gets you much closer to bare-metal numbers. If your VM results seem low, check out our guide on why your internet might seem slow to rule out other causes first.
Tips for Accurate Speed Tests Inside a VM
1. Use Bridged Networking
We covered this above, but it's worth repeating: switch from NAT to bridged mode before testing. In VirtualBox, go to Settings → Network → change "Attached to" from NAT to Bridged Adapter. In VMware, select "Bridged" under Virtual Machine Settings → Network Adapter.
2. Install Guest Additions or VMware Tools
Hypervisors ship with special drivers called guest additions (VirtualBox) or VMware Tools (VMware). These replace the generic virtual network driver with an optimized one. Without them, you're leaving performance on the table. Installing them often improves network throughput by 10–20%.
3. Use Virtio or VMXNET3 Adapters
The default emulated adapter (like Intel E1000) mimics old hardware. Paravirtual adapters like Virtio (for KVM/QEMU) or VMXNET3 (for VMware) are designed specifically for VMs. They skip the hardware emulation step and pass data more efficiently. VMXNET3 can handle up to 10 Gbps, while E1000 tops out around 1 Gbps.
4. Shut Down Other VMs
If you're running three VMs on one host, they're all fighting over the same network adapter and CPU time. Shut down the others before testing so your results reflect actual network capacity, not resource contention.
5. Run Multiple Tests
VM performance can fluctuate more than bare metal because of how the hypervisor schedules resources. Run at least 3–5 tests and average the results. You can also use our jitter test to see how stable your VM's connection really is — high jitter (above 5 ms) suggests the hypervisor is causing inconsistent packet delivery.
Testing on Cloud VMs (AWS, Azure, GCP)
Shared vs. Dedicated Instances
Cloud VMs add another wrinkle: you're sharing physical hardware with other customers. A standard AWS t3.micro instance gives you "burstable" performance, meaning your network speed might be great for a minute and then throttle. For reliable testing, use a compute-optimized or network-optimized instance. AWS c5n instances, for example, support up to 100 Gbps, while t3.micro caps out around 5 Gbps in bursts.
Region and Server Distance
When you test from a cloud VM, the test server's location matters a lot. A VM in US-East testing against a server in the same region might show 3 ms ping, while testing against a server in Europe could show 80–120 ms. This isn't a problem with your VM — it's just physics. Learn more about what these numbers mean in our latency explainer.
Egress Bandwidth Limits
Cloud providers often limit outbound (egress) bandwidth based on your instance type. Don't be surprised if your upload speed is lower than expected. Check your provider's documentation for the specific limits on your instance size. A packet loss test can also help you determine if the cloud network is dropping packets under load.
When You Should Skip the VM Entirely
VM testing is great for checking how an application will perform in a virtualized environment. But if you want to know your actual internet connection speed — what your ISP is delivering to your home or office — always test from the host machine. A VM will almost always underreport your true speeds, even with perfect settings.
Use VM testing when you need to:
- Verify that a cloud server has the bandwidth your app needs
- Compare network performance across different VM configurations
- Test how your application handles varying network conditions
- Benchmark before and after changing virtual network settings
For everything else, test directly on your host. Head to our broadband speed test to check what your connection can really do without any virtualization overhead getting in the way.
Quick Summary
Virtual machines add overhead that affects speed test results. The biggest factors are your network mode (use bridged, not NAT), your virtual adapter type (use paravirtual like VMXNET3 or Virtio), and whether you've installed guest tools. Expect 5–30% lower throughput and 2–10 ms higher ping compared to bare metal, depending on your setup. Run multiple tests, average the results, and remember: if you want to know your real internet speed, test from the host.