TCP连接实战：原理、报错排查与调优

就说 TCP 这朵云：三次握手、踩坑与调优，一次讲明白

做后端和网络的这些年，我数不清处理过多少和 TCP 相关的疑难杂症。上个月帮朋友排查一个本地服务启动失败的问题，终端里明晃晃地挂着 error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address——一看就是端口被占，但很多新手会愣住：什么是 bind？什么是 socket address？为什么"只能使用一次"？类似的还有 connection reset by peer、connect timeout、Navicat 连 MySQL 失败、ESP8266 连不上 OneNET、远程桌面分辨率异常……这些问题表面五花八门，底层全绕不开 TCP 连接的建立、维持和断开。

这篇文章我从实战角度出发，把 TCP 连接的原理、故障排查、实操抓包、常见场景调优一次性讲透。不管你是刚学 Socket 编程的学生，还是被线上连接问题折磨的运维，或者玩嵌入式、工业控制的朋友，看完都能直接拿去用。

1. 先搞清楚：TCP 连接建立时做过什么

很多人背过"三次握手、四次挥手"，但问一句"为什么"就卡住了。我先把这个基础夯实，后面排查问题才有方向。

1.1 三次握手：不只是"确认存在"

TCP 是面向连接的、可靠的传输协议。所谓"连接"，本质上是通信双方各自维护一组状态，而不是真的有一条物理线路。三次握手做的最核心的一件事，是让双方确认两件事：我发的你能收到，你发的我也能收到。也就是确认各自的发送和接收能力都正常。

具体流程大家都熟：客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK。网上很多文章把它类比成"打电话互相确认"，但这个类比其实不到位。我更喜欢用同事协作的说法：

• 客户端说"你好，我这边准备好了"（SYN）
• 服务端收到后心里有数了——客户端能发，我能收。于是回复"好的，我也准备好了，你确认一下"（SYN+ACK）
• 客户端回"收到"（ACK）——这时服务端也知道客户端能收，自己也能发，才敢开始传数据

为什么不能只握手两次？因为如果只有两次，服务端无法确认客户端的接收能力是否正常。比如客户端发的 SYN 因为网络重传走了一条慢链路，服务端回了 SYN+ACK 之后就认为连接建立好了，但客户端可能压根没收到，更别说回最后一次 ACK 了。与其等超时重传白白浪费资源，不如用第三次 ACK 当作最终确认信号。

注意：三次握手建立连接只解决了"可达性"问题，不代表应用层就一定能正常通信。比如服务器进程本身崩了，但内核还在响应 TCP 握手，这时 TCP connect succeed 但应用层请求照样失败。排查时别只盯着握手看。

1.2 四次挥手：断开比建立更讲究

断开连接需要四次挥手，因为 TCP 是全双工的，每个方向的传输通道必须单独关闭。想象一条双向双车道：不是双向各出一辆车打个招呼就完事，而是每条车道都得独立完成"我要关了，你确定没有车还在路上吗"的确认。

流程是：

1. 主动方发 FIN，告诉对方"我这边数据发完了"
2. 被动方回 ACK，表示"收到你的关闭请求"，但被动方可能还有数据要发，所以只是确认，不立即关闭
3. 被动方数据发完后，也发 FIN 告诉主动方"我也发完了"
4. 主动方回 ACK，双方才真正释放连接

这里最容易出问题的是两个状态：CLOSE_WAIT 和 TIME_WAIT。CLOSE_WAIT 出现在被动方，表示"对方要关了，我也得赶紧关"；如果程序代码里没正确关闭 Socket，被动方会一直卡在这个状态，连接逐渐堆积，最后导致"文件描述符不够用"或"端口全部占满"。

1.3 连接状态机：CLOSE_WAIT、TIME_WAIT 是怎么来的

排查 TCP 问题时，netstat 或 ss 打出来一堆状态，新手最容易看晕。我把高频出现的状态整理一下：

TIME_WAIT 是排查高频对象。主动关闭的一方发出最后的 ACK 后，会进入长达 2MSL（Maximum Segment Lifetime，报文最大生存时间）的等待期。之所以要等这么久，是因为怕最后一个 ACK 在网络上丢了，对方会重发 FIN，你如果已经关掉连接就收不到了。这是 TCP 可靠性设计的一部分，绝不能粗暴去掉，虽然可以用 SO_REUSEADDR 缓解端口占用问题，但那是另一码事。

