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

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

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

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

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

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

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

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

现场有四组看似冲突 …

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

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

现象与证据

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

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

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

应用日志不断出现 Dubbo RemotingException，最深层异常是 Connection refused。堆栈很长，前面还夹杂业务接口、代理类和重试线程，很容易让人先去检查调用参数或客户端代码。

但 Connection refused 的含义非常具体：目标地址可以路由到，TCP 连接却被立即拒绝。通常是目标端口没有进程监听，或容器刚好停止。它与请求超时、DNS 失败和业务异常不是同一类问题。

沿最深层异常向外验证

排查顺序从网络事实开始：

1. 消费端最终尝试连接哪个 host 和 port；
2. 对应端口是否存在监听；
3. 服务容器是否正在运行、重启或已经退出；
4. 注册中心是否还保留着失效 …

一个本地 WMS 实例的 JDBC 配置明确指向测试数据库，但登录用户、权限和部分页面行为却像来自另一套环境。单看配置文件，很容易得出“应用偷偷连错数据库”的结论。

排查后发现，同一个 Web 应用同时依赖多种数据来源；这些来源指向不同环境，造成了看似数据库串线的现象：

• 业务数据通过 JDBC 访问数据库；
• 登录、用户和权限通过远程 UPM 服务取得；
• Dubbo 服务地址由注册中心或缓存决定；
• Redis 保存会话、权限或服务发现相关缓存；
• 本机还可能同时运行多个 Tomcat，每个实例加载不同的配置目录。

因此，业务列表来自测试库，并不代表权限也来自测试环境。

先确认真正处理请求的进程 …