先看应用走哪一层代理
Throne 的 System Proxy 会在运行 Profile 时设置操作系统代理，让遵循该设置的应用连接本地混合代理端口。它不会自动改写每个程序的独立配置，也不等于接管全部 Windows 流量。Windows 10 与 Windows 11 的设置入口外观可能不同，排查时以“网络和 Internet”中的代理状态为准。
WinINET 与 WinHTTP 是不同的 Windows HTTP 接口。WinINET 常面向交互式应用，WinHTTP 面向服务及其他 HTTP 客户端场景；程序还可以使用自身网络库。因此不能根据程序是“浏览器”或“后台服务”，就断言它必然采用某一个接口。先查应用说明，再用实际请求核对。
| 设置层 | 需要确认的内容 |
|---|---|
| Windows 用户代理 | 手动代理、自动配置脚本与设备管理策略是否启用 |
| WinHTTP | 应用是否使用该接口，以及是否自行提供会话代理配置 |
| 应用独立代理 | 是否另填 HTTP 或 SOCKS 地址，是否读取环境变量 |
可先阅读系统代理与模式选择指南，把客户端运行、系统设置与应用请求三个层次分开记录。
只读查看，不急于同步或重置
先截图保存 Windows 当前代理开关、地址和脚本设置。公司管理的设备还可能受到策略约束，不要直接覆盖。随后可在终端查看 WinHTTP 当前配置：
netsh winhttp show proxy
netsh winhttp show advproxy第二条命令是否支持取决于 Windows 版本；若提示不支持，请保留第一条结果并查阅本机命令帮助。这些查询不修改设置。看到 WinHTTP 为直连，也不能单独判定故障，因为应用可能在会话级别自行选择代理或自动发现。
需要向维护人员提供结果时，先遮蔽内部代理主机名、账号和自动配置地址。不要把组织网络信息完整贴到公共讨论中。
再核对地址、协议与真正的监听
127.0.0.1 是本机回环地址，只指向当前设备。Throne 的本地混合入站可接收 HTTP 与 SOCKS 请求，但实际监听地址和端口应以当前实例为准；项目文档中的端口只是示例，不能代替本机状态。配置里填写一个端口，不代表核心已经成功监听。
HTTP 代理、用于 HTTPS 目标的 HTTP CONNECT，以及 SOCKS 是不同概念。HTTPS_PROXY 变量的名称并不意味着其值一定使用到代理服务器的 HTTPS 传输；格式必须符合相应工具的文档。若连接被拒绝，先按本地端口冲突检查方法核对监听进程，而不是立即更换远端 Profile。
HTTP_PROXY、HTTPS_PROXY 是许多命令行程序支持的约定，不是全系统开关。有的工具只读取小写变量，有的采用专用选项。记录应用当前环境后，再确认该应用究竟读取了什么。
用一个应用、一个请求完成验证
选择一个允许访问、结果可重复的目标，记录浏览器与问题应用的访问时间，再查看是否有对应客户端连接记录。先保持其他设置不动，只核对问题应用的代理来源；若请求根本没有到达 Throne，改变路由规则也无从影响它。
如果差异出现在客户端退出后，检查系统是否还指向已消失的本地监听，可继续阅读强制退出后的系统代理恢复流程。如果多个程序都失败，还要检查底层网络与 DNS，不能把所有问题归结为 WinHTTP。
