Charles 已关闭，但你的 Mac 仍指向 127.0.0.1

某个应用失败，VPN 被当成替罪羊，但请求从未到达隧道。如果 macOS 仍让该应用使用本地代理，第一跳就是 127.0.0.1，而那里没有程序在监听。关闭 Charles 并不总会清除它安装的系统代理设置，于是一个正常的 VPN 却卡在死掉的套接字后面。下面按顺序确认，并且只修出错的那一处。

第一跳是这台 Mac，而不是服务器

按字面读这个地址：127.0.0.1 就是你面前的这台机器，而端口则是代理工具被配置来监听的端口。当监听者消失时，连接会立刻以拒绝连接失败，而不是超时，这正是有用的线索。

VPN 不会创建自己的代理设置，也不会删除系统的代理设置。这两套配置互相独立，所以隧道可能完好无损，浏览器却依然不可用。这种独立性也是为什么故障能在 VPN 重连、重启和新建配置文件之后依然存在。VPN 的路径上没有任何东西会碰代理存储。

第 1 步：读取当前代理状态

从只读视图开始，因为它会告诉你任何应用解释之前系统相信什么：

scutil --proxy

看 HTTPEnable、HTTPProxy、HTTPPort、HTTPS 对应项，以及任何带 URL 的 ProxyAutoConfigEnable。代理已启用但端口上没有任何程序监听，这就是你的故障。PAC URL 是另一种形态：设置可以在没有可见手动地址的情况下生效，因为文件在请求时选择代理。

然后在“系统设置 > 网络 > 你实际使用的服务 > 详细信息 > 代理”里确认相同的值。图形界面和命令读的是同一个存储，所以出现不一致就意味着你在看另一个服务。

第 2 步：找出这个设置归谁

三种归属者会造成这种状态：装了辅助程序却没有清理的代理工具、你所在组织的托管配置描述文件，以及有人在调试时手动加上的设置。每一种的正确修法都不同，只有第一种是你可以随手删掉的。

Charles 记录了它的浏览器与系统代理集成，包括 macOS 辅助程序，所以先用它自己的控件和关闭流程。特权辅助程序的存在是为了修改配置；这不是把机器的广泛权限交给无关软件的理由。

如果设置来自托管描述文件，本地禁用它要么失败，要么在下一次签入时被恢复。把这当作描述文件归属者的策略问题，而不是本地缺陷。

第 3 步：改最窄的那一处

只针对该服务的具体条目禁用它。不要切换所有服务，也不要清空整个代理面板，因为 VPN 服务和底层 Wi-Fi 服务各自保存设置，其中一个可能是正确的。

如果代理是被有意要求的，就启动它已获批准的监听程序，而不是删除策略。在代理是上网唯一通道、VPN 只是第二条更窄路径的组织里，这个区别很重要。

从受影响的应用重试一次全新的请求。有些应用只在启动时读一次代理，所以退出再打开是测试的一部分，而不是迷信。

第 4 步：如果代理已经没了却仍然失败

那你面对的是另一个问题，新的报错才是有用的证据。名称解析、VPN 路由、TLS 信任和应用授权是四项独立的检查，每一项都会产生可区分的失败。

不要把证书信任牵进这次修复。删除受信任的根证书或削弱服务器校验并不能修好一个死掉的代理套接字，反而让你同时面对两处改动和一个原始故障。如果企业代理会检查 TLS，那是有意设计并带有自己的信任要求，不是需要撤销的副作用。动证书之前先问代理的归属团队，因为他们的回答关于策略，而你的问题只关于一次失败的请求。

开始之前先写好回滚：记下你找到的确切代理值，这样恢复就是复制，而不是凭记忆。 Charles 代理配置文档 介绍了集成方式以及你所运行版本的关闭行为。

下次应用在 VPN 上失败时，先检查第一跳，再看隧道。它只花一条命令，却能排除一整类误诊。