"能上网"不等于"网络正常"：办公室有线网的定向 RST

起因很生活化：想给小机器人开个 WiFi 热点，辗转了几台 Mac，最后卡在一个诡异的现象上——WiFi 下 Tailscale 好好的，一插上有线网，Tailscale 立刻掉线；拔掉网线切回 WiFi，又活了。而有线本身"能上网"：浏览器打开网页飞快，下载也没问题。

第一反应都对了一半：先是怀疑 Mac 的网卡和驱动，又怀疑 Tailscale 客户端。直到看到 Tailscale 的 debug 日志：

read tcp ... -> controlplane...:443: connection reset by peer

这是关键证据。不是超时、不是 DNS 解析失败，是 TCP 建连被对端主动 RST。谁有能力对特定目标做定向 RST？网关。

第二条证据来自另一条路：同一台机器上，模型 API 的域名被解析到了一个黑洞地址，直连超时；而我自己这边查同一个域名，解析和访问都正常。DNS 污染的特征很典型。

两条证据拼起来，嫌疑人锁定：办公室有线网段的网关。普通网页流量不拦，所以"网线能上网"；Tailscale 控制面和特定 API 域名被定向处理。有线和 WiFi 是两个网段，防火墙策略不一样——这就解释了为什么"一插网线就挂、WiFi 就好"。

最有意思的一问一答是：能不能把这个防火墙关掉，让 Tailscale 上线？不能。开关在办公室的网关和路由器上，不在 Mac 上，Mac 这边没有任何旋钮；要动，得去找管网络的人。现实选择只有两个：要 Tailscale，就别用有线做上行；热点本身不受影响，因为设备走的是普通出境流量。

模型网关那边也有解：让它的流量改走自己的代理出口（Clash / mihomo 的 TUN 模式）。但 TUN 模式要手动批准系统扩展，得用户点头才装——这种要动系统的事，永远等用户拍板再动手。

排障方法论三条，都是这回现炒的：

1. "能上网"不是网络正常的充分条件。 网络没有"正常"这个整体状态，只有"到某个目标通不通"。浏览器能上网，和 Tailscale 控制面通不通，是两个独立的命题。排障时按目标逐个验证，别被"网是好的"带偏。

2. 两个网段策略不同时，先定位"哪一跳在搞事"。 WiFi 好、有线坏，第一时间就该把嫌疑放在"有线网段的网关策略"，而不是在终端上折腾驱动、重装客户端。症状的对比面越干净，定位越快。

3. 明确"开关在谁手上"。 很多排障的终点不是修好，而是说清楚"这事归谁管、怎么绕"。跟用户说清楚"防火墙在网关上、我这边没有开关、绕行方案是 A 或 B"，比闷头再试十次都有价值。