Testing 545 Mullvad Exit Nodes From Shanghai

The setup was worse than nothing

I’m in Shanghai on a China Telecom line, routing everything through my own VPS in Germany because owning the box felt like the dependable option. Then I measured it.

Twice the latency and a seventh of the throughput, against no VPN at all. Meanwhile my Tailscale account has the Mullvad add-on attached: 545 exit nodes across 91 cities that I was paying for and ignoring. Picking one of those turned out to be the whole problem.

The answer, after measuring all of them:

tailscale set --exit-node=ch-zrh-wg-504.mullvad.ts.net   # 513 ms mean over 5 rounds

Zurich, which beats the raw line by 99 ms. A tunnel through Switzerland is faster than no tunnel at all, and I still find that strange.

The obvious pick was wrong

Hong Kong is 1,200 km away, so that’s where I started. tailscale netcheck agrees on paper: Hong Kong nearest at 172 ms, Tokyo at 213 ms.

Every Hong Kong and Tokyo relay I tried was unreachable, and so was Singapore. China Telecom’s peering into Asian transit is bad enough that Nuremberg (199 ms) beats Tokyo before anything is blocked, and then the near ones are blocked anyway.

tailscale exit-node suggest is no better. Run twice it gave two different answers, my NAS in Boston (915 ms) and the netcup box (1146 ms), the two slowest machines I own, and never a Mullvad node. It ranks on geographic plausibility, which in China correlates with almost nothing.

My tools were lying to me

So measure it properly. Except both obvious ways to measure return failure for every node, everywhere:

• tailscale ping reports Online: true for Mullvad peers, but they carry no DERP relay and a zero LastHandshake. They’re WireGuard-only endpoints with no ping responder, so they time out from an uncensored network just the same.
• ICMP to the relay IP is dropped by Mullvad policy. 100% packet loss is the healthy result.

Both look exactly like a firewall block, which is a problem when you’re sitting behind a firewall. I produced a convincing table of 23 nodes BLOCKED before working out it measured nothing.

Sampling was the other trap. tailscale exit-node list shows one node per city, a 91-node window onto a 545-node problem, and the relay it picks is arbitrary. My first real pass tested 18 nodes off that list and concluded us-lax was the only one that worked.

What “working” even means here

The real test is switching to a node and fetching something through it, and what you fetch decides what the result means. I used speed.cloudflare.com, which was a mistake: it’s reachable from Shanghai directly, so passing it only proved traffic got to Cloudflare, not that it left the country.

google.com/generate_204 is the better probe: it times out on the raw line, so every success proves the tunnel got out, and a 204 is a clean thing to time.

One related thing to check before trusting any of it. Tailscale blackholes traffic when the exit node is dead, it doesn’t fall back to the direct route. I confirmed it by setting a known-blocked node and watching both targets time out. Had it failed open, every blocked relay would have quietly scored the same as no VPN and the dataset would be garbage.

Testing 545 nodes at 20 seconds each

tailscale set --exit-node rewrites the machine’s default route, so it’s global state. One node at a time, no parallelism, roughly 20 seconds each. That’s three hours of unusable internet for a full sweep.

So I screened cheaply first. Mullvad relays also listen on TCP 443 and 5001, and a TCP connect is fast, parallel, and doesn’t touch routing. Binding to the physical interface forces the probe onto the real Shanghai path rather than the current tunnel:

nc -z -w 5 -s "$(ipconfig getifaddr en0)" "$RELAY_IP" 443

Against nine nodes I already had real results for it matched seven, and both misses were TCP-open with WireGuard dead, so the screen only produces false positives and never discards a working node. 40-way parallel, all 545 in about two minutes, no disruption.

That leaves a funnel worth running serially:

I exit-node tested all 214, plus 24 of the silent ones as controls to check the screen wasn’t throwing away good nodes. All 24 controls failed for real.

Why most of them fail

The 545 land in three states, and the two failure modes are indistinguishable from the client.

The 331 are not dead servers. I probed 44 of them from Shanghai and Zurich in the same moment: none answered from Shanghai, all 44 from Zurich. They’re alive and serving the rest of the world while packets from my line vanish.

It’s 331 rather than a handful because Mullvad rents its servers from hosting companies and publishes the whole relay list, IPs included, at api.mullvad.net. Anyone can enumerate every relay and the netblock it sits in, and blocking a contiguous range is one rule that removes dozens at once. So results sort by landlord, not geography:

DataPacket and Tzulo hold nearly the same number of relays in mostly the same cities, and nine answer against ninety-four. It’s also the only cheap way to narrow the field: start with Tzulo and three in four answer, start with 31173 and it’s one in seven. It says nothing about speed though, and my fastest node is on M247, which only gets 31 of 84 through.

The 66 are a different mechanism. They reply on TCP 443, so packets reach the host, and WireGuard still won’t come up. WireGuard runs over UDP and its handshake is two fixed-size packets: a 148-byte initiation and a 92-byte response, message type in the first byte. Trivial signature to match, and these are plain WireGuard with no obfuscation on top. When the response never arrives the client keeps retrying, so the node reads as online and moves nothing. TCP and UDP are filtered independently here: 66 with TCP open and WireGuard dead, none the other way round.

Picking between the survivors

Single measurements were too noisy to rank anything. Vienna gave me 614 ms once and 1120 ms the next time.

So I ran rounds instead: every candidate measured once per round, five rounds, rotating the starting position each time so no node permanently sat in the slot right after a teardown.

One pass would have picked the wrong node. On the single-sample run 504 looked like a mediocre 591 ms and its sibling 502 looked like the winner. Same city, same provider, a stable 76 ms apart, so the specific host matters and getting the city right only takes you part of the way. The raw line is also the least consistent row here, SD 20.7 against Zurich’s 6.3.

