During several trips, I attempted to upload newly taken photos to my Immich server at home in Changsha. I used to rely on Cloudflare Tunnel for reverse proxying, but due to the particularities of the Chinese network environment, slow connections, frequent disconnections, and failed uploads became the norm. Later, I started experimenting with Tailscale — a NAT traversal tool based on WireGuard — and it finally allowed me to stably and quickly access my home NAS and photo library from anywhere in China.

However, a new problem emerged: when Tailscale runs on Android, it needs to take over the system traffic as a VPN service. Meanwhile, my usual tool Clash also relies on the VPN interface for traffic routing. Due to Android’s limitation of allowing only one VPN service at a time, the two cannot coexist. This meant I had to choose between “accessing home services” and “accessing the open internet”.

This article walks through the principles of Tailscale, how to set up your own DERP server to improve connection quality, and how to hijack traffic from a Tailscale Exit Node using iptables and forward it to ShellCrash, enabling flexible traffic routing and secure tunnelling. Whether you’re looking to access your home NAS or photo library remotely, or protect your data on untrusted networks, this guide offers a practical and stable solution.

What is Tailscale?

Tailscale is a zero-config virtual private network (VPN) tool based on the WireGuard protocol. It allows devices located in different network environments to communicate as if they were on the same secure local network. By automatically traversing NATs and firewalls, Tailscale enables access to your home NAS, personal servers, development environments, and other internal resources without requiring a public IP or port forwarding. Its key strengths lie in its simplicity, security, and stability — it’s ready to use out of the box, encrypts all traffic end-to-end, and is suitable for developers, remote workers, and home users alike.

Tailscale’s technical implementation is quite ingenious. It builds on the WireGuard encryption protocol but reimagines traditional VPN IP allocation. Each device authenticates using SSO/OAuth2 and receives a node key that is permanently bound to its identity. This identity-based networking model allows a “NAS in Changsha” and a “phone in Hong Kong” to communicate as if they were coworkers in the same office.

How Tailscale Establishes Connections

Control Server

When a Tailscale client starts, it first connects to the control server (controlplane) to authenticate and fetch information about other nodes in the network, including each device’s public IP, port, NAT type, etc. This step is essentially the “getting to know your peers” phase. The control server does not relay any traffic — it only coordinates connections, acting like a dispatcher.

DERP Servers

A key factor behind Tailscale’s high connection success rate is its custom relay protocol called DERP. In Tailscale’s architecture, DERP (Designated Encrypted Relay for Packets) is a crucial component that only steps in when needed. In simple terms, it’s an encrypted HTTP-based relay server that acts as an intermediary when two devices cannot connect directly. All clients initially connect via DERP (relay mode), meaning the connection is established instantly with no waiting. Then, both sides begin path discovery in parallel, and within a few seconds, Tailscale typically finds a better route and transparently upgrades the connection to a direct peer-to-peer tunnel.¹

Important notes:

• All traffic relayed via DERP is end-to-end encrypted, so DERP servers cannot see the content;
• Tailscale uses DERP only when necessary — once a direct connection is established, it automatically switches;
• Official DERP nodes are distributed globally, and clients automatically select the one with the lowest latency;
• You can also deploy your own DERP server (for example, within China) to improve latency and reliability. Think of DERP as a fallback mechanism — although it’s not as performant as direct connections, it ensures devices can always stay connected even when NAT traversal fails.

NAT Traversal

After obtaining the peer’s address info, Tailscale attempts to establish a peer-to-peer (P2P) connection via NAT traversal. This process uses the STUN protocol, where both sides send probe packets to try to punch a hole through the NAT router and create a direct UDP tunnel. If the network conditions allow, a direct tunnel is established, offering fast speeds and low latency.

Due to space constraints, we won’t go into detail about NAT traversal here. For more information, refer to Tailscale’s official article “How NAT traversal works”.

Full Connection Flow Diagram

flowchart TD
    A[Device A starts Tailscale] --> B[Initial connection via DERP server]
    B --> C[Exchange network info and WireGuard keys]
    C --> D[Both sides perform NAT type detection]
    D --> E{Direct connection possible?}
    E -- Yes --> F[Establish P2P tunnel]
    F --> G[Periodically check connection quality]
    G --> H{Is P2P better than DERP?}
    H -- Yes --> I[Switch most traffic to P2P]
    H -- No --> J[Continue relaying traffic via DERP]
    E -- No --> J
    style B fill:#e3f2fd,stroke:#2196f3,color:#000
    style F fill:#e8f5e9,stroke:#4caf50,color:#000
    style J fill:#fff3e0,stroke:#ff9800,color:#000

Hosting Your Own DERP Server

Tailscale installation is straightforward across platforms, and the official documentation covers it in detail. This article assumes you have already installed and logged into Tailscale on the relevant devices.

