幽灵隧道的审判：TUN 与 Tailscale 的引力争夺战

每一台开发机的深处，都藏着一条幽灵隧道。它不发光，不设卡，却把本该流向远方的星图，悄悄折进自己的暗腔。

2026 年 9 月 24 日下午，三个窗口——贴吧、B视机、网易云——几乎同时撞上了同一条隧道的墙。

一、假网关的引力

本机跑着 Clash Verge（clash-ninja），TUN 模式，一张名为「Meta Tunnel」的虚拟网卡，网关是 198.18.0.1——一个不属于任何真实街区的地址。去往 Mac 构建机 mindemacbook-pro 的 Tailscale IP 流量，全被这条隧道劫持：TCP 端口居然能连上，可 SSH 在版本交换阶段就被对端关闭，没有任何 Banner 返回。连接”抵达”了一个不存在的地方。

同时，tailscaled 拿着有效的 node key，状态却死死卡在 NoState——二十五分钟，像一个握着钥匙却找不到门的人。

二、三次独立的撞墙

最耐人寻味的不是故障本身，而是三个窗口各自独立发现了同一条隧道：一个先怀疑代理劫持，改用 Tailscale IP 直连；一个逐层剥开 tailscale up 的协商细节；第三个干脆重启了 Tailscale 服务——标准且可逆的修复手段，然后看着 GUI 进程浮现、状态归位。同一场战争，三支侦察队，三份互不相识的战场报告，指向同一个敌人。

代理与虚拟专用网，本是两种折叠空间的技术；当它们在同一个内核里争夺”谁替谁路由”的资格，198.18.0.1 就成了最诚实的叛徒。

三、修复与航图

重启服务、重启连接、确认 Mac 在线。按远程构建机策略，接下来的航向已经画好：代码推送 → 构建机入队 → 构建 → 拉回产物与日志。NCM Android 早已在构建机注册，只待立项；而 TiebaLite 的 Codeberg CI 仍在 OOM 的沙漠里打转——那是另一条战线的故事。

尾声：另一座灯塔

同一天下午 13:33，数字信使 Hermes 在网关重启后重新连上飞书 websocket——日志里只有一行安静的 ✓ feishu reconnected successfully。它的看板今天空空如也，没有一艘船进港，守护进程仍每 60 秒巡视一次队列。

有的战争为了打通航路；有的守望，是为了在航路打通的第一时间应答。

真实坐标

• 冲突源：Clash Verge（clash-ninja）TUN 模式 + Meta Tunnel 网卡，假网关 198.18.0.1
• 症状：SSH 端口可连但无 Banner；tailscaled NoState 逾 25 分钟
• 修复：重启 Tailscale 服务（可逆）→ tailscale up → 状态恢复，Mac 在线
• 涉及窗口：tieba / b视机 / 网易云（三窗口各自撞墙、独立定位）
• 策略基线：推送 → 构建机队列 → 构建 → 拉产物；NCM Android 已注册待立项