Last updated: October 2026
#AFFILIATE-PLACEHOLDER-* in our code) until we join programs — at which point every affected page gets a clear, conspicuous disclosure. Full disclosure.
WireGuard is the fastest, simplest, most modern VPN protocol — and the protocol we generally recommend. But it has a well-known design quirk that matters for privacy: every WireGuard client gets a static internal IP address. That address doesn't change for the life of your cryptographic key. Here's what that means, why WireGuard works this way, the 2026 Mullvad exit-IP fingerprinting disclosure that put the issue back in the spotlight, and what you can do about it.
WireGuard's core design is cryptokey routing: instead of separate connection sessions and logins, each client's public key is paired with an "allowed" internal IP address. When a packet arrives, the server checks the key, decrypts, and routes it to that IP — identity and routing are the same thing. Because the pairing is key-to-IP, the server assigns you the same internal IP for as long as your key exists.
This design isn't sloppiness; it's why WireGuard is so good. Tying identity to the key eliminates the slow handshake dance of older protocols — connections reconnect in milliseconds when you switch networks — and it keeps the entire codebase to roughly 4,000 lines, which makes auditing far easier than OpenVPN's roughly 600,000. The static internal IP is the price of that simplicity (mullvad.net — "Why WireGuard?").
Your internal VPN IP (something like 10.x.x.x) is supposed to stay inside the tunnel. But it can escape — and when it does, its static nature makes it much more useful to anyone watching:
Mullvad — a privacy-focused provider and a major WireGuard advocate — puts it bluntly: "We acknowledge that keeping a static IP for each device, even internally, is not ideal," while still concluding that WireGuard overall is in a better state than OpenVPN (mullvad.net).
A persistent misconception says "WireGuard can't work without the server logging your public IP." That's false. The server needs your public WireGuard IP (your real address on the internet) to send packets back to you — but it holds it temporarily in RAM during the connection and deletes it on server reboot or interface restart. No activity logging is required for WireGuard to function (mullvad.net — FAQ).
Mullvad even built an extra mitigation: if no handshake with a peer occurs within 600 seconds, the peer is removed and reapplied, wiping both the stored public IP and the handshake timestamp (mullvad.net — FAQ). A provider running a genuine no-logs setup can run WireGuard without writing your public IP to disk.
In 2026, independent researcher "tmctmt" published findings on Mullvad's WireGuard implementation that put the static-IP question back on the front page. Key facts, verified across CyberInsider and PiunikaWeb's reporting:
The honest framing matters: no identities were exposed directly and there was no evidence of customer data leaks — this was about the potential to fingerprint a user's key across servers, not about cracked encryption or breached accounts (CyberInsider). But it's proof that privacy depends on implementation details, not just on strong cryptography.
Two mitigations are already real: Mullvad WireGuard keys rotate every few days, which resets any such fingerprint — and the researcher's practical advice was to avoid frequent server-switching within one key cycle and force a key refresh periodically (CyberInsider).
Different providers engineer around WireGuard's key-to-IP binding in different ways (alwaysvpn.com — WireGuard workarounds guide):
| Workaround | How it works | Who does it |
|---|---|---|
| Double-NAT / proprietary protocols | A second NAT layer sits on top of WireGuard so the static internal IP never maps cleanly to a user; some providers built entire proprietary protocols on WireGuard specifically to fix the IP-binding issue | e.g. NordVPN's NordLynx (built on WireGuard with a double-NAT system) |
| Automatic key rotation | Keys — and therefore the static internal IPs tied to them — are replaced on a schedule, resetting any accumulated fingerprint | e.g. Mullvad (weekly auto-replace in the app) |
| WG-dynamic | Future protocol work to dynamically assign a new internal IP on every connection, removing the static trait at the protocol level | Cited by Mullvad and AlwaysVPN as the long-term direction |
| OpenVPN instead | Dynamic IPs per session — but a far larger attack surface; Mullvad's position is that WireGuard remains the better overall state despite the static-IP trade-off | Providers offering both protocols |
Table compiled from alwaysvpn.com and mullvad.net (2026).
The verdict: WireGuard is still excellent — Mullvad's own conclusion — but its privacy is only as good as the provider's engineering. Pick providers that engineer around the static-IP limitations (key rotation, double-NAT systems like NordLynx, multihop), and re-test with the leak tool after every change.
Not by protocol design. WireGuard holds your public IP temporarily in RAM during the connection; it is deleted on server reboot or interface restart, and no activity logging is required. Whether a provider logs is a matter of their policy, not the protocol (mullvad.net — FAQ).
Only if something leaks it — the main route is a WebRTC leak. Run our leak test to check; if the internal IP never appears outside the tunnel, sites can't see it.
Not directly. The researcher showed that deterministic exit-IP patterns across servers could form a fingerprint for a WireGuard key — no identities exposed, no evidence of customer data leaks. Regular key rotation (which Mullvad does every few days) mitigates it (CyberInsider; PiunikaWeb).
Probably not. OpenVPN gives you dynamic IPs per session, but it has a far larger attack surface and slower reconnections. Mullvad's position — and ours — is that WireGuard remains the better overall state, provided your provider engineers around its static-IP traits with key rotation, double-NAT, or multihop (mullvad.net; alwaysvpn.com).