2. TCP 还是 UDP？先别急着选

热搜词里"TCP和UDP的区别"排得很靠前，我看很多帖子解释得都太死板。说句实在话，很多场景下选哪个协议不是看性能，而是看你的信任模型和资源承受能力。

2.1 两者的核心差异：有连接 vs 无连接

TCP 有连接、可靠、有序、面向字节流；UDP 无连接、不可靠、无序、面向报文。这个基础定义很多人都会背，但实际使用中的差异才是关键。

TCP 的可靠是通过确认重传、序号、校验和、流量控制、拥塞控制一整套机制换来的。代价是头大、有延迟、有连接建立开销，结构也比 UDP 复杂。UDP 则是一把梭，发出去就不管了，头只有 8 字节，没有连接建立成本，也没有重传延迟，适合能忍受丢包的场景。

我见过一个经典选错案例：有人用 TCP 去传视频流，因为网络抖动导致 TCP 重传风暴，画面卡得不能看；后来换成 UDP，配合应用层只处理最新帧，体验立刻上来了。

2.2 选型建议：什么场景用什么协议

另外一个近期常见词是 tcp和ws区别。很多人问 WebSocket 和 TCP 什么关系。简单说，WebSocket 是基于 TCP 的应用层协议，它复用了 TCP 的可靠传输能力，但通过一次 HTTP 升级握手，建立一条全双工的长连接。所以 WebSocket 是 TCP 的"上层住户"，不是平级替代。

实操心得：如果你用 UDP 做关键业务，一定要在应用层做序列号和超时重传，否则数据丢了连日志都对不上。千万别以为"用了 UDP 就能省心"。

3. 高频报错与排查思路（实测整理）

这一节我整理了生产环境和日常开发里最常踩的 TCP 连接坑，按报错信息为线索，逐个拆解。

3.1 bind: only one usage of each socket address——端口被占用

这个报错的完整格式一般是：

bash复制error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address
或者
error: listen tcp 0.0.0.0:11434: bind: only one usage of each socket address

含义是：你尝试监听的 IP:端口 已经被另一个 socket 占用了。一个端口同一时刻只能被一个 socket 监听，这是操作系统的基本规则，不能违反。

排查顺序固定为：

bash复制# 1. 看哪个进程在监听该端口
ss -lntp | grep 11434
# 或
lsof -i :11434

# 2. 如果没有输出，再查确认连接
ss -tunap | grep 11434

# 3. 找出来之后看进程信息，确认是否残留
ps -ef | grep 11434

常见原因有两类。第一类是服务启动脚本重复执行，比如用 systemd 启动了两次服务、多个 docker 容器映射了同一个宿主机端口。第二类是服务异常退出但 socket 没有完全释放，尤其是 TIME_WAIT 大量堆积时。

关于第二类，有同学会问：TIME_WAIT 状态也会占用端口吗？答案是：会占用本地端口号，但通过 SO_REUSEADDR 可以让新的监听 socket 复用地址。很多服务框架默认开了这个选项，所以不存在"TIME_WAIT 导致 bind 失败"；但如果你的裸代码没设置，就可能踩到。

注意：SO_REUSEADDR 是允许新 socket 绑定 TIME_WAIT 状态的地址，不代表它能绑定一个活着的有监听 socket 的地址。后者无论如何都不行，这是两种完全不同的情况。

3.2 connect timeout——连接超时

connect timeout 是排查成本最高的一种，因为导致它的链路环节很多。我一般按下面几步走：

1. 先判断目标 IP 是否可达：ping 目标IP，能通说明基本网络层OK，不通则查路由、防火墙、物理链路。
2. 用 telnet/nc 探测特定端口：telnet 192.168.1.10 3306 或者 nc -vz 192.168.1.10 3306。如果超时，说明端口被防火墙挡了，或者服务没在监听。
3. 从客户端抓包确认 SYN 是否发出、有没有回应：tcpdump -i eth0 host 192.168.1.10 and tcp port 3306。
4. 区分是 SYN 发出去了没回应，还是连接建立后应用层卡住：前者是网络层/防火墙问题，后者可能是数据库连接池耗尽、服务端线程阻塞等。

