mac上 ping提示 No route to host 排查以及修复

macOS 局域网排障实录：从路由表、ARP 到应用层权限

记录一次近期在办公网络环境下遇到的 macOS 局域网连通性问题。整个排障过程比较曲折，涉及代理软件的网络残留、企业交换机的准入策略，以及 macOS 系统自身的隐私权限限制。借此复盘一下从底层网络到应用层的排查思路。

故障表现：

连入公司 Wi-Fi（网段 192.168.0.0/21）后，无法 ping 通局域网内的 Ubuntu 测试机（192.168.7.124），同时网关（192.168.0.1）也无法 ping 通，均提示：

bash 复制代码

❯ ping 192.168.7.124
ping: sendto: No route to host

定位过程：

出现 No route to host，首先怀疑本地路由表或网卡接口存在异常。通过 ifconfig 检查网络接口，发现在常规的 en0（Wi-Fi）之外，存在一个处于 active 状态的虚拟网卡 utun1024：

text 复制代码

utun1024: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
	inet 198.18.0.1 --> 198.18.0.1 netmask 0xfffffffc

198.18.0.0/15 是常见的代理软件（如 Clash 的 TUN 模式 / Fake-IP）使用的保留网段。即使已经卸载了软件图形端，其底层的内核扩展和路由接管规则可能并未清理干净，导致发往局域网的流量被错误路由。

处理方式：

清理相关进程，并强制刷新系统路由表，然后重启 Wi-Fi：

bash 复制代码

sudo route -n flush

新问题：

清理虚拟网卡并重新获取 IP（192.168.3.71）后，通过 netstat -nr -f inet 确认路由表已恢复正常，同网段路由指向明确。但依然无法 ping 通目标 IP。

此时检查底层的 ARP 缓存：

bash 复制代码

❯ arp 192.168.7.124
192.168.7.124 (192.168.7.124) -- no entry

提示 no entry，说明本地发出的 ARP 广播没有收到任何物理 MAC 地址的回应。

通过交叉测试发现：其他同事可以正常 ping 通网关，也可以连上那台 Ubuntu 测试机。问题仅出在我的 Mac 上。

原因分析：

排查后确认，原因是 macOS 的 "私有 Wi-Fi 地址" 功能。为了隐私保护，苹果设备连接 Wi-Fi 时默认会伪造一个随机的 MAC 地址。

企业网络的核心交换机（此处为华为/H3C 设备）通常配置了 NAC（网络准入控制）或端口安全策略。交换机识别到非法的随机 MAC 地址后，直接在二层链路将其隔离，丢弃了该设备发出的所有 ARP 广播。

处理方式：

在 Mac 的 Wi-Fi 网络设置中，关闭"私有 Wi-Fi 地址"。

使用物理 MAC 地址重连后，交换机正常学习到 ARP 表项，底层网络连通。

text 复制代码

# 交换机端状态确认
<HEXIN>dis arp | in 192.168.3.41
192.168.3.41    fcb2-14c4-b769    20    D-0  GE0/0/19

现象：

底层链路打通后，目标机器 IP 变更为 192.168.2.1。此时出现了一个奇怪的现象：

使用 macOS 自带的 Terminal ：ping 和 telnet 192.168.2.1 22 均正常。
使用 iTerm2 ：依然提示 No route to host。
使用 FinalShell ：SSH 连接报错 java.net.NoRouteToHostException: No route to host。

在系统网络正常的情况下，第三方终端软件无法建立连接，通常是应用层环境或系统权限拦截导致的。

排查方向：

终端环境变量污染

卸载代理软件时，如果终端配置文件（如 ~/.zshrc 或 ~/.bash_profile）中的全局代理变量没有清理，iTerm2 启动时会继续加载 http_proxy 或 ALL_PROXY。这会导致 CLI 工具尝试通过已经失效的本地代理端口发包。
- 修复： 检查 env 输出，执行 unset http_proxy https_proxy all_proxy ALL_PROXY，并从配置文件中移除相关变量。
macOS 本地网络权限限制（主要原因）

macOS 近期的安全机制严格限制了应用访问局域网的能力。任何第三方 App 尝试连接 192.168.x.x 时，系统都会拦截并要求用户授权"查找并连接到本地网络上的设备"。

如果在首次弹窗时被拒绝，或者系统默认未放行，内核会针对该 App 直接返回 No route to host。自带的 Terminal 默认拥有系统级白名单，因此不受影响。
- 修复： 进入 "系统设置" -> "隐私与安全性" -> "本地网络" ，在列表中找到 iTerm2 和 Java (FinalShell 依赖)，开启对应权限。

在企业网络环境下排查类似的网络阻断问题，需要区分不同层面的干扰因素：