系统更新连不上代理？WinHTTP 设置与服务账户检查

浏览器能上网，系统更新却连不上代理，先核对更新使用的代理配置、后台服务账户，以及失败发生在检查还是下载阶段。浏览器成功只说明那次浏览器请求可用，不能证明后台更新采用了同一个入口和身份；也不要先把所有问题归为节点失效。

本文面向 Windows 上使用本地代理、VPN 或组织代理的读者。先做只读检查，保留错误和原配置，再决定是否需要调整。若连浏览器也无法访问，可先按VPN 已连接却无法上网的检查清单排除基础连接问题。

先分清“检查更新”和“下载更新”

更新界面显示失败，不代表每个阶段都采用相同的访问方式。Microsoft 的流程文档说明，更新检测与非检测请求的代理尝试顺序不同，某些错误会触发另一类配置的尝试；内网 WSUS 还可由策略指定行为。不能概括成“Windows 更新永远只读系统代理”或“总会自动沿用浏览器设置”。依据：Windows Update 工作流程

先记录失败时界面究竟在检查、下载还是安装，是否已经发现更新，以及完整错误码。只有下载进度不动时，不要用安装失败的清理教程直接处理它。

当前现象	优先检查	尚不能说明
浏览器正常，检查更新失败	更新源、WinHTTP 配置、代理认证	不能据此认定所有应用都应改代理
能找到更新，下载失败	下载阶段的访问路径、响应和传输限制	不等于扫描配置完全错误
退出本地客户端后才失败	代理入口是否仍有人监听	不一定是更新服务损坏
已下载完成，安装或重启报错	对应安装错误及系统日志	不能继续只用换节点解释

第一步：读取 WinHTTP 配置，不急着导入

打开终端，先查看当前系统支持的命令：

netsh winhttp show advproxy

它用于显示 WinHTTP 的高级代理配置。核对代理地址、绕过列表、自动配置脚本和自动检测项，并保留输出。Microsoft 的 Win32 文档已将旧的 show proxy 标为弃用并推荐 show advproxy；如果当前系统不支持高级命令，可记录版本，再用兼容查询查看基础配置：

netsh winhttp show proxy

这两条是查看命令，不会替你设置代理。高级与基础输出的范围不同，不能把一次 DIRECT 显示当成所有进程必然直连的证明；应用自身配置、自动发现和 TUN 路由仍需分别核对。依据：WinHTTP Netsh 命令

再与 设置 → 网络和 Internet → 代理 中的手动地址和脚本进行对照，重点找三种差异：一边有固定地址、另一边没有；端口仍指向已经退出的程序；脚本地址或绕过范围不同。不要为了让两份显示一致，就立即复制所有设置。

第二步：核对后台账户与代理入口

可在 PowerShell 中只读查询 Windows Update 服务的账户和状态：

Get-CimInstance -ClassName Win32_Service -Filter "Name='wuauserv'" |
    Select-Object Name, State, StartName

StartName 表示服务运行账户，State 是当前状态；这不是一次更新访问的认证记录，也没有列出全部下载组件。某个时刻服务未运行，也不足以单独断言其损坏。依据：Win32_Service 属性

浏览器里完成的一次代理登录，不能直接证明后台服务也具有所需认证条件。若报 0x8024401B，微软将其对应到 HTTP 407，即代理要求认证；应检查服务访问更新源时能否完成代理认证，而不是先重输自己的系统登录密码。依据：常见更新错误

若地址是 127.0.0.1:某端口，它指向本机入口。确认客户端此刻运行、实际端口没有变化，并检查后台更新发生时它是否仍可用。这里需要的是兼容的 HTTP 代理入口；不要把 SOCKS5 端口、远端节点端口或订阅地址填进去。WinHTTP 的相关命令文档明确提示不支持 SOCKS5。

第三步：区分缺少配置与不同的接入方式

系统代理、应用自己的代理和 TUN 是不同层面的接入方式。若已经使用 TUN 接管，WinHTTP 显示没有固定代理，仍可能通过系统路由进入客户端；反之，客户端写着“全局”，也不能证明更新流量已经进入。概念可参考规则、全局与 TUN 的区别。

在故障时间前后对照客户端连接记录，查看更新相关请求是否出现、采用什么出站、错误停在哪个地址。没有日志时，也先核对日志覆盖范围，别把“没看见”直接当作“完全没有请求”。

若使用 PAC，除了地址是否存在，还要核对后台环境能否取得脚本，以及脚本对实际更新目标返回什么结果。浏览器打开脚本成功，不足以替后台账户作证。自动配置的基本机制可查WinHTTP AutoProxy 说明。

确认不一致后，怎样调整才可回退

个人设备确实需要设置 WinHTTP 时，先保存现有高级配置、脚本与绕过列表，再按本机支持的 set advproxy 文档配置适用范围和真实 HTTP 入口。组织管理的设备则应把检查记录交给管理员，结合更新源与策略调整。每次只改一项，之后仍用原更新流程重试并记下结果。

不要把 netsh winhttp import proxy source=ie 理解成“复制当前任何浏览器的一切配置”。它导入的是 IE/Internet Options 对应设置，也会改变 WinHTTP 配置；导入不是只读测试，更不能保证同步某个客户端今后的端口变化。依据：netsh winhttp 导入说明

同样，reset proxy 是把对应设置重置为 DIRECT，不是恢复先前那套组织代理。需要回退时，应恢复自己保存的原配置，不能把重置当作通用修复。

用一张记录表决定下一步

记录项	填写内容
故障阶段	检查／下载／安装，以及时间与时区
更新来源	公网更新或组织提供的更新源；不确定则注明
配置	WinHTTP、用户代理、PAC、TUN 的实际状态
入口	本机协议与端口，客户端是否持续运行
错误	完整错误码、目标主机和脱敏后的日志
对照结果	本轮只改了什么，重试后哪个阶段发生变化

如果能检查却下载失败，还应核对代理对 HTTP Range 请求的支持；微软的更新排障文档将其列为下载相关检查点。依据：HTTP／代理问题 Range 的含义可继续阅读断点续传与状态码说明。

若失败的是 Git、curl 等终端程序，应转到终端代理排查，不要假定修改 WinHTTP 能覆盖它们各自的配置。