如果是跨机房或跨云环境的连接超时，还要考虑安全组规则和中间防火墙设备。这类问题只能用排除法：换端口、换IP、换网段、关掉部分防火墙逐级测试。

3.3 TCP Connection Reset by Peer——对端重置连接

curl: (35) tcp connection reset by peer 这句话我看过无数次。含义是：连接建立过程中或建立后，对端直接发了个 RST 包来强制关闭连接。RST 是 TCP 的"急刹车"，不打招呼，不握手，直接拒绝。

常见原因：

• 服务端监听的端口确实有进程，但进程已经崩了或 socket 已经关闭，内核收到新的握手请求后回 RST。
• 服务端不接受该客户端来源（如防火墙策略），主动回了 RST。
• 客户端发送的数据触发了服务端应用层主动 close，随后又收到数据。
• 后端连接池recv超时，把连接关了，客户端还继续写数据。
• 中间设备（如NAT/负载均衡）检测到空闲超时，强制杀了连接。

排查时第一步看时间点：是"连接刚建就被 RST"，还是"运行一段时间后被 RST"。前者主要查服务端监听状态和防火墙；后者优先查空闲超时配置、数据库连接池保活机制、以及反向代理的 keepalive 配置。

3.4 connection refused——拒绝连接

这个报错常见于本地，比如 127.0.0.1 已拒绝连接。和 timeout 不同，refused 意味着目标端口没人监听，所以服务端直接回了 RST，客户端立刻就知道连不上。排查思路：

• 服务有没有启动？ss -lntp | grep 端口
• 服务是不是监听在别的IP上？比如只监听了 127.0.0.1，外部 IP 访问就会 refused。
• 防火墙有没有挡？但要注意：防火墙通常表现为 timeout（丢弃包），而不是 refused（因为没人监听才拒绝）。如果出现 refused，一般说明已经把包递到了目标机器上，只是端口层没进程接。

实操心得：Docker 场景下最容易碰到"端口映射了但从外部连不上"。多半是 Docker 进程挂了、容器重启后端口没映射成功、或者宿主机的 firewalld/iptables 在 DOCKER-USER 链里做了限制。先用 docker ps 确认容器状态，再 ss -lntp | grep 端口 确认宿主机是否有监听，最后看防火墙链，三步排查。

4. 实操心法：查看连接状态、定位故障源头

排查 TCP 问题，命令是基本功。别每次都靠搜索引擎现查，我把自己最常用的三板斧写下来。

4.1 用 ss 和 netstat 快速看连接

netstat 是经典工具，但新系统更推荐 ss，因为 ss 直接从内核读取 socket 信息，速度更快，输出也更全。基本用法：

bash复制# 列出所有 TCP 连接，显示进程信息
ss -tunap

# 只看监听端口
ss -lntp

# 统计各种 TCP 状态数量
ss -s

# 按状态过滤，比如只看 TIME_WAIT
ss -tan state time-wait

实操中我看连接数异常飙升的流程是：

bash复制# 1. 先看整体状态统计，确认哪种状态异常多
ss -s

# 2. 按端口过滤，找出具体连接
ss -tan | grep :3306 | wc -l

# 3. 按状态统计端口
ss -tan | grep :3306 | awk '{print $1}' | sort | uniq -c | sort -rn

这三步下来，基本能判断是连接池没释放（CLOSE_WAIT 多）、还是短连接频繁创建导致 TIME_WAIT 多，或者是恶意扫描导致 SYN_RECV 多。

4.2 用 tcpdump 抓包看握手/断连

如果 ss 只能看到状态，那抓包就是看到证据。比如要确认一个连接是被对端 RST 的，还是自己超时断开的，抓包一目了然。

最常用的抓包姿势：

bash复制# 抓指定端口并只看 TCP
tcpdump -i eth0 tcp port 11434 -n -vv

# 抓指定主机之间的流量
tcpdump -i eth0 host 192.168.1.100 and tcp port 3306 -w /tmp/tcp.cap

# 只看 SYN 和 RST 包
tcpdump -i eth0 tcp port 11434 and '(tcp[tcpflags] & (tcp-syn|tcp-rst) != 0)' -n

抓到包之后，用 Wireshark 打开或者直接看文本输出。关键信息是包的 flags 和 sequence number：

