网络排查 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

解决 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