上午9:14，后台数据同步服务再次开始失败。每隔几分钟就会抛出连接错误，而坐在同一工作站的用户正常加载网站，Windows代理页面已经显示了企业代理。浏览器工作正常，但服务却不行。
这种情况通常并不矛盾。这意味着浏览器和服务可能使用不同的网络堆栈。在更改代理之前，打开管理员命令行并运行 netsh winhttp show proxy。此命令回答了一个狭窄但重要的问题：机器级 WinHTTP 配置告诉后台进程使用什么？
当工作正常的浏览器隐藏了损坏的服务时
我检查的第一件事是失败进程的上下文。Windows 服务可能通过 services.exe 运行，使用 SYSTEM 凭据，并继承与交互用户配置不匹配的组策略设置。计划任务或更新代理也可能面临相同的分裂。操作员在浏览器或 Windows 设置中看到配置的代理，但非交互进程看到的是直接访问。
这种不匹配在锁定环境中很常见，在这些环境中，组策略或移动设备管理应用了用户设置，但没有应用相应的机器级设置。结果是一个服务不断尝试直接连接，即使测试连接的人有一个正常工作的浏览器会话。
实用规则：测试失败的网络上下文。浏览器测试证明浏览器可以连接，并不意味着服务帐户可以。
运行：
netsh winhttp show proxy
微软将此命令记录为显示当前 WinHTTP 代理设置的方法。它报告 WinHTTP 是否使用直接连接或配置的代理，以及代理服务器和绕过列表，尽管微软现在将 show proxy 标记为不推荐使用，并建议在其 WinHTTP netsh 命令文档 中使用 show advproxy 进行较新的配置。
其余的诊断取决于正确读取该结果。您需要区分 WinHTTP 和 WinINet 以及浏览器设置，识别失败的进程是否在不同的帐户或位数下运行，并在与服务相同的上下文中测试更改。首先使用该命令，因为它消除了调查第一层的猜测。
什么是 WinHTTP 以及为什么它有自己的代理设置
WinHTTP 是 Windows 中的系统级 HTTP API。它为服务和其他非交互式应用程序提供了一种发出 HTTP 和 HTTPS 请求的方法，而不依赖于已登录用户的浏览器会话。微软将 WinHTTP 设置描述为机器级配置，供依赖 WinHTTP API 的应用程序使用，设置通常在创建会话时应用，并可能在 WinHTTP 代理配置指南 中为单个请求覆盖。
代理服务器 是一个中介，将客户端请求转发到其目标。绕过列表 是一组 WinHTTP 应该直接联系的主机，而不是通过该中介发送。直接访问 意味着在 WinHTTP 层没有配置代理，因此请求直接发送到其目标，除非应用程序应用了其他规则。
这些设置可以与浏览器设置分开存在。WinINet 是与较旧的交互式应用程序和每用户 Internet 选项相关的 Windows 客户端网络层。现代浏览器也可能维护自己的网络行为。更改一个层不会自动更改其他层。
这种分离对于实际工作负载很重要：
- Windows 服务 可以使用 WinHTTP，而已登录用户依赖于浏览器堆栈。
- 计划任务 可以在具有不同凭据和配置设置的服务身份下运行。
- Windows 更新和管理代理 可以依赖于机器级连接。
- 后台自动化 可以继承系统配置，而不是浏览器窗口中选择的代理。
微软的 Windows 更新指南明确使用 netsh winhttp show proxy 来验证代理配置，然后再扫描或下载更新。同样的文档确认 netsh winhttp 命令可以在 netsh 提示符下或在脚本和批处理文件中交互式运行，这使得该命令对于可重复的管理非常有用，而不仅仅是一次性检查。
对于 WinHTTP 客户端而言，netsh winhttp show proxy 因此是该特定层的权威读取。它不是计算机上配置的每个代理的通用报告。
运行命令并读取输出
当您需要检查或更改机器级设置时，请使用具有管理员权限的命令行。
- 打开开始菜单并输入
cmd。 - 右键单击 命令提示符 并选择 以管理员身份运行。
- 输入
netsh winhttp show proxy并按 Enter。
PowerShell 也可以。命令语法是相同的，因为 PowerShell 可以直接调用 Windows netsh 实用程序。
在支持的新版本 Windows 配置中，输出可能包括一个不推荐使用的通知，建议使用 show advproxy。将该通知视为关于命令接口的指导，而不是证明显示的设置无效。输出的主体仍然告诉您当前 WinHTTP 层的报告。
您通常会解释以下状态之一：
- 直接访问（没有代理服务器） 意味着 WinHTTP 在此层没有配置代理。
- 代理服务器：server:port 意味着 WinHTTP 配置了代理端点。
- 绕过列表 确定应该直接联系的主机。
代理值以主机和端口的形式写出，例如 proxy.corp.local:8080。像 <local> 这样的绕过条目表示应该避免代理的本地或内部网络目的地。
该命令报告与 HKEY_LOCAL_MACHINE 相关的每台计算机的配置，而不是存储在 HKEY_CURRENT_USER 下的每用户配置。在 64 位 Windows 上，一些 32 位进程可以读取单独的 WOW6432Node 注册表视图。当服务和管理员的诊断命令行似乎不一致时，这种区别变得重要。
解释直接访问与配置代理
输出很简短，但每种状态指向不同的故障路径。
直接访问（没有代理服务器） 意味着 WinHTTP 层直接将请求发送到其目标。浏览器代理或每用户 Internet 选项设置不会覆盖 WinHTTP 客户端的结果。如果后台服务必须通过企业代理进行访问，直接访问可以解释为什么它无法到达外部端点，而用户的浏览器继续工作。
配置的结果在概念上看起来更像这样：
代理服务器：proxy.corp.local:8080绕过列表：<local>;internal.example
代理地址标识中介。绕过列表告诉 WinHTTP 哪些目的地应该跳过它。一个过于宽泛的绕过规则可以在应该检查或通过企业路径路由时直接发送流量。一个过于狭窄的规则可以将内部流量发送到无法解析或到达内部主机名的代理。
不要仅仅停留在代理线路的存在上。确认受影响的应用程序使用 WinHTTP，终端不受绕过规则的覆盖，并且该进程读取您检查的相同注册表视图。设置也可以通过策略或其他管理更改被清除，导致机器在某人认为已应用代理后处于直接模式。
| 输出模式 | 这意味着什么 | 系统管理员可能看到的故障 |
|---|---|---|
| 直接访问，无代理服务器 | WinHTTP 在此层没有代理 | 服务尝试直接进行外部流量 |
| 带有绕过列表的代理服务器 | WinHTTP 通过指定的代理路由符合条件的流量 | 内部名称失败，因为它们通过错误的路径发送 |
| 代理存在，意外排除 | 绕过规则在请求到达代理之前改变路由 | 某些目标工作而其他目标始终失败 |
该命令不测试身份验证、DNS 解析、防火墙策略或应用程序级覆盖。它告诉您应用程序所提供的 WinHTTP 路由。
WinHTTP 与 WinINet 与浏览器代理设置
将代理配置视为堆栈图，而不是单一的 Windows 设置。WinHTTP、WinINet 和浏览器级配置可以在一台设备上共存，每个应用程序决定读取哪个层。
WinHTTP 是面向机器的层。它通常为后台 Windows 组件和基于 WinHTTP API 构建的应用程序提供服务。WinINet 是一个更高层次的客户端库，历史上与交互式 Windows 应用程序和每用户的 Internet 选项相关联。浏览器配置可能遵循操作系统设置，使用配置文件级设置，或应用自己的规则。
| 堆栈 | 设置所在位置 | 使用者 | netsh 或浏览器等效项 |
|---|---|---|---|
| WinHTTP | 机器级 WinHTTP 配置 | 使用 WinHTTP 的服务、计划任务、更新和管理进程 | 使用 netsh winhttp show proxy 读取；浏览器更改不会自动更新它 |
| WinINet | 每用户 Internet 选项和相关用户上下文 | 为 WinINet 构建的传统交互式应用程序和客户端 | 与 netsh winhttp 不可互换 |
| 浏览器代理 | 浏览器或操作系统集成，具体取决于浏览器 | 交互式浏览和浏览器驱动的工作流 | 一个正常工作的浏览器会话并不能证明 WinHTTP 已配置 |
这就是为什么将代理复制到浏览器设置中可能会修复交互式测试，而不改变计划的抓取器、QA 工作人员或更新服务。反之亦然。运行 netsh winhttp set proxy 可以改变机器级行为，而不改变已登录用户在 Internet 选项中看到的内容。
对于自动化合法市场研究、广告验证、价格监控或地理依赖 QA 的团队，在选择代理集成方法之前识别客户端堆栈。有关应用程序端设置概念的有用参考是这个 代理设置指南，但 Windows 诊断仍然从失败的进程和它使用的层开始。
心理模型很简单：浏览器成功是浏览器结果，WinINet 成功是用户上下文结果，而 WinHTTP 成功是机器或服务上下文结果。不要将一个作为另一个的替代品。
设置、导入和重置 WinHTTP 代理
检查应在修改之前进行。如果输出确认 WinHTTP 是涉及的层，请有意识地使用相关命令并记录先前状态。
传统的显式配置如下所示：
netsh winhttp set proxy proxy-server="proxy.corp.local:8080" bypass-list="<local>;internal.example"
proxy-server 值标识终端，而 bypass-list 包含应直接连接的目标。微软现在将较旧的 set proxy 和 show proxy 路径视为新配置的遗留管理。对于自动发现、基于 PAC 的路由或更高级的企业设置，请使用 advproxy 命令：
netsh winhttp show advproxynetsh winhttp set advproxy
导入是另一种选择：
netsh winhttp import proxy source=ie
该命令将当前每用户的 WinINet 配置复制到机器级 WinHTTP 上下文中。当用户的设置被认为是正确时，这可能很方便，但在多用户服务器上可能会让您感到惊讶，因为用户上下文配置变成了机器范围的设置。
要将 WinHTTP 恢复为直接访问，请使用：
netsh winhttp reset proxy
微软特别警告不要依赖 netsh winhttp set proxy 进行交付优化，因为它不提供自动检测、PAC URL 支持或代理身份验证支持。这使得显式的 set proxy 不适合依赖自动发现或经过身份验证的代理链的企业工作流。有关自动发现概念的背景，请参见这个 自动代理设置指南。
以管理员身份运行命令提示符，然后按照此顺序进行：
- 读取当前状态。
- 更改一个设置。
- 再次运行
show proxy或show advproxy。 - 从受影响的服务上下文进行测试。
- 如果更改加重了事件，则重置。
错误的机器级值可能会影响主机上的每个 WinHTTP 客户端，而不仅仅是您正在调查的应用程序。
命令揭示的常见代理不匹配
痛苦的 Windows 代理故障通常不是由明显为空的配置引起的。它们来自于在一个上下文中看起来正确而在另一个上下文中看起来错误的配置。
| 不匹配模式 | 症状 | 典型根本原因 |
|---|---|---|
| 浏览器有代理，WinHTTP 报告直接访问 | 交互式浏览正常，但服务无法到达其终端 | 用户设置从未应用到机器级 WinHTTP 层 |
set proxy 已运行，但服务仍然绕过它 |
管理员在一个测试中看到代理，而服务继续直接连接 | 该进程使用了另一个堆栈、帐户上下文或注册表视图 |
| 32 位和 64 位行为不同 | 一个应用程序在同一主机上工作，而另一个失败 | 进程读取不同的 WOW64 和本机注册表视图 |
| 代理配置后内部目标失败 | 外部请求正常，但本地服务调用失败 | 绕过列表未包含所需的内部目标 |
第一个模式是经典的浏览器与服务的陷阱。用户通过 Internet 选项或浏览器界面配置代理，但 WinHTTP 命令返回直接访问。Windows 更新和其他机器级客户端可以遵循与浏览器不同的路径。
第二个模式通常出现在匆忙更改之后。操作员运行 set proxy，确认命令完成，并假设每个进程现在都使用该值。受影响的服务可能根本不使用 WinHTTP，或者它可能在具有不同用户级设置和应用程序覆盖的上下文中运行。
第三个模式值得检查注册表视图。一个在 WOW64 下的 32 位进程可以读取 HKLM\SOFTWARE\WOW6432Node，而 64 位服务读取本机机器视图。直接编辑注册表的脚本可以更新一个视图而不改变另一个视图。在每次更改后重新运行诊断，并将结果与实际进程的行为进行比较。
逐步排除 WinHTTP 代理问题
使用分层过程。反复更改代理值而不识别客户端堆栈会产生噪音，并可能破坏无关的服务。
- 识别堆栈。 确认失败的应用程序是使用 WinHTTP、WinINet、浏览器管理的配置，还是特定于应用程序的设置。不要将浏览器的成功作为服务的证据。
- 读取机器状态。 在管理员命令提示符下，运行
netsh winhttp show proxy并记录结果是直接访问还是配置的代理。 - 检查路由。 验证配置的代理主机和端口是否可以从受影响的机器访问，并确保目标没有意外被旁路规则覆盖。
- 检查进程上下文。 确认进程是 32 位还是 64 位，然后在适用时将本地 WinHTTP 注册表视图与
WOW6432Node视图进行比较。 - 在服务身份中重现。 如果进程以 LocalSystem 身份运行，请使用
psexec -s -i cmd打开诊断 shell，运行相同的命令并比较结果。
要进行更深入的追踪，请使用 netsh winhttp show tracing 启用追踪，重现故障，然后禁用追踪，以免诊断日志不必要地增长。将请求失败与事件查看器中的 应用程序和服务日志，Microsoft，Windows，WinHttp 进行关联。
值得检查的注册表位置是 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp 及其 WOW6432Node 兄弟。如果您需要一个实用的连接故障检查清单，这个 拒绝连接的代理指南 可以补充 Windows 端的检查。
依赖 WinHTTP 的自动化用例
当代理堆栈错误影响无人监视的进程时，它就成为了一个操作问题。Windows 更新、交付优化、管理代理和其他后台组件可能依赖于 WinHTTP。尽管机器在登录的操作员看来仍然健康，但补丁检索、遥测、注册或与证书相关的网络请求在后台可能会失败。
该命令对 Windows 原生自动化也很重要。轮询 API、同步数据、检查价格、验证广告位置或运行合规 QA 工作流的计划任务可以继承机器级网络，而不是浏览器的代理。如果该任务在服务帐户下运行，请测试该帐户的上下文，而不是假设管理员的会话是代表性的。
在交互式浏览器中有效的代理并不自动意味着在自动化中有效。
代理类型与 Windows 堆栈选择是两个独立的决策。数据中心代理 通常提供基础设施托管的地址和可预测的连接性。住宅代理 使用与住宅接入网络相关的地址。移动代理 使用 4G 或 5G 运营商连接，其中运营商级 NAT 可能将许多订阅者放置在共享的移动地址空间后面。
移动 IP 对服务的分类和阻止可能比数据中心地址更困难，因为它们类似于普通的运营商流量，但这并不消除对负责任的速率控制、账户所有权、平台合规性或准确识别的需求。对于使用这些协议的客户端，选择 HTTP 或 HTTPS，对于应用程序特别支持的选择 SOCKS5。然后将轮换、粘性会话、ASN 和地理定位与工作流对齐，而不是将轮换视为健全自动化设计的替代品。
Netsh WinHTTP 子命令快速参考
使用管理员 shell 进行更改。每次修改后读取输出，并记住 32 位和 64 位进程可以使用不同的注册表视图。
| 子命令 | 目的 | 何时使用 |
|---|---|---|
show proxy |
显示传统的 WinHTTP 代理状态 | 在初步检查期间快速兼容性检查 |
show advproxy |
显示更新的高级代理配置 | 现代配置的首选 |
show state |
显示 WinHTTP 配置状态 | 检查更广泛的命令上下文 |
set proxy proxy-server="host:port" bypass-list="hosts" |
应用传统的显式代理 | 受控的遗留或简单环境 |
set advproxy |
应用高级代理设置 | PAC、自动检测或现代企业配置 |
import proxy source=ie |
将当前用户代理复制到 WinHTTP | 仅在用户配置已知适合全机器时使用 |
reset proxy |
恢复直接的 WinHTTP 访问 | 删除故障的传统代理配置 |
show tracing |
控制 WinHTTP 诊断追踪 | 捕获可重现的请求失败，然后禁用它 |
微软的 WinHTTP 命令参考 记录了交互式和脚本化使用，这在这些检查成为部署或合规脚本的一部分时非常有用。
关于该命令的常见问题
为什么浏览器在 WinHTTP 报告直接访问时仍然可以工作
它们可以使用不同的代理堆栈。浏览器或每用户配置不会自动填充机器级 WinHTTP 设置。
该命令在 PowerShell 中有效吗
是的。以管理员权限打开 PowerShell，并像在命令提示符中一样运行 netsh winhttp show proxy。
PAC 文件如何适应这一点
PAC 文件提供自动代理选择逻辑。使用高级 WinHTTP 配置路径进行 PAC 或自动发现，而不是将传统的 set proxy 语法视为完全替代。
没有提升会发生什么
您可能能够读取一些信息，但机器级更改需要具有管理员权限的 shell。如果更改似乎未影响服务，请以管理员身份重新打开 shell 并验证结果。
为什么 32 位进程可能与 64 位服务不一致
在 WOW64 下，32 位和 64 位进程可以读取不同的注册表视图。检查失败进程使用的视图，而不是依赖于不相关的 shell 的结果。
为您的工作流选择可靠的代理层
该命令告诉您 Windows 机器是直接路由 WinHTTP 流量还是通过配置的中介。它并不决定中介是否适合您的工作流。
对于多账户社交媒体管理、广告验证、市场研究、价格和 SEO 监控、品牌保护以及地理依赖的 QA，首先考虑流量模式。粘性会话 有助于在工作流依赖于相同 IP 时保持连续性。轮换 在不同的合法任务需要不同出口时很有用。ASN 和地理位置 在验证服务如何在运营商网络或位置上表现时很重要。HTTP、HTTPS 和 SOCKS5 支持应与将使用代理的客户端相匹配。
移动 4G 代理可以适应运营商网络存在比数据中心出口更重要的工作流。使用它们时要明确账户所有权、保守的自动化以及尊重每个平台的规则。Evoproxy 提供移动代理访问，用于合规的社交媒体、验证、研究和测试工作流，为团队提供了在确认其应用程序使用哪个 Windows 堆栈后评估的另一层。
如果您的服务、验证工作者或多账户工作流需要基于运营商的路由，请针对失败的确切 WinHTTP 上下文测试移动 4G 代理。访问 Evoproxy 查看适合您用例的移动代理选项，并在将其推广到您的 Windows 自动化主机之前验证配置。
