开了 VPN 就找不到 AirDrop？检查本地路由

AirDrop 本来能用，一开 VPN 另一台 Mac 或 iPhone 就从共享面板里消失了。VPN 日志不会提到发现，因为故障通常出在本地可达性上，而不是密码学。Apple 的支持页面也承认，限制本地网络的 VPN 配置可能干扰 Continuity 与 AirDrop；这是有用的线索，不是诊断。先做便宜的检查，再读路由表，把本地访问开关当作关于隐私的决定，而不是随手拨动的默认值。

隧道还没介入之前坏掉的是什么

两台设备都要开着 Wi-Fi 或蓝牙，AirDrop 必须在接收窗口内接受来自联系人或所有人的投送，两个账户还要能互相发现。把接收方设成所有人十分钟是正当的实验：如果另一台设备出现了，问题就在设置上，隧道是清白的。用已知的接收方测试，别照着共享面板显示的内容下结论。

浏览器能打开网页只证明互联网通路正常，不证明本地发现正常。让两台设备和你的位置都不动，然后开关 VPN，注意另一台设备是否只在隧道建立时消失。如果发现随隧道一起死、关掉又回来，隧道就是变量，这份清单剩下的部分才适用。如果两种状态都失败，先重新过一遍前提条件，再改任何网络策略。

默认路由一动，共享面板就空了

全隧道客户端通常装一条经隧道的默认路由，再加两条抓走大部分目的地址的半路由。本地子网只有拥有更具体的路由才能在这种布局下存活；否则就掉进隧道里。AirDrop 本身走 AWDL 点对点接口，所以过滤或强行给本地接口改路由的客户端会干扰它，而互联网通路依然完好。四条命令覆盖接口、路由、活动连接和包过滤器。

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

先读默认那一行：如果它指向 utun 接口，又没有更具体的路由覆盖你的子网，本地流量就进了隧道，感知也随之消失。0/1 与 128.0/1 这一对是全隧道常见的形状，因为这些路由压过真正的默认路由，却没有取代它。awdl0 那行显示活动状态和地址，就排除了点对点接口断开。三样都正常时，限制来自客户端策略或主机上的过滤器，而不是路由表。

有一种形状值得单独说，因为它专门在访客网络上抓人，而且不是半路由。DHCP 会把刚分到的地址装成一条链路内路由，这条记录比两个半路由都更具体，所以访客子网和家里的一样能穿过隧道。去掉它的是策略而不是路由：一个安装拒绝规则的阻止本地网络选项、一个丢弃该子网的主机防火墙，或者客户端缺的 macOS 本地网络权限。看起来正常的表配上死掉的共享面板，正是下一节的签名，而不是路由形状的签名。

受管理的 Mac 可能不提供本地访问开关

很多客户端提供隧道建立时允许访问本地网络的选项，但这个选项由客户端和管理描述文件共同执行，所以在受管理的 Mac 上可能被锁定、隐藏或覆盖。主机防火墙规则或安全代理也能在不看 VPN 客户端提供什么的情况下挡住点对点流量。先去找这个开关，再断言它没用。这个开关住在客户端自己的偏好设置里，而不是 macOS 的网络设置里，所以面板上不显示它的客户端通常受管理描述文件支配。

为了一个接收方出现而移除管理或关掉所有过滤器，是拿受控的配置换未知的配置。只有当本地访问选项符合你所在环境的策略时才打开它，在从来不需要本地发现的访客网络上保持关闭。

用文件验证，而不是用图标

改完路由或策略后，把真实文件发给目标接收方，确认传输完成。名字出现在面板里只是发现，发现回来不等于传输结束。

设备仍然不出现，就用同一网络上的另一对设备做对比，把主机问题和全网问题分开。这种对比比逐个切换 VPN 选项快，也能给工单留下事实。趁故障可复现，记下默认接口、路由形状和本地访问开关的状态。否则下一个人会把四项检查从头再做一遍。