Tailscale on 猫猫鱼的小窝

阿里云 ECS 控制台远程连接失败、云助手不响应、OSS 内网超时——Tailscale 与阿里云 100.x 段冲突排查全过程

xxx@example.com (catcatyu) — Wed, 10 Jun 2026 12:40:15 +0800

阿里云 ECS 控制台远程连接失败、云助手不响应、OSS 内网超时——Tailscale 与阿里云 100.x 段冲突排查全过程

作者：catcatyu（xxx@example.com）

一、现象：从控制台远程连接打不开开始

某天准备登一台跑在杭州地域的阿里云 ECS 改点东西，结果发现三件事同时挂了：

阿里云控制台的「远程连接」（Workbench / VNC）打不开，点击之后转圈，最后报 “连接失败”；
「云助手」（Cloud Assistant / ECS Run Command）也不响应，下发任何命令都一直显示「执行中」，永远不返回结果；
业务侧报错：访问 oss-cn-hangzhou-internal.aliyuncs.com（OSS 内网域名）超时，对象读写全部 hang 住。

但是奇怪的是：

SSH（外网公网 IP）还能正常登录；
ping 8.8.8.8、ping baidu.com 都通；
业务里访问外网 API 也都正常。

这就说明 ECS 本身和外网都没问题，坏的是阿里云自己的内网链路——控制台远程连接、云助手、OSS 内网域名，全都走阿里云内网 100.x 段。

这台机器装了 Tailscale 自建 Headscale，这是个非常重要的伏笔。

二、最小化复现：定位到内网域名超时

先确认 OSS 内网到底是 DNS 挂了还是网络挂了：

1
2
3
4


$ nslookup oss-cn-hangzhou-internal.aliyuncs.com
Name:   oss-cn-hangzhou-internal.aliyuncs.com
Address: 100.118.28.52
Address: 100.118.28.43

DNS 没问题，解析出来两个 100.118.x.x 的地址。

1
2
3


$ timeout 10 telnet 100.118.28.52 443
Trying 100.118.28.52...
（10 秒之后超时）

TCP 不通。再 ping 一下 ECS metadata 服务器（这也是阿里云内部接口）：

1
2


$ ping -c 3 100.100.2.136
3 packets transmitted, 0 received, 100% packet loss

也不通。再试一下 metadata HTTP 接口：

1
2


$ curl --connect-timeout 5 http://100.100.100.200/latest/meta-data/region-id
（超时，无输出）

也不通。结论：凡是阿里云内网 100.x.x.x 段，全部访问不到。

到这里就明确了：阿里云控制台远程连接挂掉、云助手不响应，本质上跟 OSS 内网挂掉是同一个问题——它们都需要走 ECS 到 100.x 阿里云内网管控面的链路。

三、排查防火墙

第一反应是 ufw 或者 iptables 把内网段拦了。

1
2


$ sudo ufw status verbose
Status: inactive

ufw 是关的。再看 iptables：

1
2
3
4
5
6
7
8
9


$ sudo iptables -L -v -n
...
Chain ts-input (1 references)
 pkts bytes target  prot opt in        out  source            destination
    0     0 ACCEPT  0   --  lo         *    100.64.0.1        0.0.0.0/0
    0     0 RETURN  0   --  !tailscale0 *   100.115.92.0/23   0.0.0.0/0
 113K 5983K DROP    0   --  !tailscale0 *   100.64.0.0/10     0.0.0.0/0
 189K   26M ACCEPT  0   --  tailscale0  *   0.0.0.0/0         0.0.0.0/0
...

罪魁祸首找到了。

ts-input 是 Tailscale 自己装的 iptables 链，最关键的是这条：

DROP  !tailscale0  100.64.0.0/10  0.0.0.0/0

翻译一下：从不是 tailscale0 的网卡进来的包，只要源地址在 100.64.0.0/10 这个段里，全部丢掉。

而这条 DROP 已经累积了 113000+ 个被丢的包，将近 6MB 流量——所有访问阿里云内网失败的包，都被这条规则吞了。

四、根因：CGNAT 段撞车

为啥 Tailscale 要装这条 DROP？

Tailscale（包括自建 Headscale）默认使用 100.64.0.0/10 这个 CGNAT（运营商级 NAT）地址段给 tailnet 里的节点分配虚拟 IP。这条 DROP 是 Tailscale 的反伪造防御：从外部网卡进来的包，源 IP 不可能是 tailnet 内部地址，如果有那就是欺骗，丢掉。

但是！ 阿里云华东 1（杭州）的内网管控面，也用了 100.x 段：

资源	地址段
Tailscale CGNAT（虚拟）	`100.64.0.0/10`（即 `100.64.0.0` ～ `100.127.255.255`）
阿里云 ECS metadata	`100.100.100.200`、`100.100.2.136`
阿里云 OSS 内网（杭州）	`100.118.28.0/24` 等
阿里云云助手/Workbench 回调	部分 100.x 段

