# Verify Your Connection

After deploying a circuit, verify that your traffic is actually routing through the VPN. This page covers the checks you should run and what to expect from the results.

## Check Your IP Address

The fastest way to confirm VPN protection is active: your public IP should show the VPN exit server, not your real location.

### From Terminal

```bash
curl https://ifconfig.me/
```

The returned IP should belong to your VPN provider, not your ISP.

### From Browser

Visit any of these sites from a device on your LAN:

- [whatismyipaddress.com](https://whatismyipaddress.com) - Shows IP and approximate location
- [ipleak.net](https://ipleak.net) - Comprehensive leak test including DNS
- [mullvad.net/check](https://mullvad.net/en/check) - Works with any VPN, not only Mullvad VPN

The reported location should match your VPN exit server's city, not your physical location.

## Latency Check

Ping a reliable external server to measure round-trip time through your VPN tunnel.

**Primary (privacy-focused):**

```bash
ping 9.9.9.9
```

Quad9 is a privacy-focused DNS provider. Good baseline for latency testing.

**Alternatives:**

```bash
ping 1.1.1.1  # Cloudflare
ping 8.8.8.8  # Google
```

### What to Expect

VPN adds latency. Your traffic travels to the VPN server first, then to the destination, then back. If you are routing through a server on another continent, expect latency to reflect that geographic distance.

A VPN server in the same city might add 5-15ms. A server across the Atlantic might add 80-120ms. This is physics, not a problem with your setup.

## Latency with Parallel VPNs (ECMP)

When running parallel tunnels, different destination IPs may route through different tunnels. This is expected ECMP behavior.

**What you might observe:**

```bash
ping 9.9.9.9   # Routes through Tunnel A -> 45ms
ping 8.8.8.8   # Routes through Tunnel B -> 62ms
```

ECMP hashes flows based on source IP, destination IP, protocol, and ports. Each destination gets assigned to a specific tunnel and stays there for connection stability.

**This is not a bug.** You are seeing the latency of whichever tunnel that particular destination hashes to. If your parallel servers are in different datacenters or cities, latency will vary by destination.

For consistent latency to all destinations, use a single tunnel or ensure all parallel tunnels terminate in the same datacenter.

## Speed Tests

### Basic Test (Aggregate Throughput)

1. Go to [speedtest.net](https://speedtest.net)
2. Run the test with default settings

By default, speed test sites use multiple parallel connections. With parallel VPN tunnels, these connections distribute across your tunnels, showing aggregate throughput.

### Per-Tunnel Throughput

To see what a single tunnel delivers:

1. On speedtest.net, click the settings gear
2. Disable **Multi-connection** (may be labeled "Multiple connections" or similar)
3. Run the test again

This single-connection test shows the throughput of one tunnel. With 4 parallel tunnels, your aggregate (multi-connection) result should approach 4x this number, assuming the bottleneck is server-side capacity rather than your ISP line.

### What to Compare

| Scenario | What it shows |
|----------|---------------|
| VPN off | Your raw ISP speed |
| VPN on, multi-connection | Aggregate throughput across all tunnels |
| VPN on, single-connection | Per-tunnel throughput |

If single-connection shows 150 Mbps and you have 4 tunnels, expect aggregate results around 500-600 Mbps (accounting for overhead).

## Quick Verification Checklist

After deploying a new circuit:

- [ ] IP check shows VPN exit location, not your real location
- [ ] DNS leak test shows VPN provider's DNS, not your ISP's
- [ ] Ping latency matches expected distance to VPN server
- [ ] Speed test shows reasonable throughput for your connection and tunnel count

## If Something Looks Wrong

**IP check shows your real location:**
- Circuit may not have deployed successfully
- Check the Wirebump dashboard for errors
- Try redeploying the circuit

**Speed is much lower than expected:**
- Server might be overloaded. Try a different exit location.
- With parallel tunnels, test single-connection mode to identify if one tunnel is slow
- Check if traffic shaping limits are set too low

**Latency is unexpectedly high:**
- Confirm which city your VPN server is actually in
- Geographic distance is the primary factor in VPN latency
- For lower latency, choose servers closer to your physical location

For more detailed troubleshooting: [Troubleshooting Guide](https://wirebump.net/docs/guides/troubleshooting)

---

Mullvad and Mullvad VPN are trademarks of Mullvad VPN AB. Proton VPN is a registered trademark of Proton AG.