问题现象

上游服务报连接超时。虽然进程跑着、端口开着、日志空空如也，但客户端的 SYN 包发出去后服务端却收不到相应的 ACK。tcpdump 抓包发现，客户端发送的 SYN 被服务端收到并回复了 SYN‑ACK。但这条 SYN‑ACK 在离开网卡前就消失了。检查防火墙会话表，没有这条连接记录，说明包被静默丢弃。

排查过程

再看第一步先。确认服务端状态

先确认进程是否正常：

ss -tlnp | grep 

若日志中没有对应时间段内的关键字，说明服务端确实没收到请求。

随后在服务端启动 tcpdump 捕获握手过程：

tcpdump -i eth0 port  -c 100 -nn -w /tmp/handshake.pcap

抓包结果显示一个典型模式：

:: IP ..> ..: Flags ← SYN
:: IP ..> ..: Flags ← SYN+ACK
:: IP ..> ..: Flags ← SYN 重传
:: IP ..> ..: Flags ← SYN+ACK 重传
...

即：服务端收到了客户端的 SYN，并多次回应了 SYN+ACK；但第三次握手的 ACK 永远没有到来。怎么说呢，客户端不断重传 SYN。连接始终无法建立——典型的半开连接场景。

接下来的观点是，检查 TCP 连接状态

查看半连接队列：

$ ss -t state syn-recv
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 0 .:* .:* 

存在多个处于 SYN-RECV 状态。表示服务端已发出多次 SYN+ACK，却未收到 ACK。说起来，

进一步统计重传情况：

$ nstat -az | grep -E 'Retrans|Loss|Syn'
TcpExtTCPSynRetrans ...
TcpExtTCPFastRetrans ...
TcpExtTCPLostRetransmit...
...

用 ss -ti 查看每个半连接细节。 可看到大量未确认字节和重传段数。

：重传统计

通过 $ netstat -s | grep -E 'retrans|Retrans' 和 $ ethtool -S eth0 | grep drop。可发现:

• SYN+ACK 包在本机网络栈被丢弃，与重传次数完全吻合。

从第四步来看，用 Wireshark 风格查看三次握手全过程

• 正常三次握手：

1. SYN
2. SYN+ACK
3. Ack— 完成建立。

• 客户端视角：

1. SYN 发出
2. No ACK within 3s → 重发 SYN
3. No ACK within 6s → 重发 …

• 服务器视角：

1. SYN 接收后立即回应 SYN+ACK，但该包被标记为 “DROPPED by iptables”。此后服务器认为仍有半连接，继续回应。

第五步这方面，定位根因——iptables 规则错误配置

`iptables` 输出显示有一条错误规则:

$ iptables -L OUTPUT -n -v --line-numbers
Chain OUTPUT
...
DROP tcp -- * * ./ ./ tcp spt: tcpflags:SYN,ACK/SYN,ACK ... pkts=... bytes=...
...

This rule mistakenly drops outgoing packets that have both SYN and ACK flags set . It was intended to mitigate a SYN flood attack but was applied on OUTPUT chain with reversed match conditions.

第六步的观点是。修复与验证

Dangerous rule removed instantly:

$ iptables -D OUTPUT 

The `syn-recv` queue clears immediately.

$ ss -t state syn-recv # should be empty

Client reconnect attempts now succeed instantly:

$ ss -tn sport = : ESTAB ...

Access logs resume normal traffic:

2024/08/09 POST /api/callback HTTP/1.1 ...

A Wireshark-style replay confirms complete handshake:

SYN –✓ ––→ ––→ ––→ ✓

根因分析与痛点提炼

• Pain Point #1: You spent hours chasing empty logs because problem lay inside your own firewall rules.  Root Cause: An incorrectly written DROP rule on OUTPUT chain killed legitimate TCP replies.........
• Pain Point #2: The absence of connection‑stage monitoring left you blind until after service disruption.  Root Cause: No metrics on SYN‑RECV depth or retransmission rates were instrumented....
• Pain Point #3: Your security hardening script bypassed review and landed directly in production.  Root Cause: Lack of code review and inadequate test environment validation caused misconfiguration...
• Pain Point #4: The client’s generous connect timeout ) let threads hang unnecessarily.  Root Cause: Inappropriate timeout settings magnified resource exhaustion during failure periods...
• Pain Point #5: You had no dual-side packet capture strategy to pinpoint where packets vanished.. Root Cause:* Dual capture was absent—client saw only outbound SYNs while server saw outbound dropped packets.* .