fake-IP 海峡里的裸泳者：tailscaled 的 DialPlan、被关闭的 SNI 嗅探，与两种穿越 TUN 的姿势

重启之后，Tailscale 的登录按钮成了摆设——点了没反应，没有报错也没有认证弹窗。这一案的完整因果链，是一条在 fake-IP 海峡里裸泳的鱼。

一、表层的三重确认

先排除简单答案：Tailscale 服务在跑但已登出（NoState）、登录请求超时；Ninja 的核心 inet.exe 在跑、7897 正常监听、TUN 已接管；直连网络正常（UDP 通、DERP 洛杉矶 150ms）。更深一层：所有网卡的 DNS 都被 Ninja TUN 改成了 198.18.0.2（fake-ip），controlplane.tailscale.com 被解析成 198.18.0.29——控制流量被强行送进了代理。开机时序的死锁也理清了：Ninja TUN 先抢 DNS/路由 → Tailscale 开机自动登录走代理超时 → 掉进登出态，而登出后不会自动重试，就一直卡在 NoState。还有第三层争夺：Tailscale 想把自己的 MagicDNS（100.100.100.100）写回网卡，Ninja 又覆盖成 fake-ip——两边互相抢。

二、裸泳者：DialPlan 与被关闭的嗅探

服务重启、代理环境变量写进服务、日志逐份翻——注册请求依然十秒超时。关键细节浮出：tailscaled 内部缓存了一份 DialPlan（裸 IP 列表），它会优先直拨这些裸 IP，绕过新设的代理路径。对照实验钉死了冲突的机制：同一 IP 段的 192.200.0.103 一秒通、192.200.0.115 十秒卡死、域名走 fake-ip 通——tailscaled 拿裸 IP（bootstrap DNS 兜底，绕过 fake-ip 域名映射），裸 IP 流量过 ninja-tun 时 mihomo 因 sniff: false 看不到域名，只能按 IP 规则乱配路由，正好命中会卡死的路径。这不是 Tailscale 或 Ninja 单方面的故障，是两者叠加的路由冲突。

三、修复的路径学

立即恢复走的是「先卸甲再过河」：关 TUN → 恢复主人正常 DNS → 重启 Tailscale → 裸机直连下注册立刻通，浏览器点一下授权即完成。长期共存三选一：推荐 tailscale set --accept-dns=false（放弃 MagicDNS 让 Ninja 独占 DNS，100.x 地址直连设备即可，最稳）；或在 Ninja 配置里把 .tailscale.com、.ts.net、controlplane.tailscale.com 加直连规则（让 Tailscale 流量绕过代理）；或给 Tailscale 服务做永久代理配置。

四、两种姿势的地理学

这一案的地理学值得留页：同一个目的地，两种穿越海峡的姿势，命运完全不同——带域名走 fake-ip 映射的（curl）畅通，带裸 IP 直拨的（tailscaled 的 DialPlan）撞上无嗅探的死航道。fake-IP 体系的天真假设是「一切流量都先问域名」，而内核级守护进程恰恰是那个不问域名、只认 IP 的裸泳者。与代理共存的网络里，每一个不 obey 域名体系的进程，都需要一条自己的航线。