VPN 开着时 iPhone 应用找不到局域网设备
两扇门决定 iPhone 应用能否通过 VPN 访问打印机或电视：本地网络权限和隧道本身的路由。按顺序检查。
你的打印机应用显示空列表，相机应用报告没有找到设备，视频应用里的投送按钮一直转到放弃为止。VPN 图标就在状态栏里，手机信号满格，Safari 也能正常加载网页，所以连接看起来没有任何毛病。然后你打开应用自己的设置，却找不到任何可切换的开关。
我在家里的网络上用标签打印机时正好撞上这堵墙：应用从未获得本地网络访问权限，而我测试的配置是完整隧道，把所有发往 192.168.1.0/24 的包都吞掉了。两扇独立的门都关着，只打开一扇并不能消除症状。
一个应用和一个打印机之间隔着两扇门
第一扇门属于操作系统而不是应用本身的隐私决定。iOS 决定应用能否向本地网络中的地址发送流量，并且只在应用第一次尝试时询问用户。第二扇门是路由表。发往 192.168.1.50 的数据包要么经 Wi-Fi 直接去打印机，要么进入隧道，而这个选择写在 VPN 配置里。
两扇门的失败形态不同，这正是诊断可行的原因。权限被拒会直接杀死应用自己的 socket 调用，于是应用没有东西可报告，只能回落到通用的空状态。路由问题看起来像超时，因为数据包离开了手机，死在对面某处。同样是空白屏幕，修法却不同。
先读权限状态，再碰 VPN
打开设置，然后是隐私与安全性，再是本地网络。每个请求过访问权限的应用都会带着开关出现在那里。Apple 在 iOS 14 到 iOS 18 之间挪动并重命名过这个界面的部分内容，所以如果条目不在你预期的位置，直接在设置的搜索框里输入本地网络，不要翻菜单树。
最容易卡住人的是一次性询问。iOS 只在应用第一次接触本地网络时询问，而且仅此一次。点了不允许，下次启动不会再问，开关是唯一的回头路，而且默认是关的。重装应用会重置这个决定，所以一些排障帖声称重装修好了发现功能。确实修好了，方法是清掉了拒绝。
在被监督或被管理的 iPhone 上，开关有时是灰色的。MDM 下发的隐私偏好负载可以预设或锁定本地网络访问，而一个被锁定且关闭的开关意味着要改的是策略而不是手机。Apple 在这里记录了这次询问和每个应用的开关: support.apple.com/en-us/102229。
检查隧道究竟路由了什么
完整隧道拿走 0.0.0.0/0，同时拿走所有私有网段。发往 10.x、172.16.0.0/12 和 192.168.x.x 的数据包会跑到服务器，服务器通常直接丢掉，或者把它翻译成自己的子网，所以即使给了权限，打印机仍然不可达。分流隧道做的是相反的事，但只对配置里列出的网段生效。
用 Apple Configurator 构建或以 .mobileconfig 分发的 IKEv2 配置，把它表达为发送全部流量的设置，加上分流时一份明确排除的本地网络列表。基于 NEPacketTunnelProvider 的客户端应用通过 includedRoutes 表达同样的决定。两者都从状态栏上看不出来，而且都会覆盖应用预期看到的结果。
我用的测试是这样的。连接 VPN 后，在 Safari 里用路由器的 LAN 地址打开管理页面。如果公共网站能打开而那个页面超时，你的私有网段就在隧道里。如果页面能打开，本地流量仍然走 Wi-Fi，阻塞在别处。
把症状对应到门
同一部手机上的两个应用可能表现不一致，因为权限按应用授予，而路由按配置授予。动手之前先比较什么在失败：通常这个模式自己就会指出是哪扇门。
| What you see | Gate | Next step |
|---|---|---|
| Device list stays empty, Local Network switch is off | Permission | Enable the switch, force-quit the app, reopen it |
| Switch is on, router page times out, public sites load | Routing | Exclude the local range in the profile, or move to a split tunnel |
| Both pass, direct IP works, discovery stays empty | Link-local multicast | Enter the device address by hand, or check profile discovery support |
| Works by IP address, never by name such as printer.local | Name resolution | Fix mDNS reachability or use the numeric address |
| Everything fails with the VPN off, on hotel Wi-Fi | Client isolation | Change network, do not change permissions |
mDNS 这一行值得说明。Bonjour 和大多数投送协议的发现流量以链路本地作用域组播到 224.0.0.251 和 ff02::fb，而被路由的隧道不承载它。这就是为什么设备能回应直连，却从不出现在列表里。
测试操作，而不是图标
拨完本地网络开关后，从应用切换器强制退出应用再重新打开。正在运行的进程可能保留改动之前的拒绝状态，而一个持续返回空列表的应用，无论权限是否生效都长得一样。然后执行一个具体操作，比如打印测试页或开始播放视频，而不是盯着设备列表等它填充。
对比期间保持 VPN 配置不变。如果发现功能只在断开后才开始工作，你就学到了问题出在隧道而不是权限。每次只改一个变量，否则下一轮什么都告诉不了你。
按这个顺序修复
下面这个顺序是我现在遵循的，因为它从不让手机停在改了一半、下一次测试读不出结果的状态。
- 确认应用在隐私与安全性、本地网络下有条目，且开关是打开的。
- 强制退出并重启应用，然后把真实操作重试一次。
- 在连接状态下用 LAN 地址打开路由器页面，证明私有网段是否走了隧道。
- 如果走了隧道，改配置排除本地网络，或者请配置的所有者来做。
- 如果开关是灰色的，把设备当作受管理的，把请求转给管理员。
通常只有一条适用。如果都没改变结果，剩下的嫌疑就是网络本身，比如接入点隔离或绑定 Wi-Fi 地址的客户端白名单，上面的对照表会指出是哪一条。