iPhone 上的 VPN 图标亮着：它覆盖了每个应用，还是只算能用？
一个徽标，三种不同说法。分清配置描述文件覆盖了什么、按需规则做了什么，以及你实际测的是哪个地址族。
徽标出现了，应用却仍像在家里一样工作，于是显而易见的结论是隧道坏了。通常什么都没坏。徽标报告的是一条连接，而它背后的问题关乎覆盖范围，这是两回事。
三个条件决定你能下哪种结论。在它们明确之前，任何测试结果都含糊不清。
一个图标背后藏着三个答案
第一个问题是你要隧道做什么。访问内部 wiki、对流媒体服务隐藏你的地址、保护单个受管理的应用，是三种不同需求，由三种不同的描述文件满足。
第二个问题是描述文件归谁所有。个人自行安装的配置，与管理系统下发的配置行为不同，只有后者能携带 iOS 会执行的按应用规则。徽标分不清这两者。
第三个问题是你所处的地址族。当网络分配 IPv6 而隧道只承载 IPv4 时，就有一条路径留在隧道之外。只访问 IPv4 站点的测试永远看不到它。
按应用的描述文件只覆盖它自己列出的应用
按应用的 VPN 正是最容易产生误报的情形。描述文件列出流量进入隧道的应用，其余应用按设计继续走本地网络。因此，浏览器里的公网地址保持不变是预期行为，而不是故障证据。状态栏里没有任何东西与此矛盾。
测试描述文件所针对的那个应用，并用只有内网才有的资源来测。被列出的应用成功发出内部请求，说明配置可用。这时 Safari 里显示正常的公网地址，说明按应用描述文件正按配置工作。
按需规则会改变你观察到的现象
按需配置决定的是何时建立连接，而不是流量是否被覆盖。规则可以在请求某个域时拉起隧道、在请求结束后拆掉它，所以日常使用中徽标时有时无，恰恰是设计在起作用。读规则，再解读徽标。
这一行为也解释了同一天里看似矛盾的结果。同一个应用可能上午十点走隧道、中午直连，因为变的是触发条件，不是策略。
一次探测不等于覆盖证明
浏览器里的一次检查只能证明一个请求走了一条路径，仅此而已。它说明不了自带网络栈的第二个应用、在隧道建立前跑过的后台同步，或者因为旧套接字从未重建而熬过网络切换的连接。这个缺口是范围问题，不是泄漏。
| Observation | Decide this first | Then test |
|---|---|---|
| Badge on, public address unchanged | Is the profile per-app? | The named internal app, not a browser |
| Badge flickers during the day | Are on-demand rules present? | Whether the flip follows a trigger domain |
| Internal app works, another fails | Is that app in the profile? | Its own settings and any proxy config |
| Nothing works while badge is on | Is this a path failure? | Name resolution and a known-good internal host |
只有第四行指向故障。隧道已连接但域名解析坏了、回程路由缺失，或服务本身停摆，从应用的角度看都是一样的。
升级前要记录什么
记下描述文件名称、是否来自管理系统、有没有按应用规则，以及失败请求的准确时间。再加上你测过的地址族和发起测试的应用。屏幕上的任何数字都替代不了这份清单。有了它，一轮沟通就能把覆盖问题与故障区分开。
也要盯住安全基本功。隧道并不替代证书校验、账号保护或设备权限。网络状态旁出现一个图标，并不证明其中任何一项已经配置好；把它当成证明，正是凭一个徽标就宣称隐私的来源。
Apple 的VPN 部署概览介绍了这些差异背后的描述文件类型与按需行为。在就描述文件该覆盖什么与管理方争论之前，先读一读。