一个由 Tmux 进程寿命引发的诡异No Route to Host问题

经验证，ping 能通、nc 能连，唯独 telnet 返回“No route to host”，且 tcpdump 抓不到任何包。这不是网络故障，而是 macOS 内核给你开了个“时间玩笑”。

一、诡异的开场：同一个目标，不同的命运 #

在一个平常的工作日下午，我需要验证局域网内一台设备（192.168.1.237）的 1095 端口是否通畅。

我顺手敲下了 nc 命令：

nc -vz 192.168.1.237 1095

输出显示 succeeded!。为了确保不是幻觉，我立刻开启了 tcpdump 抓包，捕获到了标准的 TCP 三次握手和 FIN 挥手包——一切完美无瑕。

然而，当我像往常一样使用 telnet 进行交互式测试时，画风突变：

telnet 192.168.1.237 1095
# 输出：telnet: connect to address 192.168.1.237: No route to host

No route to host？ 这台设备明明就在同一个 /24 网段，刚才 nc 还通了，怎么可能没有路由？

更诡异的是，当我再次盯着 tcpdump 运行 telnet 时，网卡上竟然静悄悄的，一个数据包都没有发出去。这意味着操作系统在协议栈的最底层就将这次请求“吃掉了”，根本没有送到网线上。

我检查了 ARP 表（arp -na | grep 192.168.1.237），发现没有该设备的 MAC 地址记录。但这也正常，如果操作系统不发 ARP 请求，表里自然没有。

路由表（netstat -rn）显示直连路由存在，且 nc 的成功证明了网络层物理链路是完全畅通的。这绝对不是一个传统的三层路由问题。

排查发现，如果我在 macOS 的本地 Terminal.app 直接运行 telnet，它竟然是成功的。

而故障复现的路径极其隐蔽：Tailscale SSH -> 远程 macOS -> tmux 会话 -> telnet。

一开始，我将怀疑指向了 macOS 的 “本地网络隐私”（Local Network Privacy） 权限。这是 Apple 在 Sonoma 时代引入的强安全机制，无 GUI 权限的进程访问局域网会被内核无情拦截。

但很快，一个现象推翻了这个单一假设：同一个 SSH 通道，同一个用户，如果我新开一个终端窗口，重新 SSH 进去并启动一个新的 tmux，telnet 居然奇迹般地成功了！

旧的那个 tmux 窗格依然死死报错，而新的 tmux 窗格一切正常。新旧会话并存，同一时刻，一个能连一个不能连。这排除了“目标设备离线”和“防火墙策略”的可能性。

在查阅了大量 macOS XNU 内核相关资料后，真相终于浮出水面。问题出在 macOS 的 TCC（Transparency, Consent, and Control，透明性、同意与控制）框架 与 进程生命周期 的交织上。

macOS 的内核在检查“本地网络访问”权限时，遵循一个铁律：权限检查在进程启动（exec/fork）时进行，且结果在该进程的整个生命周期（PID 生命周期）内永不改变。

我们来看时间线：

旧 tmux 服务器（坏掉的，PID 100）：
- 这个 tmux 服务器可能是几天前系统刚启动时，或者你第一次 SSH 连接时启动的。
- 在那个遥远的时刻，macOS 的 TCC 数据库判定该进程无权访问 192.168.x.x 网段。
- 内核在 PID 100 的进程结构体上打上了“禁止局域网”的标签。从此，无论你在这个 tmux 里运行 telnet、curl 还是 python，子进程都会继承这个“原罪”。
- 调用 connect() 时，内核直接返回 EHOSTUNREACH，并提前返回，数据包根本没机会进入 IP 栈，所以 tcpdump 抓不到任何包。
新 tmux 服务器（好的，PID 200）：
- 你新开窗口重新 SSH 并输入 tmux 时，系统创建了一个全新的进程（PID 200）。
- 此时，由于你在之前的 Terminal.app 中成功运行过命令，或者系统 TCC 数据库此时处于“允许”状态，PID 200 获得了“允许访问”的标签。
- 新会话中的所有命令畅通无阻。

你可能会问：为什么 nc 从头到尾都能通？

因为 macOS 自带的 /usr/bin/nc 属于系统级二进制文件，拥有特殊的加密签名和系统白名单保护。在 TCC 框架下，它通常享有豁免权，或者其权限独立于父进程的环境判断。而通过 Homebrew 安装的 telnet 则是一个标准的第三方用户态进程，严格受限于父进程的权限继承。

既然根因是“旧进程被内核拉黑”，那么解决问题的方式就不需要重启电脑，也不需要修改复杂的系统设置。

# 注意：这会杀死所有 tmux 会话，请先 :wq 保存你的文件！
tmux kill-server

杀死后，重新 SSH 并启动 tmux。此时新生成的服务器进程将获得当前 TCC 状态的“新鲜快照”，telnet 永久恢复正常。

macOS 大版本更新后（如 14.x 升 15.x），建议主动 tmux kill-server 一次，避免老进程因为 TCC 数据库迁移而突然失效。
临时应急：在不方便重启 tmux 时，如果在旧窗格里需要测试端口，可以改用 nc -vz，它通常不受此类父进程标签限制。
彻底放弃 telnet：在 macOS 下，telnet 早已不是系统自带（需要 Homebrew 安装），且因其古老且不安全的协议，完全可以用 nc 或 nmap 替代日常探测任务。