Android on 猫猫鱼的小窝

解决 Google Play 在 v2rayNG 下卡在等待下载的问题

xxx@example.com (catcatyu) — Fri, 05 Jun 2026 20:30:00 +0800

解决 Google Play 在 v2rayNG 下卡在等待下载的问题

作者：catcatyu（xxx@example.com）

问题现象

一台 OnePlus / ColorOS 设备上，Google Play 可以打开，也能搜索应用，但是安装应用时一直显示“等待中”或者“正在等待下载”。设备已经 root，可以在 Termux 里使用 su 执行系统命令。

当时环境大致如下：

Android 16
Google Play 商店版本：40.1.20-23
Google Play 服务版本：26.19.34
v2rayNG：2.0.18
当前代理节点：TLS-Vision-Unlimited-IPv4

先排除常见问题

先看空间：

1

df -h /data /storage/emulated/0

结果 /data 可用空间还有几百 GB，所以不是空间不足。

再确认几个核心包是否存在：

1
2
3
4


pm path com.android.vending
pm path com.google.android.gms
pm path com.google.android.gsf
pm path com.android.providers.downloads

这些包都存在。root 下进一步看包状态：

1
2
3


su -c '/system/bin/dumpsys package com.android.vending | grep -E "versionName|lastUpdateTime|installerPackageName|User 0"'
su -c '/system/bin/dumpsys package com.google.android.gms | grep -E "versionName|lastUpdateTime|installerPackageName|User 0"'
su -c '/system/bin/dumpsys package com.android.providers.downloads | grep -E "versionName|User 0"'

结论：

Play 商店、Play 服务、GSF、下载管理器都没有被禁用。
Play 商店版本比较旧，最后更新时间停在 2025-03-12。
下载管理器正常启用。

清掉旧的卡死下载任务

一开始在下载管理器数据库里发现了一个旧的 Play 下载任务：

1

su -c 'content query --uri content://downloads/all_downloads'

其中有一条记录类似：

1
2
3
4
5


notificationpackage=com.android.vending
allowed_network_types=2
status=194
errorMsg=Binding socket to network 182 failed: EPERM (Operation not permitted)
uri=https://rr5---sn-a5mekn6r.gvt1.com/play-apps-download-default/download/by-id/...

这里有两个重点：

allowed_network_types=2 表示任务只允许 Wi-Fi。
Binding socket to network 182 failed 表示它还绑到了一个已经失效的网络。

删除这条旧任务：

1
2
3


su -c 'content delete --uri content://downloads/all_downloads/103519'
su -c 'am force-stop com.android.vending; am force-stop com.android.providers.downloads; am force-stop com.google.android.gms'
su -c 'cmd package clear --user 0 --cache-only com.android.providers.downloads; cmd package clear --user 0 --cache-only com.android.vending'

这一步可以解决旧任务残留导致的“等待中”，但本次问题还没有完全解决。

抓 Play 下载服务日志

重新点下载后，继续抓日志：

1

su -c 'logcat -d -t 3000 | grep -Ei "Finsky|DownloadService|CronetDownloader|CANNOT_CONNECT|ERR_QUIC|ERR_CONNECTION|WAITING_FOR_RETRY|RUNNING|QUEUED|gvt1|CronetUrlRequest"'

关键日志：

1
2
3
4


CronetDownloader: onFailed
Exception in CronetUrlRequest: net::ERR_CONNECTION_CLOSED
Download Service Error: CANNOT_CONNECT (8)
Updating listeners of <... QUEUED with WAITING_FOR_RETRY ...>

中间还出现过：

1

net::ERR_QUIC_PROTOCOL_ERROR

这说明 Play 不是真的单纯排队，而是下载服务连接失败后进入等待重试。

为了排除 QUIC/HTTP3 影响，我临时对 Play 和 GMS 禁了 UDP 443：

1
2


su -c 'iptables -I OUTPUT -p udp --dport 443 -m owner --uid-owner 10248 -j REJECT'
su -c 'iptables -I OUTPUT -p udp --dport 443 -m owner --uid-owner 10242 -j REJECT'

其中：

10248 是 Play 商店 UID。
10242 是 Google Play 服务 UID。

禁掉 UDP 443 后，QUIC 错误减少，但仍然出现 TCP 层的 ERR_CONNECTION_CLOSED，所以问题不只是 QUIC。

找到真正失败的域名

Play 的下载 URL 不一定直接出现在 logcat 里，可以复制它的本地数据库出来读：

1
2
3
4
5
6
7
8


su -c 'cp /data/data/com.android.vending/databases/download_service /tmp/play_download_service.db; chmod 644 /tmp/play_download_service.db'
python3 - <<'PY'
import pathlib, re
data = pathlib.Path('/tmp/play_download_service.db').read_bytes()
urls = sorted(set(m.decode('utf-8', 'ignore') for m in re.findall(rb'https?://[^\x00\s"\']+', data)))
for u in urls:
    print(u[:500])
PY

查到当前 Play 下载库里实际使用的是：

1

https://services.googleapis.cn/download/by-token/download?token=...

旧任务里还出现过：

1

https://rr5---sn-a5mekn6r.gvt1.com/play-apps-download-default/download/by-id/...

因此重点域名是：

1
2
3


