本文深入剖析了Python中ConnectionResetError的根源与应对策略，指出该错误并非网络波动所致，而是对端（如服务器、负载均衡器或防火墙）主动发送RST包强制断连的明确信号，常见于长连接空闲超时、进程崩溃或代理策略清理。文章强调：仅靠异常捕获和简单重试远远不够——系统级TCP Keepalive必须在connect后显式启用并大幅调小探测参数（如Linux下KEEPIDLE=60秒），同时应用层必须构建双重保障：HTTP场景需结合HEAD探活+会话重建，WebSocket则须自主实现带超时监控的ping/pong心跳与状态感知重连，并严格处理鉴权、订阅恢复及TIME_WAIT规避。这是一份直击生产环境痛点、兼顾底层机制与工程落地的高可用连接治理指南。

ConnectionResetError 通常意味着对端主动关闭了连接

这不是网络抖动或超时，而是服务器（或中间代理、防火墙）直接发了 RST 包。常见于长连接空闲超时、服务端进程崩溃、负载均衡器主动踢掉空闲连接。Python 的 socket 或 requests、urllib3 底层遇到这个错误时会抛出 ConnectionResetError: [Errno 104] Connection reset by peer，此时连接对象已失效，不能再复用。

单纯捕获重试不加心跳，大概率重试时仍用着同一个已断的 socket，立刻再报一次 ConnectionResetError。

用 socket 自建 TCP 连接时必须手动加心跳

Python 标准库 socket 默认不开启 TCP Keepalive，操作系统默认 2 小时才探测，远超大多数服务端空闲超时（常见 5–30 分钟）。必须显式启用并调小间隔：

sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
# Linux：首次探测前空闲时间（秒）
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)
# 探测间隔（秒）
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 30)
# 失败重试次数
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)

• Windows 不支持 TCP_KEEPIDLE，需用 socket.IOCTL_KEEPALIVE_VALS（需 win32file）
• setsockopt 必须在 connect() 之后、send()/recv() 之前调用
• Keepalive 只保活底层 TCP 连接，不保证应用层协议有效（比如 WebSocket 还得发 ping/pong）

HTTP 客户端（requests/urllib3）无法靠系统 keepalive 解决问题

requests 底层用 urllib3 管理连接池，但它的连接复用逻辑和系统 TCP keepalive 是两套机制。即使 socket 层启用了 keepalive，urllib3 仍可能把一个“看起来还活着”的连接从池里取出，结果第一次 send() 就触发 ConnectionResetError。

可靠做法是：在业务请求前主动探测，或封装带重试的请求函数：

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
session = requests.Session()
retry_strategy = Retry(
total=3,
backoff_factor=1,
status_forcelist=[429, 500, 502, 503, 504],
allowed_methods=["HEAD", "GET", "OPTIONS", "POST"],  # 注意：默认不含 POST
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)
但 retry 不捕获 ConnectionResetError —— 它属于 ConnectionError 子类
所以还需外层 try/catch + 重试逻辑

• urllib3.Retry 默认不重试 ConnectionError（含 ConnectionResetError），需手动指定 raise_on_status=False 并在 except 中处理
• 更稳妥的是在每次请求前发个轻量 HEAD 请求探活，尤其适用于固定 endpoint 的长周期轮询
• 避免在重试中盲目复用 session —— 断连后整个连接池可能已脏，建议失败后 session.close() 并新建

WebSocket 场景下心跳必须由应用层控制

像 websocket-client 这类库虽提供 ping_interval 参数，但实际行为依赖底层实现，且断线后不会自动重连。真正健壮的做法是：

• 自己起一个后台线程，定期调用 ws.send('{"type":"ping"}')（按服务端要求格式）
• 设置 ws.settimeout(30)，并在 recv() 时捕获 websocket.WebSocketConnectionClosedException 和 OSError
• 重连前先 ws.close()，等待几秒再 connect()，避免 TIME_WAIT 风暴
• 重连成功后必须重新鉴权、重订阅，不能假设服务端还记得上次状态

最易被忽略的是：心跳包本身也可能失败。不要只监听 recv 超时，也要监控 send 是否卡住 —— 比如用 select.select([ws.sock], [], [], timeout) 做非阻塞检测。

本篇关于《Python处理ConnectionResetError：添加心跳与重连机制》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！