它们全在 100.64.0.0/10 区间内。

链路是这样的：

ECS 发起对 100.118.28.52（OSS 内网）的连接，包从 eth0 出去，OSS 服务回包；
回包从 eth0 进来，源 IP 是 100.118.28.52；
进了 INPUT 链 → ts-input 链；
源 IP 在 100.64.0.0/10 里 + 进来的网卡不是 tailscale0 → DROP；
应用层看到的就是连接超时。

控制台远程连接打不开、云助手不响应，也是同样的机制：阿里云管控面发到这台 ECS 的回调走的就是这条链路，全被丢了。

五、修复方案

方案 A：关掉 Tailscale 的 netfilter 接管（推荐）

最干净的办法是让 Tailscale 不要再托管 iptables，让默认 ACCEPT 策略接管。

1
2


$ sudo tailscale set --netfilter-mode=off
Warning: netfilter=off; configure iptables yourself.

这条命令告诉 tailscaled：「我不要你的 iptables 规则」。之后 tailscaled 会把它自己加的 ts-input、ts-forward 等链清掉。

立刻验证：

1
2


$ curl --connect-timeout 5 http://100.100.100.200/latest/meta-data/region-id
cn-hangzhou

通了！再试 OSS：

1
2
3


$ curl -sI http://oss-cn-hangzhou-internal.aliyuncs.com
HTTP/1.1 404 Not Found
Server: AliyunOSS

Server: AliyunOSS 头就证明已经打到 OSS 了（404 是因为我们没指定 bucket，正常）。同时阿里云控制台的远程连接和云助手也都恢复。

代价：失去了 Tailscale 自己装的「外部网卡上源 IP 伪造成 CGNAT 段的包丢掉」这条防御。但是在阿里云 VPC 内部，攻击者要伪造这种源 IP 包到你的 ECS，几乎做不到（VPC 自身的 underlay 会先把它清掉）。所以这个防御在 VPC 场景下几乎没有实际作用，关掉是安全的。

而且对 Tailscale 的实际功能没有影响：

tailscale0 接口还在；
节点间互相访问还能走；
路由还是好的；
唯一不工作的就是那条没意义的 DROP。

方案 B：保留 netfilter，加豁免规则（不推荐）

如果非要保留 Tailscale 的完整 iptables 规则，可以加一条豁免，让阿里云 OSS 段不被 DROP：

1
2


# 在 ts-input 链的 DROP 规则之前插入豁免
sudo iptables -I ts-input 3 -s 100.118.0.0/16 -j RETURN

但是这条规则不持久：

tailscaled 重启时会重建 ts-input 链，豁免被冲掉；
tailscaled 运行时如果对账（比如对端变化、ACL 推送），也可能重建。

要让它持久得写 systemd drop-in：

1
2
3
4
5
6
7
8
9


sudo mkdir -p /etc/systemd/system/tailscaled.service.d/
sudo tee /etc/systemd/system/tailscaled.service.d/aliyun-exception.conf > /dev/null <<'EOF'
[Service]
ExecStartPost=/bin/sh -c 'sleep 3 && \
  /usr/sbin/iptables -C ts-input -s 100.118.0.0/16 -j RETURN 2>/dev/null || \
  /usr/sbin/iptables -I ts-input 3 -s 100.118.0.0/16 -j RETURN'
EOF
sudo systemctl daemon-reload
sudo systemctl restart tailscaled

但是 tailscaled 启动到 ExecStartPost 跑完之间仍然有几秒的窗口期，OSS 会短暂断连。所以一般场景下我还是推荐方案 A。

还要注意：上面的豁免段 100.118.0.0/16 只覆盖了杭州地域的 OSS。如果你的 ECS 在别的地域、或者要访问别的内网服务（如 RDS、Redis 内网），需要查到对应的 100.x 段一起豁免。最稳的查法是直接 nslookup 对应内网域名拿 IP，再确定它的 /16 或 /24。

方案 C：换 Tailscale 的 IP 段（理论上可行，但复杂）

Headscale 配置文件里可以改 prefixes.v4：

1
2


prefixes:
  v4: 100.64.0.0/10  # 默认

如果改成不和阿里云冲突的段（比如自建一个 RFC1918 段），就能彻底避开。但是：

所有已注册节点都要重新分配 IP；
部分 Tailscale 客户端对非 CGNAT 段的支持有限制；
改完 ACL、DNS 都要重写。

对于个人/小团队的 Tailscale 部署，这个改动成本远大于方案 A。不推荐。

六、为什么阿里云控制台和云助手也会挂

很多人不理解：我自己访问 OSS 失败可以理解，控制台远程连接、云助手为什么会跟着挂？