Why Host Your Own DERP?

Tailscale has deployed numerous DERP relay servers globally². However, for well-known reasons, there are no official DERP nodes within mainland China. This leads to the following issues:

• When NAT traversal fails, all traffic must be routed via overseas DERP nodes, resulting in high latency and poor performance;
• Some official DERP nodes may be disrupted by the Great Firewall (GFW), causing connection drops or handshake failures;
• Even when direct connections succeed, Tailscale still relies on DERP for exchanging route info and WireGuard keys — if DERP is unreachable, connection quality suffers.

Therefore, in the Chinese network environment, hosting a local DERP node can significantly improve connection stability and performance, while also avoiding unexpected issues caused by network restrictions — making it a worthwhile optimisation.

Prerequisites

As DERP is HTTP-based, you’ll need an HTTP reverse proxy and an SSL certificate. This guide uses Docker for deployment. Before proceeding, ensure your server has Docker and Docker Compose installed. You’ll also need basic knowledge of editors like nano to modify config files. For optimal results, your server should have a static public IPv4+IPv6 dual-stack address. If all requirements are met, you can begin deployment:

1
2

mkdir tailscale-derp && cd tailscale-derp
nano docker-compose.yml

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

services:
  derper:
    name: tailscale-derp
    image: fredliang/derper
    environment:
      - DERP_DOMAIN=derp.nightcity.pub
      - DERP_VERIFY_CLIENTS=true
      - DERP_ADDR=:4433
    network_mode: host
    restart: unless-stopped
    volumes:
      - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

The network_mode: host setting is crucial. It allows the container to share the host’s network stack. If Docker’s default bridge mode is used, the container’s network will be NATed, and the DERP STUN service will detect a 172.17.0.0/16 address instead of the client’s real public IP, causing connection issues.

1
2

volumes:
  - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

As mentioned earlier, DERP traffic is end-to-end encrypted, and DERP servers do not know who is using them. Without proper access control, anyone who knows your DERP address and port could use it. This volume mounts the Tailscale socket file into the container, allowing the DERP service to authenticate clients via the local tailscaled service. Combined with DERP_VERIFY_CLIENTS=true, it prevents freeloaders from using your DERP node.

Notes:

• Your host must already have the Tailscale client (tailscaled) installed and logged in, or the socket file won’t exist and the container will fail;
• tailscaled must run with root privileges to create this socket.

Reverse Proxy

Using Caddy as an example, reverse proxy port 4433 and deploy an SSL certificate:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
        email webmaster@l3zc.com
}
*.l3zc.com {
        encode gzip
        tls {
                dns dnspod APP_ID,APP_KEY
                resolvers 119.29.29.29 223.5.5.5
        }
        @derp host derp.l3zc.com
        reverse_proxy @derp :4433
}

Note: If you’re using MagicDNS with Caddy and DNS providers to request a wildcard certificate, you may encounter local certificate validation errors. Setting the resolvers parameter resolves this issue. Visit the proxied node — if you see the following page, the setup is correct:

Configuring ACL Policies

Go to the Tailscale admin console’s page and add your custom DERP configuration.

Tailscale’s ACL policies are written in HuJSON³. To edit in VSCode, set the language mode to “JSON with Comments (jsonc)”. Here’s an example configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

{
  "acls": [{ "action": "accept", "src": ["*"], "dst": ["*:*"] }],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"]
    }
  ],
  // Custom DERP configuration
  "derpMap": {
    "OmitDefaultRegions": false, // Set to true to exclude official DERPs
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "Shanghai",
        "Nodes": [
          {
            "Name": "myderp",
            "RegionID": 900,
            "HostName": "derp.l3zc.com"
          }
        ]
      }
    }
  }
}

Tailscale reserves RegionIDs 1–899 for official nodes. Custom DERPs must use IDs 900 and above.

Testing the Connection

Once you’ve saved your ACL configuration, Tailscale will automatically sync it to all clients. After a short wait, run tailscale netcheck on a client to test the connection:

Pay attention to whether the returned IP is your actual public IP. If it shows an address in the 172.17.0.0/16 range, your Docker configuration is incorrect.

Coexisting with Internet Access: Hijacking Exit Node Traffic to the Clash Engine

Declaring an Exit Node

Prepare a device at home that stays on 24/7 — this could be a Raspberry Pi or a Mac Mini. Install Tailscale and declare it as an Exit Node. You can also advertise your home LAN subnet if needed. Once enabled in the Tailscale console, this device becomes a free VPN, allowing you to securely access the internet from unfamiliar networks.

1

sudo tailscale up --advertise-exit-node --advertise-routes 192.168.1.0/24

Once broadcasting is complete, you can access all devices on your home network from anywhere in the world, as long as you’re connected to the Tailscale network.