• S 表示 SYN
• . 表示 ACK
• P 表示 PUSH（携带数据）
• F 表示 FIN
• R 表示 RST

如果看到客户端反复发 SYN 但服务端一直不回 SYN+ACK，那就是包被防火墙丢或者服务端没监听。如果看到 R 包，注意是谁发的、什么时候发的，这比任何猜测都靠谱。

4.3 常见连接状态速查表

为了方便贴到笔记里，我做了一张速查表，覆盖日常运维最高的几种情况：

5. 几个真实场景里的 TCP 调试记录

把 热搜词里高频的场景单独拿出来讲，每一个都有明确的操作路径。

5.1 本地服务启动失败：端口被占用的完整处理

热搜里出现两次的报错 error: listen tcp 127.0.0.1:11434 和 error: listen tcp 0.0.0.0:11434，本质上是同一个问题：监听地址被占用。区别只在 IP 地址是回环还是所有网卡。

处理流程：

bash复制# 1. 确认谁占用了端口
ss -lntp | grep 11434

# 2. 看进程详情
ps aux | grep <PID>

# 3. 如果确认是残留进程，kill
kill -9 <PID>

# 4. 如果占用的是 TIME_WAIT 状态的连接
ss -tan | grep 11434
# 可以等待 MSL 过期，也可以开启 SO_REUSEADDR，或者改内核参数
sudo sysctl -w net.ipv4.tcp_tw_reuse=1

这里多说一句 tcp_tw_reuse。它其实只对主动发起连接的一方生效，也就是说，如果是一个客户端要去连服务端，本地端口不够用了，这个参数能帮忙；如果是服务端程序要 bind 一个已在 TIME_WAIT 的监听地址，那 tcp_tw_reuse 帮不上忙，得靠 SO_REUSEADDR。

很多同学搞混这两个机制，所以我专门强调一遍。

5.2 数据库远程连不上：Navicat、MySQL 连接问题

热搜里有 navicat连接mysql，这个问题十个有八个是以下三个原因：

1. MySQL 没开远程访问授权。默认 root 只允许 localhost 登录，需要单独创建远程用户并授权：

sql复制CREATE USER 'dev'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%';
FLUSH PRIVILEGES;

2. bind-address 限制。MySQL 的 my.cnf 里如果写了 bind-address = 127.0.0.1，外部连不上。改成 0.0.0.0 并重启服务。

3. 防火墙/安全组拦截。云服务器记得放行 3306 端口，本地测试先关防火墙看是否恢复。

排查时我习惯先用 telnet 服务器IP 3306 测端口通不通。如果通，说明 TCP 层没有问题，问题在 MySQL 应用层；如果不通，才继续看防火墙和 bind-address。

5.3 嵌入式/工业场景：Modbus TCP、ESP8266

热搜里有 modbus tcp 和 esp8266连接onenet失败，这两个场景的共同点是设备资源有限、网络环境不如服务器稳定。

Modbus TCP 基于 TCP 之上的应用协议，默认端口 502。它的特点是报文结构紧凑，但底层依然是可靠的 TCP。调试 Modbus TCP 时最容易踩的坑是大部分 PLC 只允许少量并发连接，比如西门子很多设备默认只允许 1-2 个 TCP 连接。你调试工具开一个连接、上位机再开一个，第三个连接直接被拒。这时候排查思路不是"PLC 是不是坏了"，而是先检查现有连接数。

ESP8266 连 OneNET 失败，我遇到过板上没有设置正确的 AT+CIPSTART 模式，或者模块固件版本太老不支持 TCP 长连接。建议先通过串口调试工具做单步验证：

bash复制AT+CWMODE=1
AT+CWJAP="ssid","password"
AT+CIPSTART="TCP","183.230.40.40",80

如果 AT+CIPSTART 返回 ERROR，优先确认网络模块是否获取到 IP、目标服务器是否真的开放了对应端口。另外不少物联网平台只支持 TLS 加密连接，普通 AT 固件不带 SSL 功能，自然连不上。这属于应用层协议兼容问题，不是 TCP 本身的问题。

5.4 远程桌面/SSH 连接中的 TCP 因素

热搜里 vscode连接ssh远程服务器、远程桌面连接、关闭显示器后远程连接分辨率降低，这些表面看着不是"TCP 问题"，但 TCP 的实际状态直接决定体验。

