ConnProof

proxy port is not listening：代理端口没有进程监听 ​

PROXY-003proxy port is not listening严重程度 High
一句话结论

预期的代理端口上没有任何进程在监听，所有依赖它的应用都会连接失败。最可能是代理客户端的核心进程启动失败——界面开着不等于核心活着；第一步是查看客户端日志里有没有端口绑定失败或配置解析错误的记录。

适用环境WindowsmacOSLinux
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28

结论 ​

这条错误与 proxy connection refused 描述的是同一个物理事实（端口上没人听）的不同视角：那边站在"连接者被拒绝"的角度，这边站在"监听者缺席"的角度——它是 doctor 检测直接给出的诊断，而不是某次连接的报错。核心疑点只有一个：那个本该监听端口的进程为什么没在监听？ 答案几乎总在客户端的日志里。

适用环境 ​

  • Windows / macOS / Linux 桌面系统
  • 现代代理客户端普遍采用的"界面 + 核心"双进程架构

一分钟快速判断 ​

  1. 看客户端日志：找 bind、listen、address already in use、配置解析错误等关键词。九成的答案在这里；
  2. 确认核心状态：客户端界面上通常有核心运行指示（版本号显示、开关状态）。界面正常但核心指示异常/空白 → 核心没起来；
  3. 重启核心：用客户端的"重启核心/重载配置"功能（比重启整个程序更有针对性），观察日志里的启动序列走到哪一步失败。

这条错误代表什么 ​

“界面 + 核心"架构下，你看到的窗口只是遥控器，真正监听端口、转发流量的是它管理的核心进程。两者的生死是独立的：核心可以在界面完全正常的情况下启动失败或中途退出，症状就是"客户端明明开着，端口却是空的”。核心起不来的常见剧本：

  • 配置解析失败：订阅更新引入了核心不认识的字段、手工编辑配置留下语法错误——核心在启动的第一步就退出；
  • 端口被占用：上一次异常退出的旧核心进程还赖在端口上，新核心绑定失败；
  • 权限不足：TUN 模式或低位端口需要管理员/root 权限，没给够就起不来；
  • 被安全软件拦截：核心二进制被误杀或其监听行为被阻止。

ConnProof 如何判断 ​

connproof doctor

doctor 列出固定清单内常见代理端口在 127.0.0.1 上的实际监听状态。自定义端口用单点检测补充：

connproof tcp 127.0.0.1 --port 你的端口

“拒绝"即无监听。再交叉一条证据：系统代理若指向这个空端口，全系统断网的症状同时成立（参见 PROXY-002——两者常常联袂出场：核心启动失败 + 系统代理已被接管 = 残留式断网）。

最常见原因 ​

  1. 配置错误导致核心启动即退：订阅内容变化后最高发；
  2. 旧进程占用端口：崩溃后未清理；
  3. 权限不足：升级系统或客户端后权限授权失效；
  4. 安全软件误杀核心：更新客户端版本后新二进制未被信任；
  5. 绑定地址错位：核心只绑了 ::1 或特定接口，127.0.0.1 侧看是空的。

Windows 排查步骤 ​

  1. 客户端日志定位启动失败原因；
  2. 配置类：回滚到上一个可用配置（多数客户端有配置历史/备份），或重新更新订阅覆盖；
  3. 占用类：netstat -ano | findstr :端口 找到 PID，任务管理器确认是旧核心则结束它；
  4. 误杀类：查看安全软件的隔离区，恢复核心文件并加入信任列表；
  5. 权限类：以管理员身份运行一次，确认是否权限所致，再决定长期方案。

macOS / Linux 排查步骤 ​

  1. 日志优先；
  2. 占用：lsof -nP -iTCP:端口 -sTCP:LISTEN 看谁在听、绑定哪个地址；
  3. macOS 首次启用 TUN/系统扩展需要在"隐私与安全性"里手动允许，升级系统后可能要重新允许；
  4. Linux 低位端口或 TUN 需要 capability 或 root，核对服务的运行用户与权限配置。

如何区分本地问题和节点问题 ​

端口监听发生在任何流量出门之前，与节点无关。内部三分：

证据结论
日志显示配置解析失败配置问题（回滚/重新订阅）
日志显示 bind 失败端口占用或权限
核心文件消失/被隔离安全软件误杀
核心正常监听在其他地址绑定地址错位（改监听地址）

订阅更新为什么会弄死核心 ​

“昨天还好好的，更新了下订阅就起不来了"——这个高频剧情值得专门解释。订阅不只是节点列表：很多订阅同时下发分组结构、规则集甚至 DNS 配置。服务方在订阅里引入了新协议类型或新字段，而你的核心版本较旧不认识它们时，配置校验直接失败，核心拒绝启动。于是"更新订阅"成了压垮核心的最后一根稻草。对策分两步：应急时回滚到客户端保存的上一份配置（或暂时用旧订阅缓存）恢复可用；根治则是把客户端与核心升级到支持新字段的版本再更新订阅。反过来的版本错配也存在——客户端太新而订阅格式太老——症状相同，处理思路一致：让"配置的方言"和"核心的听力"匹配。

仍未解决时收集什么信息 ​

  • ConnProof 错误码（PROXY-003）与 doctor 脱敏输出；
  • 客户端日志中启动失败的关键行（自查无敏感信息后提供）；
  • 客户端名称和版本、核心类型与版本、操作系统版本；
  • 最近一次正常工作的时间与其后做过的变更（更新订阅/升级/改配置）。

禁止提交：完整订阅链接、密码、验证码、私钥、Token、完整配置文件。

重新运行检测 ​

connproof tcp 127.0.0.1 --port 你的端口

修复后回环建连应立即成功。

相关文档 ​

更新记录 ​

  • 2026-07-28：规则 v1 发布，梳理"界面-核心"架构下的启动失败剧本。