技术日志：macOS 局域网段 (192.168.5.x) 访问故障排查与修复

日期： 2026-02-05

环境： macOS Sequoia / Sonoma

故障描述：

无法访问局域网内的 NAS 设备（IP: 192.168.5.154）。尝试 ping 或 traceroute 该地址时，系统持续报错 sendto: No route to host。即使在同一个物理网络下，流量也无法到达目标地址。

一、 深度排查过程

1. 链路基本测试

   • 执行 ping 192.168.5.154，返回 No route to host。这表明问题不在于设备关机，而是 macOS 系统根本不知道该从哪个网卡把数据包发出去。

2. 路由追踪分析

   • 执行 traceroute -n 192.168.5.154，第一跳即报错。这确认了流量在离开本机协议栈之前就被拦截或丢弃了。

3. 系统路由表检查 (核心发现)

   • 执行命令：netstat -nr | grep 192.168.5。
   • 发现异常： 该网段的路由指向了一个名为 feth3656 的虚拟接口，而不是物理网卡（en0）或预期的网络隧道。
   • 原因定位： feth (Fake Ethernet) 接口通常由广告过滤类 App 的“透明代理”驱动程序创建。即使该 App 已在界面上关闭，其系统扩展（System Extension）依然常驻底层并强行劫持了该私有网段的流量。

二、 解决方案与处理步骤

1. 强行解除劫持 (临时修复)

   • 首先手动删除被劫持的错误路由：

     sudo route delete -net 192.168.5.0/24

   • 重新将该网段指向当前的活跃网络网卡：

     sudo route add -net 192.168.5.0/24 -interface utunX (此处接口需根据实际情况指定)。

   • 结果： 手动修正后，网络立即恢复正常，但重启后故障重现。

2. 彻底根除残留驱动 (永久修复)

   • 清理网络插件： 进入 系统设置 -> 网络 -> VPN 与过滤器。
   • 移除残留： 发现“广告过滤 App”虽显示已停用，但其插件条目仍存在。点击 - 号将其从系统配置中彻底移除。
   • 重置网络堆栈： 卸载残留插件后，执行 sudo route -n flush 清空所有动态生成的错误路由。

3. 优化系统服务顺序

   • 在网络设置中调整“服务顺序”，确保常用的虚拟网络接口优先级高于物理网卡，防止物理路由表再次产生冲突。

三、 最终结论

故障根源： 之前安装的广告过滤 App 卸载不彻底，其残留的虚拟网卡驱动（feth 接口）在系统底层非法占用了 192.168.5.0/24 网段的路由权。由于驱动处于半失效状态，导致所有发往该网段的流量进入“死胡同”。

修复方案： 通过 netstat 定位到具体的非法接口名称，并在系统设置中移除对应的 内容过滤 (Content Filter) 插件，重启后系统恢复自动分配正确路由的能力。