VSCode Remote-SSH 连不上，常见报错有 connection timed out 和 kex_exchange_identification。前者是 TCP 层没通，查防火墙和 SSH 服务监听；后者更隐蔽——服务器上的 SSH 进程没有响应密钥交换，通常是因为SSH 并发连接数过多或者 /etc/hosts.deny 里限制了来源。

远程桌面分辨率降低，这个更偏会话管理，但它底层也依赖 TCP 长连接：连接建立期间如果网络波动导致 TCP 重传，RDP 协议会自动降级分辨率来保住连接。要避免的话，在组策略里关闭"连接时调整分辨率"选项，或者在客户端固定分辨率。

实操心得：解决远程工具连接问题，永远先验证"TCP 层是否能建立连接"，再谈应用层。很多 SSH/RDP 问题其实是云计算安全组没放行、防火墙拦截、或者服务只监听在 127.0.0.1 上。用 ss -lntp | grep :22 或 telnet IP 22 一步就能分辨。

6. C# 和 Qt 开发：TCP 连接数量的控制与并发问题

热搜词里有 c# tcp连接数量多少 和 qt tcp，说明很多同学在做客户端开发时对 TCP 连接管理存在疑问。

6.1 C# 中 TCP 连接数量的误区

C# 的 TcpClient 和 Socket 能建立的连接数量，理论上受限于三个因素：系统文件描述符上限、本地端口数量、服务端接收队列长度。

很多人问"客户端能开多少连接"，答案不是固定的。客户端主动发起连接时，本地端口号范围是主要瓶颈。Linux 上默认本地端口范围大约是 28000（可以通过 sysctl net.ipv4.ip_local_port_range 查看和调整）。也就是说，你用一个客户端 IP + 一个服务端 IP:端口组合，理论上最多能建立的连接数受限于这个范围。

但这只是理论值，实际上还会被内存、CPU、文件描述符限制。要同时建立大量连接做压测时，一般建议：

bash复制# 调整本地端口范围
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
# 调整文件描述符上限
ulimit -n 65535

服务端能给多少客户端提供服务，则是另一个层面。服务端通常用 listen backlog 来限制等待握手的队列长度，Accept 循环的处理速度也影响实际并发能力。C# 中建议用异步 AcceptAsync、SocketAsyncEventArgs 避免线程爆炸。

6.2 Qt TCP 开发的常见坑

Qt 里用 QTcpSocket 做连接，最常见的坑是没等 connected() 信号就调用 write()。Qt 是事件循环模型，connectToHost() 发出后，TCP 握手是异步的，必须等 connected 信号或 waitForConnected() 返回 true 之后才能写数据。

另外 QTcpServer 的监听地址如果写 QHostAddress::Any，会同时监听所有网卡的 IPv4 地址;如果需要限制本地访问，用 QHostAddress::LocalHost。这和前面讲的 bind 地址问题完全一致，只是 API 不同。

关于 Qt 写 TCP 长连接，建议设置套接字保活参数：

cpp复制socket->setSocketOption(QAbstractSocket::KeepAliveOption, 1);

它能让内核层定期发送探测包，防止网络中间设备因为空闲杀连接。不过注意，这个参数只保证 TCP 层不断开，应用层的业务心跳还是得自己实现——原因很简单，TCP 保活默认间隔好长时间才发一次，业务等不了那么久。

7. 连接束带：从 TIME_WAIT 到 keepalive 的调优参数

排查和调优是两码事。排查是找到问题，调优是让问题不再出现。我给几条常用的 TCP 参数调优建议，并说明这些参数为什么不该盲调。

7.1 常用内核参数

bash复制# 查看当前值
sysctl net.ipv4.tcp_tw_reuse net.ipv4.tcp_tw_recycle net.ipv4.tcp_fin_timeout
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

常用调优项：

• net.ipv4.tcp_tw_reuse = 1：允许客户端复用 TIME_WAIT 状态的连接。适合大量短连接的客户端，但不适用于服务端监听地址的复用。
• net.ipv4.tcp_fin_timeout：控制 FIN_WAIT_2 状态的持续时间。值太短可能导致对端还没发完数据就被强制关闭，反而不安全。
• net.ipv4.tcp_keepalive_time：TCP 保活探测的默认空闲时间，一般设 300-600 秒比较合理。
• net.ipv4.tcp_syncookies：SYN 洪水时启用 syncookies，能保命，但它绕过了半连接队列，可能干扰某些调试。

