How Myanmar Blocks Tailscale — and How to Beat It

A government blocks a VPN with an SNI filter. The fix is a custom relay on port 443. Tailscale could make this trivial for millions — but they haven't.

There's a lot of confusion about how Myanmar actually blocks Tailscale. Some say it's DNS poisoning. Others claim the coordination server is blackholed. A few insist the WireGuard protocol itself is detected and dropped.

None of that is correct. The block is simpler and stupider than most people think — and because of that, the counter is simpler too. This matters because Tailscale is genuinely important networking middleware. It's used by journalists, remote workers, distributed teams, and anyone who needs secure machine-to-machine connectivity. Blocking it isn't just censorship theater — it disrupts legitimate infrastructure.

This time, I worked on the problem with the support of a capable agentic AI. I trained its substantial capacity for research and systematic debugging on the task, and together we burned through the misconceptions, tested the actual failure points, and built a working counter. What follows is what we found.

Updated June 17, 2026 — This post has been corrected based on
reader feedback from Tailscale Support. Two factual errors have been
fixed: the SNI filter pattern was overstated, and Tailscale does
support removing default DERP relays via policy file. The corrections
are marked below.

What Myanmar Actually Blocks

Myanmar operates deep packet inspection (DPI) at the ISP level. The exact filter rule isn't public, but testing from inside the country reveals a clear pattern:

TLS ClientHello to DERP subdomains (derpN.tailscale.com) is dropped.
The coordination server (controlplane.tailscale.com) is not.

This hits Tailscale in three places:

An earlier version of this post claimed the filter was a blanket
`.tailscale.com wildcard. That was incorrect — if it were,
controlplane.tailscale.com` would be blocked too. The actual filter
appears to target DERP subdomains specifically.*

When all DERP relays are unreachable, nodes behind carrier-grade NAT in Myanmar have no path to each other. The mesh collapses. Every node is an island.

The cruel part: the coordination server still works. The client can see its peers. It knows they exist. It just can't reach them. It's like being locked in a glass box — you can see everyone, but you can't touch them.

The agent and I verified this step by step: DNS resolution from inside Myanmar, successful — the IPs resolve fine. TCP handshake to the coordination server, successful — it's not IP-blocked. TLS ClientHello to derpN.tailscale.com, dropped at the SNI. TLS ClientHello to a custom domain on the same VPS, passed cleanly. The filter is exactly one rule deep.

What Doesn't Work

Peer Relays (NAT-PMP/PCP). Tailscale's own documentation suggests custom DERP isn't needed if you set up a peer relay. But peer relays use raw UDP on arbitrary ports. DPI boxes flag non-standard UDP instantly. Port 40000 looks nothing like web traffic.

Waiting for it to get better. Myanmar's filtering isn't going away. It's getting more aggressive, not less.

Commercial VPNs. Most are blocked at the same DPI layer. The ones that work today won't work tomorrow.

What Works: Your Own DERP on Port 443

The insight is simple: TLS on port 443 looks like HTTPS to a DPI box. Every website uses it. Blocking it would break the internet.

A custom DERP relay listening on TCP 443, with a valid Let's Encrypt certificate on a domain you control, is indistinguishable from a web server. The SNI matches your domain, not a tailscale.com subdomain. The traffic is standard TLS. The DPI box shrugs and passes it through.

You can deploy this in 30 minutes:

1. Run cmd/derper on a VPS outside the censored country
2. Give it a Let's Encrypt certificate for a subdomain you control
3. Tell Tailscale to use it

But here's where Tailscale's product decision bites you.

The Problem: Two Clicks vs. a JSON File

You can remove Tailscale's default DERP relays — but not through the admin console.

Setting "OmitDefaultRegions": true in your tailnet policy file drops all default DERPs and uses only your custom ones. Tailscale's documentation covers this clearly:

{
  "derpMap": {
    "OmitDefaultRegions": true,
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "myderp",
        "Nodes": [
          {
            "Name": "1",
            "RegionID": 900,
            "HostName": "derp.example.com"
          }
        ]
      }
    }
  }
}

The catch: there's no checkbox in the admin console for this. You have to edit raw JSON in the access controls panel. For a feature that's the difference between "Tailscale works" and "Tailscale doesn't," that's a lot of friction — especially for users who've never touched a policy file before.

An earlier version of this post claimed default DERP removal was impossible and undocumented. Both were wrong — it's possible (via policy file) and documented (on Tailscale's site). The real issue is discoverability and the lack of a UI toggle.

