科技 · 实用指南
Linux 提示“Connection reset by peer”？重试前先定位 RST 的真正边界
保留一次失败，绑定精确套接字，抓取 TCP 流，确认被接受的 RST 方向，并在修改超时、keepalive 或防火墙前关联两端证据。
“Connection reset by peer”只证明当前套接字已结束，并不自动证明服务器应用主动关闭了连接。对端进程、内核、代理、负载均衡、防火墙或过期连接状态都可能产生最终被接受的 RST。
从一个带时间戳的失败和一个精确四元组开始。重试前保存首个错误、请求标识与失败字节位置；第二次成功可能抹去短暂证据，却无法解释第一次。
1. 重试前冻结一次失败
记录 UTC 时间、命令、请求或任务 ID、本地与远端地址端口、协议阶段及首个失败字节。保存完整错误链与相邻客户端日志，不要把多次重试混成一个事件。
先判断操作是否可能在重置前已提交。读取通常可重放；写入、上传、支付和任务提交未必安全。自动重试前检查应用状态或幂等键。
2. 把消息绑定到一个套接字
趁事件新鲜，用 `ss -tanp` 或运行时记录四元组与所属 PID。若在容器或网络命名空间中，必须在拥有连接的命名空间观察并记录边界。
区分连接阶段的拒绝与已建立后的重置，并记录故障发生在响应前、传输中还是看似成功的输出之后；三条分支对应不同责任方。
3. 抓取 TCP 流并确定 RST 方向
在已授权和最小权限下，用窄时间与端点过滤器抓包，例如 `tcpdump -i any -nn -s 0 -w reset.pcap 'host 192.0.2.10 and tcp port 443'`。记录接口、时钟与丢包数；不完整抓包中没看到报文不是证明。
打开精确流并找到 `RST`，记录源/目的地址端口、序列上下文与最后一次应用事件。条件允许时两端同时抓取；只在一侧可见的重置可能由路径设备注入或转换。
4. 关联端点与中间层证据
在表面发送端把四元组映射到进程，并检查同一 UTC 窗口的服务、内核、代理与负载均衡日志，查找重启、崩溃、空闲或请求超时、策略拒绝、连接池复用及资源限制。
不要把报文源地址直接等同于应用责任。NAT、sidecar、反向代理与中间盒都可能产生或转发重置；明确已观察边界、已证明进程和未知跳点。
5. 只修一个已证明分支并收口
修复证据指向的责任方：连接池复用、空闲超时、服务崩溃、协议成帧或明确策略。保持原日志和抓包不可变；同时调多个参数会破坏归因。
仅在安全时重放相同负载。验收要求结果正确、无重复副作用、测试窗口无相同重置且两端日志健康。一次重试成功只代表恢复，不代表根因已证明。