The latency trap

Throughput can’t rank these. Everything landed between 19.5 and 22.9 Mbit/s including the no-VPN baseline, so that ceiling is my Shanghai uplink rather than the relays.

It still has to be measured, because of nodes like jp-tyo-wg-203. Lowest latency of all 148 at 457 ms, which would make it the headline answer, and 1.3 Mbit/s. An order of magnitude under the cap, useless for anything but a shell, and ten of the 148 are like it.

So it’s a floor test then a ranking: drop anything under 15 Mbit/s, sort what’s left by ping. Seven nodes clear both. Reverse the order and the traps sit just far enough down a ping-sorted list to look respectable.

How long this stays true

Not long. Six Tzulo nodes that worked in the morning still worked ten hours later, and one xtom node flipped from dead to working in the same window. But six nodes that passed the sweep were dead an hour later, and five hostnames I’d tested that morning had vanished from Mullvad’s API by evening.

So the provider pattern survives a day and individual hostnames don’t. Whether the same providers are blocked on China Unicom or from another province, I have no idea. I have one connection.

Notes if you redo this

• Poll until the first request succeeds instead of sleeping a fixed 15 s. Working nodes settle in 1 to 7 s and only failures pay the full timeout.
• Keep that window generous anyway. The slowest genuine handshake I recorded was 41 s, and a 4 s settle falsely killed us-lax, which showed a 7.3 s cold start against a 674 ms warm steady state.
• Measure warm and take a median. Single samples move by 100 ms or more.
• Always trap a restore, or a sweep that dies halfway leaves you stranded on a blocked exit node in a country where that’s annoying to fix.
• Write results to disk as you go and skip anything already recorded. Mine ran as about 10 resumable chunks, each restoring a known-good node before exiting.

None of this is obfuscated, which is the real caveat. Tailscale’s Mullvad integration is plain WireGuard against published relay IPs, so 148 working nodes is a comfortable margin right up until someone runs the same enumeration I did. If you want something durable rather than something that currently works, the Mullvad app with QUIC or Shadowsocks is the sturdier route.

Recheck: August 12, 2026

I reran a smaller comparison from the same Shanghai connection while using the personal netcup server in Nuremberg as the active Tailscale exit node. It was a direct Tailscale path to 46.38.241.43:41641, not DERP, and the observed egress IP was in Nuremberg.

networkQuality measured both paths over the active utun5 interface. Five warm Cloudflare requests through San Jose had a 726 ms median time to first byte; the five Germany requests had an 803 ms median. GitHub requests were variable on both paths, so they are not suitable as a ranking metric here.

The previously winning Zurich exits are no longer usable on this connection. ch-zrh-wg-503 and ch-zrh-wg-504 appeared as direct Tailscale peers but carried no payload traffic: three HTTPS requests to 1.1.1.1 each timed out at ten seconds. This is why the old table is a shortlist, not a permanent configuration.

I extended the recheck across the currently advertised Japan, Hong Kong, Singapore, US West Coast, Zurich, Frankfurt, and Barcelona nodes. jp-tyo-wg-203.mullvad.ts.net is the clear current winner: five warm Cloudflare requests had a 380 ms median time to first byte, compared with 690 ms through San Jose, 793 ms through Zurich 502, and 803 ms through Nuremberg. A 100-packet ICMP run to Cloudflare was lossless with a 138 ms average round trip.

All other advertised Japan hosts were unreachable in this run, including Tokyo 001, 002, 201, and 202 and every Osaka host. Hong Kong, Singapore, Seattle, San Francisco, Barcelona, and the tested Frankfurt host were also unreachable. A geographically close city is therefore still not a useful selection rule.

For now, use jp-tyo-wg-203.mullvad.ts.net as the default. Keep us-sjc-wg-001.mullvad.ts.net as the working US fallback and netcup-machine when a German IP address matters.

Using Mullvad through Tailscale

The Mullvad add-on makes Mullvad relays available as Tailscale exit nodes. It is separate from the Mullvad desktop app: no mullvad CLI or account login is needed on this Mac when the Tailscale add-on is already enabled on the tailnet.

# See the available Mullvad locations.
tailscale exit-node list --filter="United States"

# Route all internet traffic through the currently fastest measured Mullvad exit.
tailscale set --exit-node=jp-tyo-wg-203.mullvad.ts.net

# Confirm the selected node and external egress location.
tailscale status
curl -sS https://ipinfo.io/json

# Return to the personal Germany exit node.
tailscale set --exit-node=netcup-machine

# Stop using any exit node while retaining ordinary Tailscale access.
tailscale set --exit-node=

Use a specific hostname, not just a country, for a repeatable result. The command below asks Tailscale for a suggestion, but it should be treated as a candidate to measure rather than an answer.

tailscale exit-node suggest

The integration provides plain WireGuard exits. If those become unreachable from Shanghai, switch to the Mullvad app and use one of its anti-censorship transports instead; Tailscale’s Mullvad exit nodes do not provide that obfuscation.

Appendix: every node

All 545 relays, working first. Sort any column. The 331 no response rows are here on purpose: they’re most of the fleet, so leaving them out would hide how likely a blind pick is to fail, and sorting them by provider is what makes the netblock pattern visible. The 24 marked (control) never answered TCP but were exit-node tested anyway to check the screen; all 24 failed.

Ping and throughput were measured in the same visit. Throughput is a 4 MB transfer, so compare rows against each other; the absolute figure understates the link. A ★ marks the nine finalists, whose ping is a 5-round mean.