The consequence of not using OmitDefaultRegions: your client will try the blocked default DERPs first. Each attempt times out after 5-10 seconds. Only after cycling through every blocked relay does it fall back to your custom one.

The result: Tailscale does connect eventually. But every connection attempt has a 20-40 second penalty. Every reconnect. Every network change. Every time your phone switches from WiFi to cellular.

It's functional but miserable — like a car that stalls three times before starting.

The Real Fix: Headscale

Headscale is the open-source implementation of the Tailscale coordination server. Self-hosting it gives you one thing Tailscale's SaaS doesn't: control over the DERP map.

With Headscale, you can:

• Add your custom DERP relay
• Remove every default Tailscale DERP
• Serve a DERP map with exactly one entry: your relay on port 443

No timeouts. No cycling through blocked relays. Your custom DERP is the only option, so clients go there immediately.

The deployment takes an afternoon:

VPS in Singapore
├── nginx :443 (SNI router)
│   ├── derp.yourdomain.com → derper container
│   └── hs.yourdomain.com → Caddy → Headscale
├── Headscale (coordination server)
├── Custom DERP relay (port 443, LE cert)
└── Headplane (web UI for management)

On the client side, joining is one command:

tailscale up --login-server=https://hs.yourdomain.com --authkey=YOUR_KEY

Add a Tailscale node as an exit node on the Singapore VPS, and every device on the tailnet can route its internet traffic through Singapore — free of Myanmar's filtering.

Total cost: one $5/month VPS.

A note on availability

If you're reading this and planning to deploy Headscale, consider forking or mirroring the repository before you need it. The DERP subdomain block works because it's easy. There's nothing stopping the same filter from being extended to github.com/juanfont/headscale — and after this article, that's a real possibility. Install from an alternate source. Host the binaries on your own domain. The pattern you use to beat the DERP block is the same pattern that keeps the tools themselves available.

What I'm Asking Tailscale to Do

Tailscale's engineering is excellent. The product decisions around DERP management are the problem.

Three changes would make Tailscale censorship-resistant for millions of people:

1. Add DERP controls to the admin console

This is the single highest-impact change. The policy-file OmitDefaultRegions field already works — you can remove default DERPs — but it's buried in raw JSON in the access controls panel. Adding a "DERP relays" section to the admin console where users can disable defaults and add customs with a click would solve the timeout problem without self-hosting anything.

2. Ship a one-click "censorship mode"

One toggle that:

• Disables all default DERPs
• Requires at least one custom DERP on port 443
• Sets aggressive timeouts so blocked relays don't stall connections

This isn't hypothetical. Iran, China, Russia, Turkey, and Myanmar all block Tailscale infrastructure. That's hundreds of millions of people who can't use the product because of a single wildcard SNI rule.

3. Document the DPI countermeasures

Tailscale's documentation on censorship circumvention is scattered across forum posts and GitHub issues. A single page — "Using Tailscale in Censored Networks" — would tell users what they need before they spend hours debugging timeouts.

Lessons

1. DPI is lazy. Myanmar's entire Tailscale block targets DERP subdomains at the SNI layer. Don't assume sophisticated adversaries — they're doing the minimum that works.
2. Port 443 is the universal blind spot. Every censorship system has to let HTTPS through. Put your tunnel traffic on 443 with a valid TLS cert and you're invisible.
3. Headscale isn't just for homelabs. The ability to control the DERP map is the difference between "barely functional" and "instant connection." For censored networks, it's not a luxury — it's the whole point.
4. Tailscale's DERP domains are a single point of failure. derpN.tailscale.com is a convenient pattern for DPI boxes to block. Custom domains break that pattern.
5. Exit nodes complete the picture. A relay gets you connectivity. An exit node gets you out.
6. Test before you trust. The coordination server at controlplane.tailscale.com was reachable from Myanmar when we tested. This can change. Self-hosting Headscale removes the last dependency on tailscale.com.
7. The gap between "works" and "works well" is 30 seconds. Without DERP map control, every connection has a built-in delay. That delay is the difference between a tool people use and a tool people abandon.
8. Mirror before you need it. The publication of this article may accelerate blocking of the Headscale repository. Fork it. Host the binaries yourself. Your infrastructure should not depend on a GitHub URL surviving a government filter.

Written with Hermes Agent. Follow me on X: @MariaTanBoBo