受管 iPhone 应用上的按应用 VPN：哪些走路由，哪些不走
按应用隧道跟随受管应用，而不是整部手机。请检查载荷关联、受管副本、按需规则以及离开应用的流量。
iPhone 上的按应用 VPN 不是整部手机的开关。它是某个受管应用与某个 VPN 载荷之间的关联，在部署应用时创建，其余一切流量都保留原来的路由。因此 同一部手机表现得不一致：工作应用打开私有页面，而 Safari 到不了同一主机；或者隧道根本不起来，应用报告一个看起来像凭据错误的超时。检查从最宽的原因往下走，所以停在第一个失败处。
先检查载荷和应用记录
关联存在于两个对象中，而不是一个。VPN 载荷定义隧道：类型、服务器、认证、DNS，以及使用自定义客户端时提供方的包标识符。应用记录指向该载荷，多数管理控制台在应用配置中以接近 Per-App VPN 的名称提供按应用选项。没有任何应用指向的载荷不会按应用路由任何东西；它的行为像一条需要有人手动启动的普通隧道。
动手机之前先读这两个对象。确认应用配置指向你在测试的载荷，而不是它的旧副本，因为迁移后名称几乎相同的重复载荷很常见，应用会乐意指向已撤回的那个。然后确认配置已到达设备：设置、通用、VPN 与设备管理必须把它显示为已安装的描述文件。那里的 VPN 列表不是测试。按应用服务通常没有手动开关，所以正确部署的配置可能永远不会出现在可启动的 VPN 之间。缺失体现在应用记录以及隧道是否在应用第一次请求时起来。
一个条件解释了许多工单：这个模型要求应用通过管理通道到达。侧载安装或私下购买的副本得不到关联，即使它的包标识符匹配。Apple 的 VPN 部署指南描述了背后的载荷模型（support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web）。
确认已安装的应用是受管副本
关联跟随已安装的受管应用。如果有人用个人 Apple ID 从 App Store 重装，换成重新签名的企业构建，或设备重新注册、应用从另一渠道回来，隧道可能一直不工作，而应用本身看起来完全正常。
用对比来测试，而不是一次观察。在管理清单中，应用必须显示为该设备的受管应用，并在记录中带有 VPN 映射。在手机上，隧道应在应用启动且第一个请求发出时起来，而不只是在有人在设置里启动单独的 manual 配置时。如果启动应用什么也没变，而那个手动配置变了，应用根本没有绑定到按应用隧道。
更新很重要：通过管理推送的更新保留映射，而用户发起的重装可能丢失它。当问题从某次更新开始，先查应用记录再看网络。
检查隧道能取什么
按应用隧道由源应用选择，所以手机的默认路由仍属于 Wi-Fi 或蜂窝网络。OverridePrimary 是改变这一点的键。当描述文件设置它时，隧道表现为完整隧道，每个应用都继承它，于是经过 VPN 的一切都变成描述文件问题，而不是应用故障。
按需规则决定持续性。OnDemandEnabled 及其规则集让隧道在应用发送流量时回来，承受 Wi-Fi 到蜂窝的切换，或在应用进入后台时落下。连上后悄悄死掉的部署，通常有一条只匹配某个探针的规则，而该探针在应用空闲时从不触发。
然后诚实阅读路由一侧。如果提供方或厂商的描述文件给出包含列表，只承载 10.20.0.0/16 的隧道不会承载 10.30.0.0/16 中的服务；那是列表在履行职责，不是按应用故障。内置 iOS 载荷没有包含列表。没有它，划分遵循提供方默认值和 IncludeAllNetworks，而不是隐藏列表。
测试应用，然后测试从它出去的东西
用名称测试，而不只是地址。在受管应用内解析内部主机证明 DNS 也走了隧道，因为载荷决定哪个解析器应答、哪些搜索域生效。名称解析失败时路由可能完美，两种症状指向不同设置。
然后从两侧测试边界。个人应用或 Safari 应到达普通公开页面并报告运营商或家庭地址，而受管应用到达私有服务。如果两者报告同一个公网地址，隧道就不再是按应用，无论应用记录怎么说。
离开应用的流量制造混乱工单。在 Safari 中打开的链接、通过共享表单传出的文档，或转到浏览器的 SSO 登录，都会离开应用进程，隧道也随之离开。应用内显示的登录通常归因于应用，所以内嵌登录可能在同一 URL 于 Safari 失败的地方成功；要验证而不是假设。当身份提供方只能通过隧道访问时，把登录留在应用内，或把提供方域加入载荷的 Safari 域，以便匹配的 Safari 流量被捕获。
把症状与层对应
故障形态告诉你该重复哪项检查。
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
中间几行背后有两个细节：按应用隧道可以健康，却仍漏掉任何提供方列表都不含的子网；受管手机可以持有不止一个 VPN 配置，所以要确认应用绑定的是哪一个，而不是假设就是你正在读的那个。
按这个顺序修：让应用记录指向活动载荷，通过管理重装应用，确认隧道在应用第一次请求时起来，然后重复名称和边界测试。如果第一次请求根本无法启动隧道，停下来检查提供方一侧，因为自定义客户端需要 存在 Network Extension，并且标识符与已安装应用匹配。
返回三件事而不是截图：应用记录指向哪个载荷，设置是否把它显示为已安装描述文件，失败的请求是什么——名称、地址还是转交浏览器。这三个答案把部署错误与路由错误分开，下一个人不必重复诊断就能行动。