是因为这两个东西的工作机制：

云助手（Cloud Assistant）：ECS 里跑了一个 AliyunAssistClient 守护进程，它需要主动连接阿里云内网的管控接口拉取要执行的命令。这个接口的接入点同样是 100.x 内网地址，被 DROP 之后客户端连不上服务器，控制台下发的命令就永远是「执行中」。
控制台远程连接（Workbench/VNC）：浏览器走的是阿里云控制台 → 阿里云内网中转 → ECS metadata/agent 通道。中转回来的握手包源 IP 在 100.x 段，被同一条 DROP 吞掉。

所以这是个典型的「打开了 Tailscale 之后阿里云任何依赖内网管控的功能都坏」综合症，看到一个症状要联想到一片。

七、检查清单

如果你在阿里云上跑了 Tailscale / Headscale 并且遇到下面任何一个症状，都先去看 iptables -L ts-input -n -v 那条 DROP 的 pkts 计数：

控制台「远程连接」打不开；
「云助手」下发的命令永远不返回；
curl http://100.100.100.200/latest/meta-data/ 超时（元数据服务）；
OSS 内网域名 oss-*-internal.aliyuncs.com 超时；
RDS、Redis 内网连接超时；
SLS 日志服务内网接口超时；
系统初始化时 cloud-init 卡很久；
ECS 自动续费、自动伸缩等管控操作异常。

如果 DROP 计数在涨，基本就是这个问题，按方案 A 关掉 netfilter 即可。

八、复盘

这个坑挺典型，关键学习点：

DROP 链的统计计数是最快的指纹。iptables -L -v -n 看到一条 DROP 规则上有大量 pkts/bytes 累积，就要立刻怀疑它。
CGNAT 段 100.64.0.0/10 是公开标准段（RFC 6598），任何使用方都不能假定自己独占。阿里云、Tailscale、容器网络、Kubernetes 的 Cilium 等等都可能占用这个段，多个一起装就容易撞车。
「我看到的症状」和「真正的根因」之间通常隔了几层。最初看到的是控制台远程连接失败，最后定位到的是 Tailscale 的 iptables 规则——中间隔着 OSS 超时、metadata 超时、DROP 计数三层证据。
本地 SSH 还能用的时候不要急着重启。这种 iptables 规则问题，重启不会修，只会让你失去能继续排查的入口。

排查工具备忘：

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


# DNS
nslookup oss-cn-hangzhou-internal.aliyuncs.com

# TCP 探测
timeout 10 telnet  

# 看防火墙状态
sudo ufw status verbose
sudo iptables -L -v -n
sudo iptables -L ts-input -v -n   # 直接看 Tailscale 链

# Tailscale 状态
tailscale debug prefs | grep -i netfilter
tailscale status

# Aliyun metadata 自检
curl --connect-timeout 5 http://100.100.100.200/latest/meta-data/region-id

# 关 Tailscale netfilter（修复）
sudo tailscale set --netfilter-mode=off

本文2026-06-10首发于猫猫鱼的小窝，最后修改于2026-06-10

Headscale + Tailscale + sing-box for Android：利用家宽打洞实现公司环境安全“科学上网”

xxx@example.com (catcatyu) — Fri, 08 May 2026 17:10:00 +0800

Headscale + Tailscale + sing-box for Android：利用家宽打洞实现公司环境安全“科学上网”

作者：catcatyu（xxx@example.com）

背景

在当前的工作环境下，公司对网络合规和出口流量审计的要求日益严苛。办公网络不仅严查各类 VPN 协议，还会对所有通往境外的连接记录进行深度审计。为了在满足个人上网需求的同时，彻底避免将个人设备的代理链路暴露在办公网络出口上，我构建了一套基于“组网即代理”的方案。

核心思路是利用家里的宽带作为唯一的“科学上网”出口，而办公环境下的手机仅作为一个纯粹的内网接入点，通过自建的 Tailscale 网络连接回自家的电脑进行“打洞”。具体设计动机如下：

规避办公网审计：通过将真正的代理入口放在家里的 Windows 电脑上，手机在办公网环境下只产生与国内服务器（阿里云）或家宽公网 IP 的通信。所有对境外的访问流量均被封装在隧道内部，并最终在家宽出口解封，从而确保办公网出口没有任何境外 IP 的访问记录。
阿里云控制面（Headscale）：为了实现稳定且不经过境外的控制平面，我在国内的阿里云 ECS 上部署了 Headscale（Tailscale 的开源替代方案）。需要注意，阿里云在这里仅作为**控制面（Control Plane）**负责节点发现和 NAT 穿透握手，并不负责数据中转。流量最终是通过 P2P 打洞直连到家里的，这样既保证了低延迟，也避免了阿里云因流量中转产生高昂的带宽费用。
完全物理隔离：本方案实现了个人访问链路与办公网络的物理级隔离。办公网出口看到的只是前往阿里云的合规 HTTPS 流量，真正的互联网访问逻辑完全托管在自有设备和自有宽带上。

