proxy connection refused：本地代理端口拒绝连接怎么处理
PROXY-001
proxy connection refused严重程度 High一句话结论
应用尝试连接本地代理端口，但端口上没有服务应答。最可能是代理客户端没有运行、核心启动失败，或系统代理里写的端口和客户端实际监听的端口不一致；第一步是运行 doctor 看端口监听实况。
适用环境WindowsmacOSLinux
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28
结论
“connection refused”与"超时"有本质区别：拒绝是立即、明确的——目标主机收到了连接请求并回复"这个端口没有服务"。当拒绝发生在 127.0.0.1 上时，结论更加干脆：你自己的电脑在告诉你，预期的代理端口上什么都没有。这不是网络问题，不是节点问题，是一个本机进程与配置的匹配问题，排查范围小而明确。
适用环境
- Windows / macOS / Linux 桌面系统
- 浏览器、系统代理、开发工具等一切指向本地代理端口的场景
一分钟快速判断
connproof doctor看"常见本地代理端口"一项：
- 一个端口都没有监听 → 代理客户端根本没在工作：没启动、崩溃了，或核心进程启动失败；
- 有端口在监听，但不是报错里的那个 → 端口号不一致：系统或应用配置里写的是旧端口，客户端实际用的是另一个；
- 报错里的端口确实在监听 → 拒绝另有原因（防火墙拦截回环连接的罕见情形，或应用连接的不是 127.0.0.1 而是别的地址）。
这条错误代表什么
TCP 连接被拒绝意味着内核在目标端口上找不到监听套接字，立即回复 RST。发生在回环地址上时，只有三种可能：监听进程不存在、监听在不同端口、监听在不同地址（如只监听了 IPv6 的 ::1 而应用连的是 127.0.0.1，或反之）。第三种最隐蔽——doctor 的端口检查针对 127.0.0.1，若客户端只绑定了 ::1，两边就会"互相找不到"。
ConnProof 如何判断
doctor 的证据链：
- 常见本地代理端口：固定列表（1080、2080、7890、7891、8080、8118、9090、10808、10809）在
127.0.0.1上的实际监听状态； - 系统代理：当前系统代理指向的地址与端口；
- 两者交叉比对，直接暴露"指向 A 端口、监听在 B 端口"的错位。
如果你的客户端使用列表之外的自定义端口，用单端口检测验证：
connproof tcp 127.0.0.1 --port 你的端口拒绝（TCP-002 证据）= 无监听；成功 = 监听正常，问题在别处。
最常见原因
- 客户端没有运行：开机没自启、被手动退出、崩溃后没拉起；
- 核心进程启动失败：客户端界面开着，但它管理的核心（负责实际监听的进程）因配置错误或端口冲突没起来——界面看着正常，端口是空的；
- 端口配置漂移：客户端升级或改配置后换了监听端口，系统代理、浏览器扩展、命令行环境变量还指向旧端口；
- 端口被其他程序抢占：客户端启动时端口已被占用，监听失败（客户端日志里通常有 bind 失败记录）；
- 地址族错位：只监听
::1而应用连127.0.0.1（或反之）。
Windows 排查步骤
connproof doctor按上面三分法定位；- 无监听：启动/重启客户端，看它的日志窗口是否报"端口被占用"或配置解析错误；
- 端口错位：以客户端设置页显示的实际端口为准，更新系统代理（
设置 → 网络和 Internet → 代理）或应用配置； - 端口被占用：管理员命令行
netstat -ano | findstr :端口号找到占用进程的 PID，在任务管理器中确认它是什么——如果是残留的旧核心进程，结束它后重启客户端； - 复测
connproof tcp 127.0.0.1 --port <端口>确认监听恢复。
macOS 排查步骤
- doctor 三分法定位；
- 查占用：
lsof -nP -iTCP:端口号 -sTCP:LISTEN，看监听者是谁、绑定的是127.0.0.1还是*/::1； - 客户端有"重置核心/重启内核"按钮的优先用它，比整个退出重开更彻底；
- 若绑定地址是
::1，在客户端设置里把监听地址改为127.0.0.1或0.0.0.0（仅本机使用时前者更安全）。
浏览器扩展与 PAC 的隐藏指向
系统代理之外，还有两个容易被遗忘的"指向来源"会触发同样的报错：
- 浏览器代理扩展：SwitchyOmega 一类扩展保存着自己的代理配置，独立于系统设置。客户端换了端口后，系统代理修正了，扩展里的旧端口还在——于是只有装了扩展的那个浏览器"断网"。检查扩展的情景模式里写的端口，或临时切到"系统代理"模式验证；
- PAC 脚本：自动配置脚本内部硬编码了
PROXY 127.0.0.1:旧端口。脚本文件不会因为客户端改端口而自动更新，需要手动同步或改用客户端自带的 PAC 地址。
判断技巧：如果只有某一个应用报代理拒绝、其他应用正常，几乎可以肯定是那个应用自己的代理配置（扩展、PAC、应用内设置）指向了错误端口，而不是系统层面的问题。
如何区分本地问题和节点问题
这条错误发生在流量离开你电脑之前，与节点完全无关。它的近亲区分：
| 证据 | 结论 |
|---|---|
| 端口无监听 + 系统代理仍指向它 + 客户端已退出 | 转 PROXY-002 代理残留 |
| 端口无监听 + 客户端界面运行中 | 核心启动失败，看客户端日志（本页场景） |
| 端口有监听但连接后无法上网 | 转 CLIENT-001 |
仍未解决时收集什么信息
- ConnProof 错误码（PROXY-001）与 doctor 脱敏输出；
- 客户端名称和版本、操作系统版本；
- 客户端日志中与"bind / listen / 端口"相关的行（自行确认无敏感信息后再发）；
- 端口占用检查的结果。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof tcp 127.0.0.1 --port 你的代理端口修复后建连应立即成功（回环连接耗时通常在 1 ms 内）。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，收录端口三分法与地址族错位场景。