我要强调一下 tcp_tw_recycle：不建议开启。它在 NAT 环境下会因为时间戳错乱导致大量随机断连，排查极其痛苦。如果你是老运维，过去习惯开 tcp_tw_recycle，现在新内核很多已经默认去掉了这个选项，因为弊大于利。

7.2 应用层 keepalive 和 TCP keepalive

TCP keepalive 和应用层心跳是两回事，我反复强调这一点。

TCP keepalive 由内核自动发送探测包，逻辑是：如果连接空闲超过 tcp_keepalive_time，就发探测包；对端不回应则继续发 intvl 间隔的包，连续 probes 次无响应才判定连接断开。这个过程完全在传输层，应用层无感知。

应用层心跳则是业务代码里的协议消息，比如每 30 秒发一个 ping。它的价值不只是检测对端存活，还能穿透很多 TCP keepalive 管不到的中间设备超时——比如云负载均衡往往有自己的空闲超时，如果 4 分钟没有任何流量，它可能在 TCP 层就把连接杀了，即使你的机器在发 TCP keepalive 探测包，如果这些包被中间设备拦截或忽略，连接照样保不住。

所以在生产环境里，业务心跳才是保连接的首选方案，TCP keepalive 只能作为辅助。

7.3 一个典型的调优案例

之前遇到过一个线上服务，每隔一段时间就出现成片 connection reset by peer。抓包后发现对端在空闲了正好 120 秒时发了 RST。查了负载均衡配置，发现空闲超时是 120 秒。解决办法很简单：在应用层做心跳，间隔设为 30 秒，问题立刻消失。类似问题的排查口诀：规律性断连先怀疑空闲超时，间歇性断连先抓包看 RST 来源。

8. 排查问题的生产力工具

最后分享几个我日常高频使用的排查工具，覆盖命令行到图形界面，帮你把信息密度拉到最高。

8.1 Baseline：ss、tcpdump、telnet、nmap

这四个是我在任何机器上都会先用起来的工具：

• ss -tunap：查看连接状态。
• tcpdump -i any tcp port 端口 -n：抓包看握手和 RST。
• telnet IP 端口：快速探测端口通不通。新版 Linux 如果没有 telnet，可以用 nc -vz IP 端口 替代。
• nmap -sS -p 1-10000 IP：扫描目标端口开放情况，适合远程环境。

8.2 Wireshark 的隐藏技巧

很多人用 Wireshark 只会在图形界面点开包，其实它有特别管用的过滤能力：

text复制# 只看某个连接
ip.addr == 192.168.1.10 && tcp.port == 3306

# 只看 RST 包
tcp.flags.reset == 1

# 只看握手包
tcp.flags.syn == 1

另外 Wireshark 的 Statistics -> Flow Graph 功能，能把一个连接的完整交互画成时序图，非常适合给团队解释问题。

8.3 时延和连接质量的快速判断

如果你怀疑网络质量差导致连接异常，可以用 mtr （结合 ping 和 traceroute）观察每个节点的丢包率：

bash复制mtr -n --tcp -P 3306 192.168.1.10

输出里有每跳的 Loss% 和延迟。如果丢包集中在本地网关到目标链路中段，基本可以确认是广域网质量问题；如果只发生在目标节点最后一跳，则要怀疑目标服务器自身的防火墙或负载。

一点收尾的心里话

TCP 连接看起来只是简历上的一句话，实际排查起来牵扯到内核参数、网络安全策略、应用层连接管理、甚至业务心跳设计，一环扣一环。我接触过的所有线上连接问题，没有一次是单靠背概念解决的，全部是"抓包 + 看状态 + 推过程"的组合拳。

最后再分享一条：

遇到任何 TCP 连接异常，先别急着怀疑"网络不好"。用 ss 看清状态，再用 tcpdump 抓到证据，最后对照状态机推演时间线。陷阱往往不在你以为的地方——可能是服务监听了 127.0.0.1，可能是防火墙在中间静默丢包，也可能是连接池忘记释放导致 CLOSE_WAIT 堆积。把这三个环节走一遍，90% 的问题都能在你发出求助帖之前就自己解决。