dial tcp i/o timeout：TCP 连接超时的逐层排查方法
TCP-001
dial tcp: i/o timeout严重程度 High一句话结论
TCP 连接请求发出后在限定时间内没有收到任何回应——既没有成功也没有拒绝。最可能是目标端口被防火墙静默丢弃；第一步是对同一主机的其他已知端口做对比检测。
适用环境WindowsmacOSLinuxAndroidiOS
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28
结论
超时的信息量藏在它"什么都没发生"这一点上。TCP 建连要么成功（收到 SYN-ACK），要么被拒绝（收到 RST），要么——像现在这样——发出去的 SYN 包彻底没有回音。没有回音意味着包在半路被丢弃，或者目标收到了但选择沉默。这和"连接被拒绝"是完全不同的两种故障，排查方向也不同：拒绝说明主机活着而端口没服务；超时说明你甚至无法证明主机存在。
适用环境
- 全部平台
- 任何 TCP 连接场景（这条报错的写法常见于 Go 编写的客户端，其他语言的等价表述是 connection timed out / ETIMEDOUT）
一分钟快速判断
- 换端口：
connproof tcp <主机> --port 443与--port 80各测一次。一个通一个超时 → 防火墙按端口过滤，主机本身在线； - 换网络：热点下复测。恢复 → 原网络出口对该目标有丢弃策略；
- 换目标：测一个你确定在线的常用域名。也超时 → 你的网络出口问题，与目标无关。
三个"换"各花二十秒，能覆盖八成以上的情形。
这条错误代表什么
SYN 包没有得到响应的三种解释：
- 静默丢弃（DROP）：防火墙收到包后直接扔掉、不回复。这是最常见原因——运营商、企业防火墙、云服务商安全组都偏爱这种方式，因为它让扫描者无法确认端口状态；
- 目标离线：主机关机或 IP 无人使用，包到达目标网段后无人认领；
- 链路中断：包在中途某一跳丢失，例如路由黑洞或严重拥塞。
注意与 connect ECONNREFUSED 的对照：拒绝是"活着但不服务"，超时是"生死未卜"。ConnProof 会在证据里明确标注是哪一种。
ConnProof 如何判断
connproof tcp 目标主机 --port 端口 --timeout 15000记录的证据：
- DNS 解析耗时（排除解析环节）；
- 等待的完整时长与设定超时的关系；
- 失败类型标注：超时（无响应）而非拒绝或重置。
放宽超时到 30 秒再测一次：偶尔成功说明是严重丢包而非彻底阻断——方向转向链路质量而不是防火墙策略。
最常见原因
- 目标端口被防火墙静默丢弃：包括目标侧安全组没放行该端口、运营商侧对特定端口的封锁；
- 目标服务器离线：续费到期、宕机、迁移后 DNS 还指向旧 IP；
- 本地出口对该目标或端口的策略：公司网络封锁非标准端口很常见；
- 路由问题：目标网段临时不可达，通常伴随同机房其他服务一起超时。
Windows / macOS / Linux 排查步骤
桌面端流程一致：
- 三个"换"（端口、网络、目标）确定问题落在哪一侧；
- 若指向目标侧：用
connproof dns <主机>确认解析出的 IP 是否还是服务方公布的地址——迁移后残留的旧解析会让你一直连一个空 IP； - 若指向本地出口：非标准端口（如 8443、2053 之外的自定义高位端口）被公司或校园网封锁时，与网络管理员确认或换用标准端口的服务入口；
- 云服务器自查（维护者场景）：控制台安全组 → 确认端口对公网放行；系统内
firewalld/ufw/Windows 防火墙逐层检查——安全组放行而系统防火墙没放行是新手部署最常见的组合失误。
手机端排查步骤
- Wi-Fi 与蜂窝各测一次是手机端唯一高效的对照手段；
- 蜂窝下通、Wi-Fi 下超时 → 路由器或宽带出口的策略/故障，重启路由器并检查其防火墙设置；
- 两边都超时 → 目标问题，用桌面设备跑 ConnProof 收集完整证据后反馈。
超时时长本身也是证据
很多人忽略了"等了多久才超时"这条信息，它其实能进一步缩小范围：
- 报错几乎立刻出现（一两秒内）：大概率不是真正的 TCP 超时，而是应用自己设置的极短超时，或者失败发生在更早的环节（如 DNS）被应用笼统地报成了超时。看 ConnProof 报告里的实际等待时长与失败层级，别被应用的报错文案带偏；
- 等满了系统默认时长（通常 20～75 秒不等，随平台而异）：标准的 SYN 重传耗尽，符合"包被静默丢弃"的画像；
- 时长不稳定、偶尔成功：丢包率高但未被完全阻断，方向转向链路质量——高峰期拥塞、无线信号弱、跨网互联质量差都属此类，此时提升超时参数或换时段重试比排查防火墙更有意义。
ConnProof 的 --timeout 参数就是为这组对照准备的：分别用 5 秒、15 秒、30 秒各测一次，三次全部干净超时与三次里成功一次，是两个完全不同的故事。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 仅特定端口超时、其他端口通 | 端口级防火墙（目标或运营商） |
| 换网络后恢复 | 本地出口策略 |
| 所有目标都超时 | 本地网络故障 |
| 解析出的 IP 与服务方公布不符 | DNS 陈旧/污染，先修 DNS |
| 放宽超时后偶尔成功 | 链路丢包，非阻断 |
仍未解决时收集什么信息
- ConnProof 错误码（TCP-001）与脱敏报告；
- 三个"换"的对照结果（这比报错本身有用得多）；
- 客户端名称和版本、操作系统版本；
- 问题开始时间与网络环境。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof tcp 目标主机 --port 端口 --format markdown --output tcp-report.md修复后建连应在数百毫秒内完成并显示耗时证据。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立"三个换"快速对照法。