公司 VPN 一连上，调试代理就失明了

抓包工具整个上午都正常，隧道一连上，它就沉默了。断开又恢复。直觉会说 VPN 弄坏了代理，但代理配置其实什么都没变。变的是应用现在读取哪一份配置：隧道条目可以自带代理设置，受管理的配置描述文件会重新启用自动配置，而某些运行时只读取操作系统所提供设置的一部分。在动全局值之前，先读这条连接自己的值。

Windows 为每条连接单独保存代理

“Internet 选项”里有看上去完全相同的两层。LAN 设置作用于普通的本地连接，而拨号或 VPN 条目在 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections 下保留自己的一份副本，以二进制值存储。写入熟悉的全局注册表值不会更新那份副本。

工具在连接前工作正常、连接后却失灵，原因正是如此，而它的设置里看不出任何变化。你一直盯着的对话框是 LAN 面板。它是对的，也是无关的。Windows 实际使用的是为隧道创建的那一条。

受支持的修改单条条目的方式是 WinINET 连接选项 API：把连接名、标志、代理服务器和绕过列表填进 INTERNET_PER_CONN_OPTION_LIST，应用之后再刷新。想快速核对，就打开隧道条目自己的设置对话框，把它的代理面板和 LAN 面板对比；知道该看哪里之后，差异通常一目了然。

受管理的 PAC 会自己重新打开

在 macOS 上，自动代理配置脚本和自动发现代理属于某个网络服务的属性，而不是整台机器的属性。配置描述文件可以强制要求它们，因此取消勾选后它们还会回来，随后每个请求都被送到脚本选中的代理。

检查一下，如果获得授权，就把承载流量的那个服务的这两个开关关掉：

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

使用真实的网络服务名，而不是猜。同时有 Wi-Fi 和 USB 以太网适配器的笔记本有两个这样的服务，而只有其中一个承载你的流量。scutil --proxy 会打印当前主服务的取值。在断定描述文件赢了之前，先把这份输出和你改过的内容比对。

把工具指向真正的上游

如果脚本里写着公司代理，就读出来，把同一个地址作为外部代理填进抓包工具。这样工具会转发到真正的上游，也就是公司代理所期望的目标，它留在请求路径里，而不是去和策略较劲。

这一步能让你继续调试，而不是去重配。

把代理塞进隧道

基于 OpenVPN 的客户端可以接受隧道建立后才生效的代理选项，这在客户端掌握路由时很方便：

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

只有尊重该选项的客户端才会使用它，而且它会把你的监听端口写死在配置里。把它当作实验室里的便利，而不是部署标准，因为下一次推送配置就会把它删掉。

有些客户端从不读系统代理

Firefox 保留自己的代理设置，所以当使用系统代理的浏览器停下来时，它有时还在抓包。不理解自动配置的老式 .NET 客户端无论在哪里运行都直接连接，因此通过隧道条目加载的页面，在应用内部仍可能失败。

网络工具也有自己的原因。通过隧道或手机共享网络卡住的 FTP 会话，往往是客户端协商的主动与被动模式问题，任何代理设置都改变不了。

读配置，而不是看开关

按这个顺序排查：隧道条目自己的代理值，按服务区分的 PAC 与自动发现状态，然后是应用自身的代理处理。停在第一个与你的假设不符的地方。

这里的每一种情况都是配置优先级问题。没有一个是隧道弄坏了你的工具。