Windows 中浏览器可以访问，并不代表终端和后台服务使用了相同代理。排查应先确认请求由哪个程序发起、读取哪套设置，再检查代理端口和规则。直接反复开关全局模式，容易把作用范围问题误判为节点失效。
先画出请求经过的路径
把一次访问拆成应用、代理入口、客户端内核、远端节点和目标服务五段。系统代理主要向愿意读取它的应用提供代理地址；它不是强制接管所有网络连接的承诺。应用也可能使用自己的代理设置，终端工具还可能读取环境变量。后台服务的运行账户和网络库又可能不同，因此同一台电脑上出现三种结果并不矛盾。
微软分别提供 Windows 代理设置和 WinHTTP 配置文档，说明不能仅凭系统设置界面的一个开关判断全部请求。本文不建议为方便而把所有层同时改掉。先记录现状，才能知道后面的变化究竟影响了谁。
建立一张本地记录表，列出浏览器、下载工具、命令行工具、更新服务，旁边写明是否成功、测试时间、目标地址及应用自身的代理选项。未知的项目写未知，不凭图标推断。用同一个普通测试页面比较时，也应避免登录状态、缓存和重定向造成不同结果。
浏览器正常而终端失败
先检查终端工具的官方说明，确认其代理参数和环境变量支持。不要把适用于一个工具的写法当作所有程序通用语法，也不要把含密码的代理地址直接保存在公开脚本里。终端继承的是启动时环境，修改环境变量后，已经打开的窗口未必立即获得新值。
一种可操作的编辑建议是：新建临时终端，明确指定本地代理做一次请求，然后在不指定代理的条件下再请求一次。记录两次完整错误类别，例如连接被拒绝、名称解析失败或者握手失败。测试只改变代理使用方式，保持目标、节点和时间尽量接近。前者成功、后者失败，说明差异值得沿作用范围调查，但仍不能排除工具对解析方式的不同处理。
如果提示本地端口拒绝连接，先看客户端是否真正启动了内核，以及工具填写的入口类型是否正确。HTTP 代理入口和 SOCKS 入口不是可以任意交换的名字。也不要因为远端节点采用某种协议，就把相同名称填进应用的本地代理设置；本地入口与远端出站是两个独立环节。
后台服务单独检查
后台服务可能读取 WinHTTP 设置，具体行为取决于服务实现。可先查阅微软的只读查看方式，记录当前配置，再查对应产品文档；不要直接照搬网上的全机重置命令。公司设备还可能由管理策略提供配置，手动覆盖会造成新的故障。
服务以不同账户运行时，当前用户可以访问的文件、证书或凭证不一定对它可用。一个常见误区是用管理员身份运行测试后成功，就认定问题已经解决；这只说明测试条件改变了。应回到实际服务账户及实际启动方式验证，而不是长期提高整个客户端的权限。
如果系统更新失败而普通网页正常，应保留更新组件的错误码和时间，不要只提交浏览器截图。后台任务可能访问多个域名，首页可达不能证明更新内容分发地址可达。关联故障时需要同时查看目标请求和客户端日志，日志处理可参考客户端日志脱敏指南。
TUN 不是一键消除差异
TUN 通过虚拟网络接口处理流量，其接管范围仍受路由、权限、排除规则及地址族影响。启用它可以改变测试条件，却不能自动证明之前的节点或系统代理配置有错。若它导致局域网设备无法访问，应检查路由和例外，而不是连续叠加更多代理软件。
例如，示例场景中浏览器成功、终端失败、打印机可达。打开 TUN 后终端成功但打印机不可达，这实际上包含两个问题：前者提示终端原本可能未使用代理，后者提示新接管规则影响了局域网路径。将两者分别记录，才不会用解决一个问题的方法制造另一个问题。入口和出口的关系见TUN 路由环路排查。
留下可恢复的最终配置
验收不只是打开一个网页。至少检查常用浏览器、一个终端任务、需要联网的后台功能及局域网服务；关闭客户端后，还应确认是否有应用继续指向已经关闭的本地端口。把最终采用的作用范围写入记录：哪些依赖系统代理，哪些采用应用配置，哪些由虚拟接口接管。
排查完成后删除临时环境变量和试验参数，避免下次升级时被遗忘的设置抢先生效。保留原始设置截图而不是密码截图。以后出现同样现象，先对照这张范围表，再进行一次只改一个变量的配置测试，通常比重装全部软件更容易找到原因。
对于偶发失败，至少补记一次成功样本。失败发生时只有终端没有请求记录，而成功时能看到相同目标进入内核，这类差异比单纯比较下载速度更能说明接管范围。记录中也要注明是否重启过应用，避免把新进程继承设置的效果误认为线路恢复。
参考资料
- Microsoft：Windows 代理设置，核验日期：2026-10-15。
- Microsoft：netsh winhttp，核验日期：2026-10-15。本文测试流程为编辑建议，不代表所有应用实现。