Windows Store 的商品页可以正常打开，开始安装时却只显示通用的稍后重试。前台应用与安装服务读取了不同的网络状态：桌面会话使用当前可用的本地代理，服务级 WinHTTP 配置仍指向已经没有监听进程的旧回环端点。

对齐代理后，目录与许可请求恢复，随后又出现了独立故障：大文件下载长时间停在同一字节数，而对实际内容主机进行直连和代理测速都很快。最终处理把两段故障分开，允许微软大文件 CDN 直连，并只重建已经证实卡住的 Delivery Optimization 下载项。安装包随后完成下载与部署，系统始终没有开启全局 TUN。

目录可用无法证明安装路径可用

通用错误很容易让人直接重置 …

IDE 在启动应用时弹出告警，提示无法打开运行配置中的 URL。浏览器稍后访问同一路由却能正常显示，应用也已经开始响应真实请求。告警看起来指向应用故障，用户实际依赖的路由却处于健康状态。

一次成功请求不足以解释这组现象。排查需要确认 IDE 检查了什么、检查发生在何时，以及这项控制面检查能否代表用户访问的应用数据面。

告警和应用描述的是两个时刻

运行配置启用了 IntelliJ IDEA 的 After launch，并填写了一个外部 URL。JetBrains 文档说明，该选项会在服务器和配置的产物启动后打开浏览器，URL 字段用于指定目标页面（Tomcat 运行配置）。

现场有四组看似冲突 …

一个自动代理组看起来仍有多个延迟正常的节点，当前策略组却会突然显示失败并停止转发流量。直接选择界面中延迟最低的节点只能偶尔恢复，因为部分正延迟来自旧记录，代理核心维护的实时健康状态又是另一套数据。

最终处理方式是在现有客户端外增加一个很小的本地故障守护。它不改订阅，不替换代理核心，也不调整系统代理。真实请求正常时，守护保持观察；连续失败后才临时接管；自动组恢复稳定后，再把控制权交还给原有策略。

先区分展示记录与运行时健康状态

排查首先确认，界面同时呈现了两类含义不同的证据：

• 桌面客户端保存的单节点延迟记录；
• 代理核心维护的实时探测与选中状态。

第一类数据中的正数只能说明某次测量曾经成功，不 …

同一个网站在外部网络可以正常打开，在一台 Windows 工作站上却持续超时。浏览器、命令行和应用接口都受影响，但其他需要代理的网站仍然可用。

这种现象很容易被误判为网站宕机、证书异常或代理客户端整体失效。真正有效的排查顺序，是先把远端服务、本机解析和流量分流拆开验证。

现象与证据

外部探测确认首页和接口都能返回成功响应，证书链也有效。这说明服务端、域名证书和公开路由并没有整体故障。

本机的直接访问却连接到与外部解析不一致的地址并最终超时。与此同时，通过现有本地代理发送同样的请求可以成功。这组对照把问题范围缩小到了本机的解析与分流链路，而不是网站应用本身。

进一步检查代理客户端的活动规则后发现 …

我一直使用桌面快捷方式，在不开启 TUN 的情况下为 Codex 单独设置本地代理。一次应用和代理客户端升级后，双击快捷方式不再启动 Codex，也没有清楚的错误提示。

检查发现 Codex 安装本身正常，真正的问题是启动脚本和全局配置都写死了旧代理端口，而代理客户端已经切换到新端口。脚本在启动应用前检测失败并直接退出。

不再猜测端口

修复后的 PowerShell 脚本按以下优先级选择代理：

1. 用户显式传入的 Proxy 参数；
2. Windows 当前用户代理设置；
3. 没有有效代理时明确报错并停止。

系统代理可能是简单的 host:port，也可能按 HTTP、HTTPS 分项配置。脚本统一解 …