ConnProof

connection closed immediately after accept：接受后立即关闭的连接 ​

TCP-005connection closed immediately after accept严重程度 Medium
一句话结论

连接被对端接受之后立即以正常流程（FIN）关闭，握手成功但通道无法使用。最可能是负载均衡器接受了连接却没有健康的后端可转发，或服务正在启动尚未就绪；第一步是间隔几分钟重试，判断是否为暂时现象。

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

结论 ​

这条错误描述的是 TCP 层一个容易被忽略的状态：握手完全成功，然后对端立刻挥手告别。

它与两个近亲的区别值得先摆清楚，因为三者的成因完全不同：

现象底层事件含义
拒绝RST 回应 SYN端口上没有服务在监听（TCP-002）
重置连接后收到 RST被强制切断，可能是中间设备干预（TCP-003）
接受后关闭连接后收到 FIN有东西在监听，但它不打算跟你说话（本页）

第三种最有信息量：有服务、能握手、但拒绝提供服务。这几乎总是服务端一侧的状态问题，而不是网络问题。

适用环境 ​

  • 全部平台
  • 高发场景：经过负载均衡器的服务、正在发布或重启的服务

一分钟快速判断 ​

connproof tcp 目标主机 --port 端口 --hold 3000

--hold 让检测在建连成功后继续观察几秒，这是捕获这类现象的必要条件——不加它，检测在握手成功的瞬间就结束了，看到的只会是"连接成功"。

报告中的关键证据：

连接提前终止：建连后 XX ms 被对端正常关闭（FIN）

看到 FIN 而不是 RST，就落在本页。再看时间间隔：几毫秒内关闭通常是自动化行为（负载均衡、连接数限制），几百毫秒以上则可能是服务端做了某种检查后才决定关闭。

这条错误代表什么 ​

TCP 的握手和应用层的服务能力是两件事。内核在应用程序调用 accept() 之前就完成了三次握手——只要有进程在监听，握手就会成功，哪怕那个进程完全没有能力服务你。

这个机制解释了三种典型场景：

一、负载均衡器没有健康后端。 负载均衡器自己在端口上监听，握手由它完成；随后它去找后端转发，发现一个健康实例都没有，于是只能关闭连接。从你的角度看，服务"活着但没用"。

二、服务正在启动或重载。 端口已经绑定，业务逻辑还没初始化完。这类情况通常几十秒到几分钟内自愈——这也是为什么"间隔几分钟重试"排在建议的第一位。

三、连接数达到上限。 服务端接受连接、发现超过配额、立即释放。特征是在高峰期出现、低谷期正常。

还有一种较少见但存在的情况：服务端有来源校验（IP 白名单一类），对不符合条件的连接直接关闭而不给任何提示。这种情况下换网络出口会有不同结果。

ConnProof 如何判断 ​

检测器在握手成功后不立即结束，而是保持 socket 观察 --hold 指定的时长，期间不发送任何数据。这个"沉默观察"很关键：它区分了"对端主动关闭"与"因为我们说了什么才关闭"。

观察期内的三种结局各自对应不同的判定：

  • 收到 FIN → 本页（TCP-005），状态 warning；
  • 收到 RST → TCP-003，状态 warning；
  • 什么都没发生，保持到观察期结束 → pass。

状态定为 warning 而不是 fail，是因为TCP 层本身确实成功了——分层诊断的原则是如实汇报每一层的结果，而不是把上层的不可用倒推成下层的失败。但错误码会挂上，方便你查文档。

最常见原因 ​

  1. 负载均衡器无健康后端：最典型，且通常伴随服务方的故障公告；
  2. 服务启动/重载窗口期：短暂，可自愈；
  3. 连接数上限：有时段规律；
  4. 来源校验不通过：换出口后表现不同。

排查步骤（全平台一致） ​

  1. 间隔重试：等待三到五分钟再测一次。恢复 → 是启动窗口或临时故障，无需进一步处理；
  2. 换出口对比：换网络或换节点重试。仅特定出口被关闭 → 来源校验；
  3. 换端口对比：如果目标主机有其他已知开放端口，测一下。其他端口正常而目标端口接受后即关 → 那个端口背后的服务有问题，主机本身健康；
  4. 看时段规律：连续几天在不同时段各测一次。仅高峰期出现 → 容量或连接数限制；
  5. 反馈：把"接受后立即关闭（FIN）"这个准确描述交给服务方。这与"连不上"是不同的故障——他们会去查负载均衡的后端健康状态，而不是去查防火墙。

服务维护者侧 ​

从"谁发的 FIN"入手：如果是负载均衡器，查后端健康检查为什么全部失败；如果是应用本身，查是否在 accept 之后有提前 return 的分支（连接数、来源校验、资源不足）。日志里通常能看到"接受连接后立即关闭"的记录，只是容易被淹没在正常日志里。

如何区分本地问题和服务端问题 ​

证据结论
收到 FIN 而非 RST服务端主动关闭（本页）
几分钟后自行恢复启动窗口或临时故障
换出口后正常来源校验或该出口被限制
同主机其他端口正常目标端口的服务问题
仅高峰期出现连接数或容量限制
多用户同时遇到服务端故障，等待修复

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

  • ConnProof 错误码（TCP-005）与脱敏报告；
  • 关闭方式（FIN）与建连到关闭的间隔毫秒数；
  • 间隔重试与换出口的对照结果；
  • 出现的时段规律与检测时间。

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

重新运行检测 ​

connproof tcp 目标主机 --port 端口 --hold 3000 --format markdown --output tcp-report.md

修复后连接应保持到观察期结束，报告中不再出现"连接提前终止"证据。

相关文档 ​

更新记录 ​

  • 2026-07-29：规则 v1 发布。此前检测已能观察到建连后的 FIN，但没有对应的错误码，只报 warning；本次补上编号与文档。