整体思路

阿里云 ECS 上部署 Headscale，作为 Tailscale 控制面（仅负责握手，记得关闭或不使用 DERP 中转，以节省阿里云流量）。
家里的 Windows 电脑 加入这个 tailnet，作为代理网关，获得内网 IP 100.64.0.2。
家里电脑 本地运行 SOCKS5 服务（如 Clash/v2ray），并监听 100.64.0.2:10808 端口。
Android 手机 使用 sing-box for Android，通过内置的 Tailscale endpoint 登录 Headscale。
手机流量路由：Android 的 TUN 流量通过 Tailscale 隧道转发到家里的 100.64.0.2:10808。

技术架构示意图：

  flowchart LR
  subgraph Phone["Android 手机"]
    App["App 流量"]
    Tun["sing-box TUN"]
    TsEndpoint["Tailscale endpoint
ts-ep"]
  end

  subgraph Cloud["阿里云 ECS"]
    Headscale["Headscale 控制面
:8443"]
  end

  subgraph Home["家里宽带"]
    Windows["Windows 网关
100.64.0.2"]
    Socks["SOCKS5 服务
100.64.0.2:10808"]
    HomeWan["家里宽带出口"]
  end

  App --> Tun --> TsEndpoint
  TsEndpoint -.->|登录 / 节点发现 / NAT 打洞| Headscale
  TsEndpoint ==>|加密 tailnet 连接| Socks
  Windows --- Socks
  Socks --> HomeWan

这样手机侧的链路是：

1
2
3
4
5
6


Android App 流量
  -> sing-box TUN
  -> sing-box 内置 Tailscale endpoint (通过阿里云 Headscale 握手)
  -> tailnet 内内的 100.64.0.2:10808 (加密隧道)
  -> 家里电脑上的 SOCKS5 代理
  -> 家里宽带出口 (真正的境外访问发生在这里)

注意：这只是个人设备访问个人授权网络的记录。实际使用时要严格遵守所在单位、学校和网络服务提供方的安全合规准则。

版本要求

Android 端需要使用支持 sing-box 1.14 新字段的 SFA/sing-box 版本。实测 sing-box for Android 1.14.0-alpha.21 以上可用。

低版本如果导入下面的配置，可能会报类似错误：

1

unknown field accept_search_domain

原因是 accept_search_domain、control_http_client、dns_mode、preferred_by 等字段属于较新的 sing-box 配置格式。

Headscale 服务端配置

服务端部署在阿里云 ECS，公网地址、域名和密钥在这里都做了脱敏。

采集到的版本：

1

headscale version v0.28.0

配置文件路径：

1

/etc/headscale/config.yaml

核心配置如下：

 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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


server_url: https://:8443
listen_addr: 0.0.0.0:8443
grpc_listen_addr: 127.0.0.1:50443
metrics_listen_addr: 127.0.0.1:9090

database:
  type: sqlite
  sqlite:
    path: /var/lib/headscale/db.sqlite
    write_ahead_log: true

prefixes:
  allocation: sequential
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

dns:
  magic_dns: true
  base_domain: 
  override_local_dns: true
  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1
      - 2606:4700:4700::1111
      - 2606:4700:4700::1001

derp:
  auto_update_enabled: false
  paths:
    - /etc/headscale/derp-stun-only.yaml
  server:
    enabled: true # 启用内置 STUN，继续监听 UDP 3478
    automatically_add_embedded_derp_region: false # 不把内置 DERP 加入 DERP map，避免客户端走 DERP 中转
    region_id: 999
    region_code: headscale
    region_name: Headscale Embedded DERP
    stun_listen_addr: 0.0.0.0:3478
    private_key_path: 
    verify_clients: true
  urls: []
  update_frequency: 3h

noise:
  private_key_path: 

tls_cert_path: /path/to/.cer
tls_key_path: /path/to/.key

同时创建 /etc/headscale/derp-stun-only.yaml，只下发 STUN，不提供可用 DERP 中继。这里可以配置多个 STUN 节点，让客户端在多出口网络里探测到更多 NAT 映射候选：

  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
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178


regions:
  999:
    regionid: 999
    regioncode: stun-self
    regionname: Self STUN
    nodes:
      - name: 999a
        regionid: 999
        hostname: 
        ipv4: 
        stunport: 3478
        derpport: 1

  1000:
    regionid: 1000
    regioncode: stun-ali
    regionname: Public STUN 39.107
    nodes:
      - name: 1000a
        regionid: 1000
        hostname: 39.107.142.158
        ipv4: 39.107.142.158
        stunport: 3478
        derpport: 1

  1001:
    regionid: 1001
    regioncode: stun-hitv
    regionname: Public STUN HITV
    nodes:
      - name: 1001a
        regionid: 1001
        hostname: stun.hitv.com
        stunport: 3478
        derpport: 1

  1002:
    regionid: 1002
    regioncode: stun-miwifi
    regionname: Public STUN MiWiFi
    nodes:
      - name: 1002a
        regionid: 1002
        hostname: stun.miwifi.com
        stunport: 3478
        derpport: 1

  1003:
    regionid: 1003
    regioncode: stun-bilibili
    regionname: Public STUN Bilibili
    nodes:
      - name: 1003a
        regionid: 1003
        hostname: stun.chat.bilibili.com
        stunport: 3478
        derpport: 1

  1004:
    regionid: 1004
    regioncode: stun-cloudflare
    regionname: Public STUN Cloudflare
    nodes:
      - name: 1004a
        regionid: 1004
        hostname: stun.cloudflare.com
        stunport: 3478
        derpport: 1

  1005:
    regionid: 1005
    regioncode: stun-nextcloud
    regionname: Public STUN Nextcloud
    nodes:
      - name: 1005a
        regionid: 1005
        hostname: stun.nextcloud.com
        stunport: 3478
        derpport: 1

  1006:
    regionid: 1006
    regioncode: stun-nextcloud-443
    regionname: Public STUN Nextcloud 443
    nodes:
      - name: 1006a
        regionid: 1006
        hostname: stun.nextcloud.com
        stunport: 443
        derpport: 1

  1007:
    regionid: 1007
    regioncode: stun-google-1
    regionname: Public STUN Google 1
    nodes:
      - name: 1007a
        regionid: 1007
        hostname: stun1.l.google.com
        stunport: 19302
        derpport: 1

  1008:
    regionid: 1008
    regioncode: stun-google-3
    regionname: Public STUN Google 3
    nodes:
      - name: 1008a
        regionid: 1008
        hostname: stun3.l.google.com
        stunport: 19302
        derpport: 1

  1009:
    regionid: 1009
    regioncode: stun-google-4
    regionname: Public STUN Google 4
    nodes:
      - name: 1009a
        regionid: 1009
        hostname: stun4.l.google.com
        stunport: 19302
        derpport: 1

  1010:
    regionid: 1010
    regioncode: stun-voipbuster
    regionname: Public STUN Voipbuster
    nodes:
      - name: 1010a
        regionid: 1010
        hostname: stun.voipbuster.com
        stunport: 3478
        derpport: 1

  1011:
    regionid: 1011
    regioncode: stun-voipstunt
    regionname: Public STUN Voipstunt
    nodes:
      - name: 1011a
        regionid: 1011
        hostname: stun.voipstunt.com
        stunport: 3478
        derpport: 1

  1012:
    regionid: 1012
    regioncode: stun-sipnet
    regionname: Public STUN Sipnet
    nodes:
      - name: 1012a
        regionid: 1012
        hostname: stun.sipnet.net
        stunport: 3478
        derpport: 1

  1013:
    regionid: 1013
    regioncode: stun-telnyx
    regionname: Public STUN Telnyx
    nodes:
      - name: 1013a
        regionid: 1013
        hostname: stun.telnyx.com
        stunport: 3478
        derpport: 1

  1014:
    regionid: 1014
    regioncode: stun-twilio
    regionname: Public STUN Twilio
    nodes:
      - name: 1014a
        regionid: 1014
        hostname: global.stun.twilio.com
        stunport: 3478
        derpport: 1

这里的效果是：Headscale 继续提供 STUN 给 tailscale netcheck 和打洞探测使用，但 DERP 中继端口不可用，打洞失败时不会通过服务器中转流量。多 STUN 的意义是增加公网映射候选，尤其适合学校、公司这类可能按目标 IP 分配不同出口的网络；如果某个 STUN 服务器和真实 peer 目标走到同一个出口，直连打洞成功率会更高。

systemd 服务使用发行版默认的 headscale serve：

1
2
3
4
5
6
7
8


[Service]
User=headscale
Group=headscale
ExecStart=/usr/bin/headscale serve
Restart=always
WorkingDirectory=/var/lib/headscale
StateDirectory=headscale
RuntimeDirectory=headscale

节点列表脱敏后大概是这样：

1
2
3
4


100.64.0.1  headscale-server  linux
100.64.0.2  home-windows-pc   windows
100.64.0.3  other-windows-pc  windows
100.64.0.4  sfa-android       android

其中 100.64.0.2 是家里的 Windows 电脑，也是 Android 最终要访问的 SOCKS5 节点。

家里 Windows 电脑的 Tailscale 配置

Windows 端不需要额外写复杂配置，核心就是在 Headscale 服务端生成一个预授权 key，然后在 Windows 上用这个 key 加入自建控制面。

在 Headscale 服务端生成 Windows 节点使用的 key：

1

headscale preauthkeys create --user 1 --expiration 24h

如果希望这个 key 可以给多台设备重复使用，可以加 --reusable：

1

headscale preauthkeys create --user 1 --expiration 24h --reusable

然后在家里的 Windows 电脑上执行：

1

tailscale up --login-server https://<HEADSCALE_DOMAIN>:8443 --auth-key <WINDOWS_AUTH_KEY> --hostname home-windows-pc --accept-dns=true --accept-routes=true

这台电脑上需要有一个 SOCKS5 服务监听 10808。如果只监听 127.0.0.1:10808，tailnet 里的手机访问不到；需要确保它监听在 0.0.0.0:10808，或者至少监听到 Tailscale 网卡的 100.64.0.2:10808，同时 Windows 防火墙允许 tailnet 访问这个端口。

Android sing-box 配置

Android 端不要同时开官方 Tailscale App 的 VPN。Android 通常只能稳定运行一个 VPN，SFA 的 TUN 已经占用 VPN 入口，所以这里让 sing-box 自己内置一个 Tailscale endpoint。

Android 端同样需要先在 Headscale 服务端生成一个 auth key：

1

headscale preauthkeys create --user 1 --expiration 24h

如果只是给手机导入一次配置，建议使用一次性 key，不加 --reusable。生成出来的 key 填到下面 sing-box 配置的 auth_key 字段里。

完整配置如下，auth_key 已脱敏。这一份是基础版，默认最终出站都是家里电脑的 SOCKS5：

  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
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128


{
  "log": {
    "level": "info"
  },
  "dns": {
    "servers": [
      {
        "type": "local",
        "tag": "local"
      },
      {
        "type": "https",
        "tag": "remote-dns",
        "server": "1.1.1.1",
        "server_port": 443,
        "path": "/dns-query",
        "tls": {
          "server_name": "cloudflare-dns.com"
        },
        "detour": "proxy"
      },
      {
        "type": "tailscale",
        "tag": "ts-dns",
        "endpoint": "ts-ep",
        "accept_default_resolvers": false,
        "accept_search_domain": true
      }
    ],
    "rules": [
      {
        "domain": [
          ""
        ],
        "action": "route",
        "server": "local"
      },
      {
        "preferred_by": [
          "ts-dns"
        ],
        "action": "route",
        "server": "ts-dns"
      }
    ],
    "final": "remote-dns",
    "strategy": "prefer_ipv4",
    "timeout": "10s"
  },
  "endpoints": [
    {
      "type": "tailscale",
      "tag": "ts-ep",
      "state_directory": "tailscale-home",
      "auth_key": "",
      "control_url": "https://:8443",
      "control_http_client": {
        "domain_resolver": "local"
      },
      "hostname": "sfa-android",
      "accept_routes": true,
      "udp_timeout": "5m"
    }
  ],
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [
        "172.19.0.1/30",
        "fdfe:dcba:9876::1/126"
      ],
      "auto_route": true,
      "strict_route": true,
      "dns_mode": "hijack",
      "stack": "mixed",
      "endpoint_independent_nat": true
    }
  ],
  "outbounds": [
    {
      "type": "socks",
      "tag": "proxy",
      "server": "100.64.0.2",
      "server_port": 10808,
      "version": "5",
      "network": [
        "tcp",
        "udp"
      ],
      "detour": "ts-ep"
    },
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "block",
      "tag": "block"
    }
  ],
  "route": {
    "rules": [
      {
        "port": 53,
        "action": "hijack-dns"
      },
      {
        "action": "sniff"
      },
      {
        "preferred_by": [
          "ts-ep"
        ],
        "action": "route",
        "outbound": "ts-ep"
      },
      {
        "ip_is_private": true,
        "action": "route",
        "outbound": "direct"
      }
    ],
    "final": "proxy",
    "auto_detect_interface": true,
    "default_domain_resolver": "local"
  }
}

国内外分流版本

上面的基础版会把手机侧流量默认全部送到家里电脑的 100.64.0.2:10808。如果希望国内站点直连、国外站点仍然走家里 SOCKS5，可以使用下面这个分流版。它使用 geosite-cn、geoip-cn 做国内直连，使用 geosite-geolocation-!cn 做国外代理，国内 DNS 走 223.5.5.5，国外 DNS 走 Cloudflare DoH 并通过家里 SOCKS5 出口。没有命中规则的流量默认直连，避免微信这类国内 App 因规则缺失误走隧道。

这个版本会在首次启动时下载远程 .srs 规则集，后续由 cache_file 缓存。注意 cn-dns 这个 UDP DNS 服务器不要写 "detour": "direct"，新版 sing-box 会报 detour to an empty direct outbound makes no sense，因为 UDP DNS 默认就是直连。这里也不再全局阻断 UDP 443；阻断 QUIC 虽然能让部分连接回退到 TCP，但放在国内规则前面容易误伤微信、小程序和国内 App。

分流版完整配置如下，auth_key 和 Headscale 域名已脱敏：

  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
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340


{
  "log": {
    "level": "info"
  },
  "dns": {
    "servers": [
      {
        "type": "local",
        "tag": "local"
      },
      {
        "type": "udp",
        "tag": "cn-dns",
        "server": "223.5.5.5",
        "server_port": 53
      },
      {
        "type": "https",
        "tag": "remote-dns",
        "server": "1.1.1.1",
        "server_port": 443,
        "path": "/dns-query",
        "tls": {
          "server_name": "cloudflare-dns.com"
        },
        "detour": "proxy"
      },
      {
        "type": "tailscale",
        "tag": "ts-dns",
        "endpoint": "ts-ep",
        "accept_default_resolvers": false,
        "accept_search_domain": true
      }
    ],
    "rules": [
      {
        "domain": [
          ""
        ],
        "action": "route",
        "server": "local"
      },
      {
        "preferred_by": [
          "ts-dns"
        ],
        "action": "route",
        "server": "ts-dns"
      },
      {
        "domain": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "domain_suffix": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "action": "route",
        "server": "remote-dns"
      },
      {
        "rule_set": [
          "geosite-geolocation-!cn"
        ],
        "action": "route",
        "server": "remote-dns"
      },
      {
        "rule_set": [
          "geosite-category-ads-all"
        ],
        "action": "predefined",
        "rcode": "NOERROR"
      },
      {
        "rule_set": [
          "geosite-private",
          "geosite-cn"
        ],
        "action": "route",
        "server": "cn-dns"
      }
    ],
    "final": "cn-dns",
    "strategy": "prefer_ipv4",
    "timeout": "10s"
  },
  "endpoints": [
    {
      "type": "tailscale",
      "tag": "ts-ep",
      "state_directory": "tailscale-home",
      "auth_key": "",
      "control_url": "https://:8443",
      "control_http_client": {
        "domain_resolver": "local"
      },
      "hostname": "sfa-android",
      "accept_routes": true,
      "udp_timeout": "5m"
    }
  ],
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [
        "172.19.0.1/30",
        "fdfe:dcba:9876::1/126"
      ],
      "auto_route": true,
      "strict_route": true,
      "dns_mode": "hijack",
      "stack": "mixed",
      "endpoint_independent_nat": true
    }
  ],
  "outbounds": [
    {
      "type": "socks",
      "tag": "proxy",
      "server": "100.64.0.2",
      "server_port": 10808,
      "version": "5",
      "network": [
        "tcp",
        "udp"
      ],
      "detour": "ts-ep"
    },
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "block",
      "tag": "block"
    }
  ],
  "route": {
    "rules": [
      {
        "port": 53,
        "action": "hijack-dns"
      },
      {
        "action": "sniff"
      },
      {
        "preferred_by": [
          "ts-ep"
        ],
        "action": "route",
        "outbound": "ts-ep"
      },
      {
        "package_name": [
          "com.tencent.mm",
          "com.tencent.mobileqq"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "domain": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "domain_suffix": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "action": "route",
        "outbound": "proxy"
      },
      {
        "rule_set": [
          "geosite-category-ads-all"
        ],
        "action": "route",
        "outbound": "block"
      },
      {
        "rule_set": [
          "geosite-geolocation-!cn"
        ],
        "action": "route",
        "outbound": "proxy"
      },
      {
        "ip_is_private": true,
        "action": "route",
        "outbound": "direct"
      },
      {
        "rule_set": [
          "geosite-private"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "ip_cidr": [
          "223.5.5.5/32",
          "223.6.6.6/32",
          "2400:3200::1/128",
          "2400:3200:baba::1/128",
          "119.29.29.29/32",
          "1.12.12.12/32",
          "120.53.53.53/32",
          "2402:4e00::/128",
          "2402:4e00:1::/128",
          "180.76.76.76/32",
          "2400:da00::6666/128",
          "114.114.114.114/32",
          "114.114.115.115/32",
          "114.114.114.119/32",
          "114.114.115.119/32",
          "114.114.114.110/32",
          "114.114.115.110/32",
          "180.184.1.1/32",
          "180.184.2.2/32",
          "101.226.4.6/32",
          "218.30.118.6/32",
          "123.125.81.6/32",
          "140.207.198.6/32",
          "1.2.4.8/32",
          "210.2.4.8/32",
          "52.80.66.66/32",
          "117.50.22.22/32",
          "2400:7fc0:849e:200::4/128",
          "2404:c2c0:85d8:901::4/128",
          "117.50.10.10/32",
          "52.80.52.52/32",
          "2400:7fc0:849e:200::8/128",
          "2404:c2c0:85d8:901::8/128",
          "117.50.60.30/32",
          "52.80.60.30/32"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "domain": [
          "alidns.com",
          "doh.pub",
          "dot.pub",
          "360.cn",
          "onedns.net"
        ],
        "domain_suffix": [
          "alidns.com",
          "doh.pub",
          "dot.pub",
          "360.cn",
          "onedns.net"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "rule_set": [
          "geosite-cn"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "rule_set": [
          "geoip-cn"
        ],
        "action": "route",
        "outbound": "direct"
      }
    ],
    "rule_set": [
      {
        "type": "remote",
        "tag": "geosite-category-ads-all",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-category-ads-all.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geosite-geolocation-!cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-geolocation-!cn.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geosite-private",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-private.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geosite-cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-cn.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geoip-cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geoip/rule-set/geoip-cn.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      }
    ],
    "final": "direct",
    "auto_detect_interface": true,
    "default_domain_resolver": "local"
  },
  "experimental": {
    "cache_file": {
      "enabled": true,
      "store_dns": true
    }
  }
}

关键点是这个出站：

1
2
3
4
5
6
7


{
  "type": "socks",
  "tag": "proxy",
  "server": "100.64.0.2",
  "server_port": 10808,
  "detour": "ts-ep"
}

detour: ts-ep 表示连接 SOCKS5 服务本身时先走 Tailscale endpoint。没有这个字段，Android 的普通网络无法直接访问 100.64.0.2。

分流规则的关键点是：微信和 QQ 先按包名强制 direct，避免国内 IM 流量误走家里 SOCKS5；geosite-geolocation-!cn 明确送到 proxy，用于国外站点；final 保持 direct，让未知流量默认直连。不要把 UDP 443 阻断规则放在国内规则前面，否则微信、小程序或国内 App 的 QUIC/UDP 连接可能先被拦截，表现为发消息慢、加载卡顿。

启动顺序

Headscale 服务端先启动，确认 server_url 能访问。
家里 Windows 电脑登录 Headscale，确认拿到 100.64.0.2。
家里电脑启动 SOCKS5 服务，确认 100.64.0.2:10808 可访问。
Android 导入 sing-box 配置，启动 SFA。
在 Headscale 上查看 sfa-android 节点是否在线。

常用检查命令：

1

headscale nodes list

Windows 上检查：

1
2


tailscale status
tailscale debug prefs

NAT 类型也要检查一下。Tailscale 打洞最怕的是两端都是对称型 NAT；办公网这边是对称型 NAT 问题不大，只要家宽这一端不是对称型 NAT，通常仍然可以打出直连。如果两端都是对称型 NAT，P2P 直连大概率失败，最终会退回 DERP 中转。

在家里 Windows 电脑上跑：

1
2


tailscale netcheck
tailscale netcheck --format json

在办公网络侧也找一台同网段设备跑同样的命令：

1
2


tailscale netcheck
tailscale netcheck --format json

重点看输出里的 MappingVariesByDestIP。如果是 true，基本可以认为这一侧是对称型 NAT 或 hard NAT；如果是 false，打洞条件会好很多。本方案里最关键的是家宽侧尽量保持 MappingVariesByDestIP: false。

sing-box 配置可以先用本地源码检查：

1

go run -tags "with_gvisor,with_tailscale" ./cmd/sing-box check -c .\sing-box-android-tailscale.json

排错

如果 Android 报 unknown field accept_search_domain，升级 SFA/sing-box 到 1.14.0-alpha.21 以上。

如果 Android 能登录 Headscale 但不能访问 100.64.0.2:10808，先检查家里电脑上的 SOCKS5 是否监听在 Tailscale 可访问的地址上，再检查 Windows 防火墙。

如果 Headscale 控制面域名解析失败，确保 Android 配置里的 control_http_client.domain_resolver 指向 local，避免控制面解析也走还没建立起来的代理链路。

如果 DNS 查询异常，确认 dns_mode 是 hijack，并且 route.rules 里有 port: 53 的 hijack-dns 规则。

脱敏清单

这篇文章里隐藏了这些内容：

Headscale 服务器公网 IP。
Headscale 域名。
SSH 密码。
Tailscale auth key。
节点公钥、机器密钥和私钥路径。
证书文件真实路径。

真实环境里不要把 auth key、SSH 密码、私钥、节点 key 写进博客仓库。首次注册成功后，也建议把一次性 auth key 作废。

本文2026-05-08首发于猫猫鱼的小窝，最后修改于2026-05-08