VPN 断开后如何检查 Mac 的 IPv6 状态

隧道断开后能用 IPv4 打开网站，并不能证明 IPv6 的情况。macOS 按每项网络服务分别配置两个协议族，VPN 客户端可以改动其中一族而不碰另一族。请按顺序查三层：地址配置、路由选择，以及断开期间客户端安装的策略。期间保持接入网络不变，否则你比较的就是两个不同的问题。

先从真正坏掉的那一族开始

通过 IPv4 能加载的页面只能说明物理网络是通的。它不能说明服务是否有全局 IPv6 地址、前缀是否仍在通告，或者是否有东西在过滤该协议族。选工具之前先确认坏在哪一层，因为解析到不可达地址的名字，与完全解析不出的名字看起来一模一样。问清是哪一层答错了，并把答案记下来。没有这一步，后面每一步都只是披着流程外衣的猜测。

整个对比过程都使用同一个 Wi-Fi 网络和同一个接入点。昨天提供 IPv6 的咖啡馆网络，说明不了你现在的网络。

先读地址，再看路由

在系统设置中，当前服务的 TCP/IP 面板会显示 IPv6 是自动、手动还是仅链路本地。把这一点与你的预期对照，并记住机构可能是有意选择手动配置的。然后运行 ifconfig 并读取相应接口。仅有 fe80:: 地址意味着该接口只能和邻居通信、仅此而已，因此链路本地地址的存在并不能证明路径可用。

还要查找客户端留下的 utun 接口。过期的隧道设备可能在客户端停用很久之后仍保留地址和路由。如果确实存在，那是给客户端所有者的生命周期发现，而不是可以当场删除的东西。

读取失败目标的路由表

向内核查询失败的那个目标，而不是默认路由。route -n get 2001:db8::25 会打印为该地址选中的接口和网关，netstat -rn -f inet6 则显示整张表以便对照。默认路由只说明存在默认项，并不说明这个目标用了它。

把 DNS 放在独立的位置。通过 IPv4 可达的解析器仍可能返回 AAAA 记录，所以查询失败和路由失败在浏览器里表现相同。

把客户端的封锁策略与残留规则分开

有些客户端 被设计为在断开期间封锁流量，包括另一个地址族，这种行为是特性而非故障。

在把封锁当成损坏之前，先弄清你的客户端文档写的是哪种行为。scutil --dns 会显示每项服务生效的解析器，客户端安装的解析器或带作用域的 DNS 设置正是在这里变得可见。然后检查是否有包过滤规则被装上并留在那里。预期之内的封锁与残留规则需要相反的处理，只有所有者的文档能区分两者。

先取证，再只改一处

在一个连接—断开周期的两侧，记录客户端版本、macOS 版本、网络服务、预期的断开策略，以及地址和路由输出。正是这份记录把抱怨变成别人可以调查的生命周期问题。然后只做一处改动并重新测量。

不要急着重置。删除虚拟接口、清空路由表、在全机范围关闭 IPv6，都会毁掉你本该留存的现场状态，还可能顺带带走无关配置。如果客户端有受支持的暂停、修复或卸载流程，就用它，并在网络受管的环境中遵循管理员的流程。已经重置过的机器不会给所有者留下任何可查的东西，而且往往在下次连接时重现故障。