macOS 上的 VPN 路由检查：用 route get 不做任何改动

用户在办公网络上访问内网，而不是通过隧道，但「设置」仍显示 VPN 已连接。此时编辑路由表可能切断你正在用来诊断的远程会话。改为询问内核会为失败的主机选择哪条路径。macOS 的 route 工具有一个 get 操作，正好针对单个目标回答这个问题，而且不做任何改动。

查询失败的主机，而不是默认路由

在现代 Mac 上，默认路由的截图说明不了什么，因为更具体的目标或受限策略可能压过默认路由表面上说的情况。隧道可能已建立，默认路由可能看起来正确，你唯一需要的主机却仍可能被路由到别处。查询失败的那个地址，让内核说出它选择的路径。

形式是 route -n get 后接地址：route -n get 203.0.113.10，其中文档地址代表你的目标。使用获得授权的目的地和匹配的地址族，因为 IPv4 的答案说明不了只支持 IPv6 的资源。route 工具的文档描述了 get 操作及它打印的字段。

把接口和网关当作证据来读

在连接 VPN 之前运行查询，连接之后再运行一次，比较接口和网关两行。两个答案之间的差值就是隧道真正改变的东西，它比整张表的转储有用得多。如果两次运行的接口相同，路由从来不是问题，你可以不再看路由。

在下结论之前，记录目标、接口、网关和查询时间。输出是证据，不是诊断：涉及拆分隧道时，同一个接口可能对一台主机正确、对另一台错误。

路由正确不等于请求可用

路由只告诉内核会使用哪个接口，仅此而已。DNS、主机防火墙和应用授权都位于这个决定之上，路由成功之后请求仍可能失败。继续之前先保留准确症状，因为「无法连接」和「能连接但返回错误」是不同的排查，后续步骤也不同。解析器视图和接口视图是对目标查询的补充，而不是替代。

路由表列表仍有其位置：你是靠它注意到意外的默认路由。残留的普通默认路由并不能证明 VPN 没被使用，因为更具体的条目会胜过它。

把端点与资源分开

这里涉及两次查找，它们回答不同的问题。到达端点是一段穿过物理网络的外部旅程。到达应用发生在隧道内部，地址只存在于私有一侧。把两者混为一谈会产生经典的假循环：端点看起来像是经由它自己终结的隧道去路由。分别查询两个地址，给每个结果加上标签，混乱就消失了。

前缀重叠是另一个值得了解的情况。当本地与远程范围重叠时，由最长前缀匹配决定，因此重叠的本地子网可能遮蔽你期望的远程地址。那时私有目标看起来和本地目标一模一样，修正属于地址规划而不是路由表。get 查询显示哪个接口胜出，而这就是你改动任何东西之前需要的事实。

先读，后改

第一轮先别碰 route add 和 route delete。在你远程管理的 Mac 上，一次粗心的表编辑就可能拿走回到这台机器的路，让没有人能完成诊断。先确定正确路由是什么，写下如何撤销改动，然后才执行。检查没有这样的尾巴。

把清缓存和重启网络服务当作第一步时也要同样谨慎，因为两者都会破坏你正要读取的证据。只读检查便宜、可重复，而且以任何顺序运行都安全。把它们作为默认步骤，只有当证据指向改动时才动手。