核验日期：2026-09-19。已核对官方说明与发行资产；Windows 客户端 GUI 未实测。
先确认现象属于哪一层
适用于 Windows 上关闭 Clash 类客户端后，部分应用突然无法联网的情况。先问自己：客户端开启时是否正常？只有浏览器失败，还是局域网管理页也失败？Wi-Fi 是否仍连接？这些答案比“网络坏了”更能缩小范围。
在组织管理的电脑上，固定代理可能是工作网络的要求。这里只恢复确认由本次客户端使用引入的设置，不覆盖公司代理或不认识的 PAC 地址。
第一步：记录再关闭残留代理
打开 Windows 设置 → 网络和 Internet → 代理。记录“使用代理服务器”的开关、服务器地址和端口。若它仍指向本机 127.0.0.1，且对应客户端已经停止，这是一条值得验证的线索。
能打开客户端时，先重新启动它，再通过客户端关闭系统代理并正常退出。无法打开时，在 Windows 代理页关闭已确认属于该客户端的手动代理，然后重新打开浏览器测试。若设置稍后自动恢复，检查客户端是否仍在托盘、自启动或存在其他代理管理工具，不反复修改注册表。
第二步：只读检查本地监听
在 PowerShell 执行下列命令，把 7890 换成之前记录的实际端口。它不修改设置。
Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue
没有输出表示此刻没有发现该 TCP 监听；有输出只代表端口有人监听，尚不能证明它就是预期客户端。还需比较进程和客户端状态。不要因“端口有人占用”就随意结束不认识的进程。
本地证据：停止代理后会出现什么
2026-09-19，本站在 Windows x64 的隔离目录运行 Mihomo v1.19.31。核心启动时，显式 HTTP 代理请求返回 clash-lab-ok；停止同一核心后，对 127.0.0.1:18790 的请求返回 curl 退出码 7，错误为 Could not connect to server。这个对照实测了“请求仍指向停止端口”的结果；实验未修改 Windows 系统代理，也未模拟真实系统代理残留。
与之不同，核心仍运行但命中 REJECT 时，本次实验得到 HTTP 502 和 using REJECT 日志。因此端口失败与规则拒绝应该分开处理，不能都靠换节点解决。
第三步：若仍不通，停止扩大修改
| 当前结果 | 下一步 |
|---|---|
| 关闭残留代理后恢复 | 记录触发方式，更新客户端前保留版本信息 |
| 只有某个应用失败 | 检查该应用独立代理设置并完全退出重开 |
| 连路由器管理页也打不开 | 转查 Wi-Fi、网线、地址分配和网关 |
| 地址能访问而域名失败 | 收集 DNS 错误，核对已配置 DNS；不要凭此单点结果改全部网络 |
| 曾开启 TUN 或其他 VPN | 用对应软件正常停用并检查状态，不直接删除虚拟网卡 |
验收与来源
验收不是“图标消失”，而是客户端停止后基础网络正常、代理设置符合预期、重新启动和退出可重复。记录恢复前后状态与时间，有助于区分偶发掉线与代理残留。
Clash Verge Rev Windows FAQ说明了异常退出导致系统代理未关闭的场景。本站增加了只读端口检查、故障分层及本地对照实验；未进行真实设备网络重置或系统代理故障注入。