Apple VPN 配置里的代理字段究竟做什么
填写代理字段并不会让 VPN 变成 HTTP。这里涉及两个连接，而这个字段只通向其中一个。
在 Apple VPN 配置里填写 Proxy 字段，会让人觉得它应该把隧道改走某个 Web 端口。其实不会。这个字段只是为愿意把流量送往那里的兼容应用，选择一个应用层中间人。而 VPN 客户端自身到网关的连接，由你配置的协议、监听端口和传输方式决定，那是另一套独立的决定。
两个连接，两个归属
任何这类配置都包含一条从客户端到网关的连接，以及一条从应用到目的地的连接。Proxy 部分说的是后者，尽管它与前者位于同一个配置文件里。
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apple 的 代理设置参考 列出了 HTTP、HTTPS、SOCKS 和自动代理配置，这描述的正是应用的代理选项。这些条目没有一条说明 IPsec 或 WireGuard 数据包如何到达网关。
有一个快速检查可以定论：说出 VPN 客户端在日志里报告的端口和协议。如果那一行仍写着 UDP 500 或 UDP 51820，代理字段就没有改变它。
什么时候这个字段才是正确的工具
确实存在代理位于隧道之前的情形，但 那是客户端特性，不是配置字段。OpenVPN 手册记录了用于经 HTTP CONNECT 代理承载的 TCP 连接的 --http-proxy。要用它，需要匹配的客户端选项、能这样到达的网关，以及允许 CONNECT 到所用端口的代理。
如果你的客户端提供该选项，且网络允许 CONNECT 到该端口，它就可能奏效。如果客户端不提供，填写系统代理对隧道毫无影响。
什么时候它毫无改变
IKEv2 或 IPsec 配置不会因为代理字段被填写就变成 HTTP 隧道。WireGuard 也不会，它的配置格式里根本没有代理概念。改网关端口同样不改变它的协议。而一个响应普通 HTTPS 的端点，不会自动成为 VPN 监听端口。
同一个陷阱也会抓住那些从旧 iPad 教程里照抄 PPTP 时代配置的人。选项在界面上仍然存在；背后的服务早就不再使用那套协议了。
判断该修哪一层
动手之前先问是哪一层失败了。如果客户端无法建立会话，问题在传输，代理字段无关。如果隧道已建立但某个应用连不上自己的服务器，值得检查应用层代理。如果隧道已建立而所有应用都失败，可疑的是隧道内的路由和 DNS。
第一种情况下，去问运营商支持哪种获准的替代传输或网络。OpenVPN over TCP 443 之所以存在，是因为有些网络只放行它，而且仍要求服务器在该端口监听。
不要把被封的 UDP 端口当成随意变通的许可。保持网关证书或身份校验不变，而不是为了迁就握手而关掉它们。
逐层确认两个连接
先确认隧道：在客户端状态页查看是否已建立会话，字节数是否不为零。然后 直接读取代理设置，用 scutil --proxy 查看生效配置，或用 networksetup -getwebproxy Wi-Fi 查看已存值。接着分别测试一个遵循系统代理的应用和一个忽略它的应用，因为很多原生应用会忽略它。
三种结果，三种不同的修法。
如果两层都报成功而应用仍然失败，就去看分离隧道、DNS 以及应用自身的网络设置。那是第三层，也同样不是代理字段。