本文目录
Clash 退出了，Windows 可能还在把请求送往旧端口
这类故障最典型的表现是：Clash 运行时网页正常，退出程序后浏览器立刻显示 ERR_PROXY_CONNECTION_FAILED，重新打开 Clash 又恢复。
问题通常不在宽带，而是代理设置仍指向 127.0.0.1 加旧端口。进程已经不监听，Windows 还在继续转发，自然会得到 connection refused。
先用手机连接同一个 Wi-Fi，或在电脑上 ping 路由器管理地址。如果其他设备能上网、电脑也能到达路由器，就不要先重置网卡。Windows 的用户代理、自动配置脚本、WinHTTP、环境变量和单个应用代理彼此独立，要找出留下设置的那一层。
错误现象通常指向哪里
| 现象 | 优先检查 | 常见提示 |
|---|---|---|
| Chrome、Edge 和系统应用一起断网 | Windows 手动代理或设置脚本 | ERR_PROXY_CONNECTION_FAILED |
| 浏览器正常，安装器或系统服务失败 | WinHTTP | 连接被拒绝、无法下载 |
| 终端里的 Git、npm 失败 | 环境变量和工具自己的代理 | Failed to connect to 127.0.0.1 |
| 只有一个浏览器异常 | 扩展、浏览器策略或安全 DNS | 其他应用仍可访问 |
| 只要开过 TUN，退出后全断 | 虚拟网卡、服务和路由 | 无明确代理错误 |
先在 Windows 的“代理”页面恢复直连
Windows 11 的检查位置
打开代理设置
进入“设置 → 网络和 Internet → 代理”，先看“使用代理服务器”是否仍为开。
关闭旧的手动地址
若地址是 127.0.0.1、端口与 Clash 的 mixed-port 一致，关闭“使用代理服务器”并保存。
检查设置脚本
如果“使用设置脚本”填有旧 PAC 地址，也一并关闭；“自动检测设置”可先保留。
彻底退出浏览器再测
关闭所有浏览器窗口，确认后台进程结束，再打开一个无痕窗口访问普通 HTTP 与 HTTPS 网站。
如果 Windows 页面看起来已经关闭，可按 Win + R 运行 inetcpl.cpl，在“连接 → 局域网设置”里再核对一次。某些旧程序仍通过这套 Internet 选项读取用户代理；不要只改地址而保留启用开关。
这一步恢复后，先保持 Clash 关闭。能直接打开路由器后台和常用网站，说明用户代理残留已经定位；此时没有必要继续执行 winsock reset 或删除网络适配器。
浏览器恢复了，系统下载仍失败时再看 WinHTTP
WinHTTP 主要被系统服务、安装器和部分企业程序使用，它不是 Windows“代理”页面的同一个开关。只有浏览器已经能直连，而 winget、某个安装器或服务仍试图连接旧代理时，才需要检查这里。
netsh winhttp show proxy
# 只有输出仍显示旧代理时才执行
netsh winhttp reset proxy终端单独没网，通常是变量或工具配置没有随 Clash 退出
很多开发教程会临时设置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也有人把代理写进 Git、npm 配置。它们不会因为 Clash 窗口关闭而自动消失。先在新开的 PowerShell 中查看当前进程和用户级变量，再检查出错工具自己的配置来源。
Get-ChildItem Env: | Where-Object Name -match '^(HTTP|HTTPS|ALL|NO)_PROXY$'
[Environment]::GetEnvironmentVariable('HTTP_PROXY', 'User')
[Environment]::GetEnvironmentVariable('HTTPS_PROXY', 'User')
git config --show-origin --get-regexp "http.*proxy"
npm config get proxy
npm config get https-proxyGit 报 Failed to connect to 127.0.0.1 port 7890
常见原因：Git 配置或环境变量仍指向旧端口
处理方法：根据 --show-origin 返回的文件删除对应 proxy 项，不盲删其他 Git 设置。
npm 失败但 curl 正常
常见原因：npm 用户配置里仍有 proxy/https-proxy
处理方法：确认来源后执行 npm config delete proxy 与 npm config delete https-proxy。
新终端正常，旧终端失败
常见原因：旧窗口继承了启动时的代理变量
处理方法：关闭旧终端并重新打开，不需要修改系统网络。
如果只有浏览器异常，把浏览器自己的变量拿掉
先开无痕窗口并停用所有代理扩展。扩展可能切换到自己的 PAC，也可能在系统代理关闭后继续接管请求。公司浏览器还可能由策略写入代理，在 chrome://policy 或 edge://policy 中能看到来源；有管理策略时不要通过改注册表强行覆盖。
ERR_NAME_NOT_RESOLVED 更像解析失败，而 ERR_PROXY_CONNECTION_FAILED 明确指向代理连接。前者可以暂时关闭浏览器“使用安全 DNS”做对照。能收到 403 或 404 已经说明网络请求到达服务端，不应继续清缓存或重置网卡。
没有代理错误、整机却断网，再检查 TUN 服务和默认路由
TUN 模式会创建虚拟适配器并改变路由，排查方法和系统代理不同。先重新打开 Clash，关闭 TUN 与服务模式，再从托盘菜单正常退出；随后用 route print 查看默认路由是否回到真实的 Wi-Fi 或以太网网关。不要一看到虚拟网卡就删除驱动，它可能同时被其他 VPN 使用。
Get-NetAdapter | Sort-Object Status, Name
route print- 默认路由仍指向失效虚拟接口
- 先正常停用对应 VPN/TUN 服务并重启电脑；记录接口名称后再决定是否卸载客户端组件。
- 真实网卡没有网关或 169.254 地址
- 这已经是 DHCP 或本地网络问题，重新连接 Wi-Fi 或续租地址，而不是继续改代理。
- 路由和地址都正常，只有 DNS 失败
- 检查网卡 DNS 与浏览器安全 DNS；整机网络重置应作为有备份后的最后手段。
以“Clash 关闭后仍可直连”作为修复结果
关闭 Clash 后逐项确认
- Windows“使用代理服务器”和旧 PAC 均为关闭
- netsh winhttp show proxy 在需要直连的电脑上显示 Direct access
- 新终端里没有指向旧端口的代理变量
- 浏览器、系统更新检查与至少一个终端工具都能访问
- 重启电脑后结果不反弹
重新启用 Clash 时一次只开一种接管方式：先系统代理，确认开启与退出都能正确恢复；确实有不读取系统代理的应用，再单独测试 TUN。不要同时让客户端、浏览器扩展和脚本修改系统代理，否则下次残留时很难判断是谁写入的。