科技 · 實用指南
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. 只修一個已證明分支併收口
修复證據指向的責任方：連接池复用、空闲超時、服務崩溃、协议成帧或明确策略。保持原日誌和抓包不可变；同時调多個参数會破坏归因。
僅在安全時重放相同負载。驗收要求結果正确、無重复副作用、測试窗口無相同重置且兩端日誌健康。一次重试成功只代表恢复，不代表根因已證明。
