连接建立失败的类型：超时、拒绝、重置、无响应等分类及特征

当客户端发起 TCP 连接或应用层握手请求后，如果未能进入预期的 ESTABLISHED 状态，我们通常将失败现象归纳为四种基本类型：超时（Timeout）、拒绝（Refused）、重置（Reset）和无响应（No Response）。这四种类型在故障表象、协议栈行为、根因方向上有显著差异，准确分类是后续调整超时参数和定位瓶颈的前提。

3.1 四种失败类型的核心特征

从 TCP 状态机与系统调用返回值两个维度观察，四种类型呈现出清晰的边界。下表汇总了它们的典型特征与常见诱因：

类型	客户端现象	协议栈行为	典型错误码	常见根因方向
超时	长时间卡在 SYN_SENT 或连接中	多次重传 SYN/SYN-ACK 后放弃	ETIMEDOUT (110)	路由黑洞、防火墙丢包、对端负载过高
拒绝	立即返回错误，端口不可达	对端回 RST，或 ICMP Port Unreachable	ECONNREFUSED (111)	端口未监听、服务未启动、iptables REJECT
重置	连接建立后立刻被断开，或握手过程中收到 RST	对端主动发送 RST 报文	ECONNRESET (104)	应用崩溃、 backlog 溢出、安全策略拦截
无响应	请求发出后无任何 ACK/RST，直至超时	报文被静默丢弃，无任何反馈	ETIMEDOUT 或应用层超时	网络设备丢包、对端内核挂起、NAT 表项失效

3.2 超时（Timeout）——最隐蔽的失败模式

超时是四种类型中排查成本最高的一种。它的本质是：客户端发送 SYN 后，在预定的重传时间内没有收到 SYN-ACK，且没有收到 RST。TCP 协议栈会按照指数退避算法重传 SYN（通常间隔 1s、2s、4s、8s…），直到达到 tcp_syn_retries 上限（Linux 默认 6 次，约 127 秒）才返回 ETIMEDOUT。

超时场景下，抓包往往看不到任何对端回包，或者只看到客户端单方向的重传。常见原因包括：

• 中间设备静默丢包：例如云安全组未放行端口、防火墙策略丢弃而非拒绝。
• 路由黑洞：下一跳设备没有有效路由，直接丢弃报文。
• 对端 SYN 队列（backlog）溢出：服务器内核丢弃 SYN，而非回 RST。
• 服务器负载过高：内核无法及时响应握手请求。

# 查看当前 SYN 重传次数上限（Linux）
sysctl net.ipv4.tcp_syn_retries
# 典型输出：6

# 抓包观察超时行为（仅看 SYN 与重传）
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0' -nn

3.3 拒绝（Refused）——端口未监听或策略明确拒绝

拒绝类型的特征是快速失败。当客户端 SYN 到达目标主机，但目标端口没有进程监听时，内核会立即返回 RST 报文。客户端收到 RST 后，connect() 系统调用立刻返回 ECONNREFUSED，整个过程通常在毫秒级完成，不会产生重传。

另一种拒绝形式是 ICMP Port Unreachable，常见于 UDP 连接或某些防火墙配置。拒绝类型的根因通常比较直接：

• 服务进程未启动或崩溃后未自动拉起。
• 监听地址与客户端访问地址不匹配（例如只监听了 127.0.0.1）。
• iptables 使用了 REJECT 策略（而非 DROP）。

3.4 重置（Reset）——连接建立后或握手过程中被强制断开

重置与前两种类型的关键差异在于：对端是活跃的，且明确发送了 RST 报文。RST 可能出现在两个阶段：

1. 握手阶段收到 RST：客户端发送 SYN 后收到 RST，而非 SYN-ACK。这通常意味着目标端口曾经有服务，但当前已关闭，或者防火墙主动发送 RST 进行干扰。
2. 连接刚建立就收到 RST：三次握手完成，但应用层立即关闭或崩溃，导致内核发送 RST。

重置类型的常见诱因包括：

• 服务器 accept 队列（backlog）溢出后，内核发送 RST 拒绝新连接。
• 应用进程在完成握手后、读取数据前崩溃。
• 中间安全设备（如 IDS/IPS）检测到异常特征后发送 RST 切断连接。
• TCP 时间戳或序列号异常导致对端认为报文非法。

# 查看 accept 队列溢出统计
netstat -s | grep -i "listen"
# 输出示例：
#    1234 times the listen queue of a socket overflowed

3.5 无响应（No Response）——静默丢弃的排查难点

无响应与超时在表象上高度相似，但侧重点不同。无响应强调整个路径上没有任何设备给出反馈——没有 RST、没有 ICMP 错误、没有应用层响应。客户端只能依靠自己的超时机制判断失败。常见于以下场景：

• 云环境安全组规则未生效，报文在虚拟交换机层面被丢弃。
• 对端服务器内核 Panic 或网络栈挂起，无法回任何报文。
• NAT 网关的映射表项老化，导致回程报文无法送达。
• 客户端发出的 SYN 本身被本机防火墙（如 iptables OUTPUT 链）拦截。

3.6 案例复盘：一次典型的“超时 vs 无响应”误判

某业务反馈连接数据库偶发失败，客户端日志显示 Connection timed out。初步判断为网络超时，于是将 tcp_syn_retries 从 6 调大到 8，但问题依旧。

随后在客户端抓包发现：SYN 报文持续重传，但服务端抓包却完全看不到任何 SYN 到达。进一步检查发现，云平台安全组误将数据库端口的源地址限制为旧网段，导致新扩容的客户端 IP 被静默丢弃。这实际上属于无响应类型（安全组丢弃），而非真正的网络超时。修正安全组规则后，问题立即消失。

复盘结论：仅凭客户端日志中的 “timed out” 无法区分超时与无响应，必须结合两端抓包才能定位丢包位置。

3.7 分类诊断流程

面对连接建立失败，建议按以下路径快速归类：

1. 观察客户端报错速度：立即返回（毫秒级）→ 优先怀疑拒绝或重置；延迟返回（秒级）→ 优先怀疑超时或无响应。
2. 在客户端抓包：是否收到 RST？收到 → 拒绝或重置；未收到 → 超时或无响应。
3. 在对端抓包：SYN 是否到达？到达但无响应 → 对端内核或应用问题；未到达 → 中间链路丢包。
4. 检查中间设备（防火墙、安全组、NAT）的丢弃日志。

3.8 常见误区与复盘要点