Enabling IP Forwarding and Disabling UDP GRO⁴

Enabling IP forwarding is essential for devices like the Raspberry Pi to function as an Exit Node. The following commands are for Raspberry Pi — if you’re using a different device, refer to the official Tailscale documentation.

1
2
3

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

According to Tailscale⁵, disabling UDP GRO⁶ can improve forwarding performance. Although the official persistence method may not work on Raspberry Pi, we can configure it manually.

1
2
3
4

# Install ethtool
sudo apt update && sudo apt install ethtool -y
# Disable UDP GRO
sudo ethtool -K eth0 gro off

To persist this setting, create a systemd service:

1
2

# Create the service file
sudo nano /etc/systemd/system/ethtool.service

Add the following content:

1
2
3
4
5
6
7
8

[Unit]
Description=Configure eth0 GRO
After=network.target
[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth0 gro off
[Install]
WantedBy=multi-user.target

Then enable and start the service:

1
2
3

sudo systemctl daemon-reload
sudo systemctl enable ethtool
sudo systemctl start ethtool

Hijacking Traffic on the Exit Node

My Exit Node is a Raspberry Pi. After configuring it as an Exit Node, the final step is to hijack the traffic sent from my phone to the Exit Node in order to enable open internet access. For stability reasons, I prefer not to run proxy software directly on the main home router. Therefore, hijacking traffic on the Pi is the only viable solution.

First, install ShellCrash. Follow the prompts to import configuration files and set up automation as needed:

1

export url='https://fastly.jsdelivr.net/gh/juewuy/ShellCrash@master' && wget -q --no-check-certificate -O /tmp/install.sh $url/install.sh  && bash /tmp/install.sh && source /etc/profile &> /dev/null

Start the service and change the firewall mode to “Clean Mode”. I also recommend enabling SNI sniffing and switching the DNS mode from fake-ip to redir-host⁷, and enabling IPv6 transparent proxy.

Setting Clean Mode allows us to manually configure iptables for more precise traffic hijacking. Use ifconfig to check the Tailscale interface name — it’s usually tailscale0 by default:

1
2
3
4
5
6
7

root@raspberrypi:~# ifconfig
eth0: ......
tailscale0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet 100.111.19.50  netmask 255.255.255.255  destination 100.111.19.50
        inet6 fd7a:115c:a1e0::3d01:1332  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::c0d5:1a1b:2005:48eb  prefixlen 64  scopeid 0x20<link>
        ...

Hijack all traffic from tailscale0 to the local Clash engine’s listening port 7892. This is called the “static route port” in ShellCrash. Don’t forget to also hijack IPv6 traffic:

1
2
3
4

# IPv4: Hijack tailscale0 TCP traffic
iptables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892
# IPv6: Hijack tailscale0 TCP traffic
ip6tables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

Advanced: Hijacking UDP Traffic with TProxy

The iptables REDIRECT target can only redirect TCP traffic. Since UDP is a connectionless protocol, REDIRECT cannot retain the original destination address, which prevents transparent proxies from identifying the original destination.

So, if you attempt to hijack UDP traffic using a rule like this:

1

iptables -t nat -A PREROUTING -i tailscale0 -p udp -j REDIRECT --to-ports 7892

This rule will either not work or cause abnormal proxy behaviour.

Is there a way to proxy UDP traffic? Yes, indeed. But the prerequisites are:

• The proxy core must support UDP transparent proxying (Clash Premium and Mihomo both support this);
• You must use TProxy mode instead of REDIRECT;
• The iptables mangle table and policy routing must be correctly configured;
• UDP proxying must be enabled in the proxy configuration file (e.g. mode: rule and udp: true).

Assuming you’ve fulfilled the first, second, and last conditions, here is an example⁸:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Create a custom chain
sudo iptables -t mangle -N SHELLCRASH

# Exclude local traffic as needed
sudo iptables -t mangle -A SHELLCRASH -d 127.0.0.1/8 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 100.64.0.0/10 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 192.168.1.0/24 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 172.17.0.0/16 -j RETURN

# Mark TCP and UDP traffic for the proxy
sudo iptables -t mangle -A SHELLCRASH -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
sudo iptables -t mangle -A SHELLCRASH -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# Interface redirection
sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH

# Routing table configuration
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip rule add fwmark 233 lookup shellcrash
sudo ip route add local 0.0.0.0/0 dev lo table shellcrash

And of course, don’t forget about IPv6:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Create a chain
sudo ip6tables -t mangle -N SHELLCRASH6

# Exclude local addresses
sudo ip6tables -t mangle -A SHELLCRASH6 -d ::1/128 -j RETURN
sudo ip6tables -t mangle -A SHELLCRASH6 -d fd7a:115c:a1e0::/48 -j RETURN

# Mark TCP/UDP traffic
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# Interface redirection
sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6

# Routing table configuration
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip -6 rule add fwmark 233 lookup shellcrash
sudo ip -6 route add local ::/0 dev lo table shellcrash

Persisting Routing Rules

Rules created with ip rule and ip route are lost after a reboot, so we need to persist them manually. The simplest method is to create a script and add it to crontab.

Create a script:

1

sudo nano /usr/local/bin/policy-route.sh

Edit it as follows:

1
2
3
4
5
6
7
8
9

#!/bin/bash

# IPv4 policy routing
ip rule add fwmark 233 lookup 233
ip route add local 0.0.0.0/0 dev lo table 233

# IPv6 policy routing
ip -6 rule add fwmark 233 lookup 233
ip -6 route add local ::/0 dev lo table 233

After granting execution permissions, edit crontab:

1
2

sudo chmod +x /usr/local/bin/policy-route.sh
sudo crontab -e

Add the following line at the end of the crontab file:

1

@reboot /usr/local/bin/policy-route.sh

How It Works: How Does TProxy Forward UDP Traffic?

If you’ve read this far, you might be wondering: why, throughout the entire process, we never specified --to-ports in iptables, nor did we see the destination address being modified, yet UDP traffic was somehow successfully proxied? How is that possible?

To explain this, let’s first look at the fundamental differences between TProxy and REDIRECT:

REDIRECT Mode:

• Uses the iptables nat table;
• Rewrites the destination address to a local one (e.g. 127.0.0.1:7892);
• Typically used for TCP traffic;
• Cannot preserve the original destination address;
• Requires specifying --to-ports.

flowchart TB
    A[Client device
initiates TCP request via Tailscale]
    B[tailscale0 interface receives traffic]
    C[iptables NAT PREROUTING
REDIRECT --to-ports 7892]
    D[ShellCrash listens locally
on 127.0.0.1:7892]
    E[ShellCrash initiates new TCP connection
→ target server]
    F[Response returns from the network
ShellCrash forwards it]
    G[Response reaches client device]

    A --> B --> C --> D --> E --> F --> G

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style D fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TPROXY Mode:

• Uses the iptables mangle table;
• Does not modify the destination IP, preserving the original target;
• Uses fwmark and policy routing to route packets to lo;
• The proxy listens on a special port (e.g. 7893) with IP_TRANSPARENT enabled;
• Supports both UDP and TCP;
• No need to specify --to-ports in iptables since this is not NAT, but marking + routing.

flowchart TB
    A[Client device
initiates TCP/UDP request via Tailscale]
    B[tailscale0 interface receives traffic]
    C[iptables MANGLE PREROUTING
assign fwmark 233]
    D[ip rule: fwmark 233
use routing table shellcrash]
    E[ip route: local 0.0.0.0/0
dev lo table shellcrash]
    F[ShellCrash listens on lo:7893
in IP_TRANSPARENT mode]
    G[ShellCrash retrieves original destination
initiates proxy connection]
    H[Response returns from the network
ShellCrash forwards it]
    I[Response reaches client device]

    A --> B --> C --> D --> E --> F --> G --> H --> I

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style F fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TProxy does not use DNAT/REDIRECT. Instead, it marks packets using the mangle table, then uses policy routing (ip rule + ip route) to route those packets to the lo interface. The proxy application (e.g. Clash / ShellCrash) listens on a port on lo⁹, and with the IP_TRANSPARENT option enabled, it can read the original destination IP and port from the packet and forward the traffic accordingly.

In short, TProxy mode only requires:

• iptables to mark packets;
• ip rule + ip route to route them to lo;
• The proxy to listen on lo with IP_TRANSPARENT enabled.

Thus, there’s no need to specify --to-ports in iptables, because the destination IP and port remain unchanged, and the proxy can detect and handle them itself.

Persisting iptables Rules

Install iptables-persistent:

1
2

sudo apt update
sudo apt install iptables-persistent

During installation, you’ll be prompted to save the current IPv4 and IPv6 rules — select “Yes”. If you later add new rules, remember to save them:

1
2

# Save current IPv4/IPv6 rules
sudo netfilter-persistent save

Saved rules are stored in:

• IPv4: /etc/iptables/rules.v4
• IPv6: /etc/iptables/rules.v6

You can also edit the rules.v4/rules.v6 files directly as needed.

Final Result

The performance of this setup largely depends on your home network’s upload bandwidth. I have a 500Mbps down / 60Mbps up connection, and I haven’t encountered a single NAT traversal failure so far. Speeds are consistently high, latency is acceptable, and I can securely access my Immich server, OpenWRT router, and other home devices from anywhere with end-to-end encryption — all while enjoying unrestricted internet access. Overall, I’m quite satisfied with the solution.