services.googleapis.cn
redirector.gvt1.com
*.gvt1.com

本机连通性测试

直接在 Termux 里测试：

1
2
3
4


curl -I --connect-timeout 10 https://services.googleapis.cn
curl -I --connect-timeout 10 https://redirector.gvt1.com
curl -I --connect-timeout 10 https://rr5---sn-a5mekn6r.gvt1.com
curl -I --connect-timeout 10 https://play.googleapis.com

一开始结果是：

1
2
3
4


services.googleapis.cn      TLS connect error: unexpected eof while reading
redirector.gvt1.com         TLS connect error: unexpected eof while reading
rr5---sn-a5mekn6r.gvt1.com  HTTP/1.1 404 Not Found
play.googleapis.com         HTTP/2 404

404 在这里反而说明 TLS 和 HTTP 都是通的，只是访问根路径不是有效接口。真正有问题的是 unexpected eof while reading，也就是 TLS 握手阶段被断开。

为了判断是不是域名本身的问题，又用 check-host 从第三方节点测：

1
2


curl -s 'https://check-host.net/check-http?host=https://services.googleapis.cn&max_nodes=8' -H 'Accept: application/json'
curl -s 'https://check-host.net/check-http?host=https://redirector.gvt1.com&max_nodes=8' -H 'Accept: application/json'

外部节点访问 services.googleapis.cn 和 redirector.gvt1.com 基本都返回 404，说明域名本身没有挂，是本机当前代理线路有问题。

检查 v2rayNG 路由配置

v2rayNG 2.0.18 的配置存在 MMKV 里：

1

su -c 'strings /data/data/com.v2ray.ang/files/mmkv/SETTING | grep -Ei "routing|geosite|gvt1|googleapis|services.googleapis|direct|proxy" -C2'

当时配置里能看到类似规则：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
  "domain": [
    "services.googleapis.cn",
    "*.gvt1.com",
    "redirector.gvt1.com",
    "*.googleusercontent.com"
  ],
  "enabled": true,
  "outboundTag": "proxy",
  "remarks": "playstore"
}

而且它的位置在 geosite:cn -> direct 前面。分应用代理里也包含：

1
2
3
4


com.android.vending
com.google.android.gms
com.android.providers.downloads
com.termux

所以表面看路由顺序没问题。

为了进一步排除“VPN 路由没生效”，我直接强制使用 v2rayNG 的本地 socks 端口测试：

1
2


curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://services.googleapis.cn
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://redirector.gvt1.com

如果强制 socks 也失败，说明不是路由规则顺序问题，而是当前节点或服务端出站本身连不上这些域名。

当时测试结果就是强制 socks 也失败：

1

TLS connect error: unexpected eof while reading

因此定位为当前节点对 services.googleapis.cn 和 redirector.gvt1.com 的 TLS 握手不正常。

修复办法

最终调整 v2rayNG 路由，让 Play 下载相关域名明确走代理，并确保规则在 geosite:cn 直连规则前面：

1
2
3
4
5
6


full:services.googleapis.cn
full:redirector.gvt1.com
domain:gvt1.com
domain:googleapis.cn
domain:googleusercontent.com
geosite:google

出站选择 proxy。

如果用的是简单路由界面，逻辑应该是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


代理：
full:services.googleapis.cn
full:redirector.gvt1.com
domain:gvt1.com
domain:googleapis.cn
domain:googleusercontent.com
geosite:google

直连：
geosite:cn
geoip:cn

注意：services.googleapis.cn 虽然是 .cn 域名，但它是 Google Play 下载入口，不能让它被 geosite:cn 提前命中走直连。

调整后重新测试：

1
2
3
4


curl -I --connect-timeout 10 https://services.googleapis.cn
curl -I --connect-timeout 10 https://redirector.gvt1.com
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://services.googleapis.cn
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://redirector.gvt1.com

正常结果：

1
2


services.googleapis.cn   HTTP/2 404
redirector.gvt1.com      HTTP/2 404

出现 404 没关系，说明 TLS/HTTPS 已经通了。

最后强停 Play 商店和下载管理器，再重新下载：

1

su -c 'am force-stop com.android.vending; am force-stop com.android.providers.downloads; am force-stop com.google.android.gms'

然后打开 Google Play，取消旧的等待任务，重新点安装。

总结

这次问题有三层：

下载管理器里曾经残留一个只允许 Wi-Fi 且绑定旧网络的 Play 下载任务，需要删除。
Play 下载服务使用 Cronet，失败时界面会显示“等待中”，日志里实际是 CANNOT_CONNECT (8)。
真正导致下载失败的域名是 services.googleapis.cn，它虽然属于 .cn，但应该走代理，不能被 geosite:cn 规则直连。

最有用的几条排查命令：

1
2
3
4


su -c 'content query --uri content://downloads/all_downloads'
su -c 'logcat -d -t 3000 | grep -Ei "Finsky|DownloadService|CronetDownloader|CANNOT_CONNECT|ERR_CONNECTION|ERR_QUIC"'
curl -I --connect-timeout 10 https://services.googleapis.cn
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://services.googleapis.cn

如果 curl --socks5-hostname 127.0.0.1:10808 都连不上，那就不是 v2rayNG 路由写法的问题，而是节点或服务端出站本身的问题。

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

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