テクノロジー · 実用ガイド
Linux の「Connection reset by peer」—再試行前に RST の発生境界を特定する
1 回の失敗を保存し、正確なソケットに結び付け、TCP ストリームと受理された RST の向きを確認してから、タイムアウトや keepalive、ファイアウォールを変更します。
「Connection reset by peer」は現在のソケットが終了したことを示しますが、サーバーアプリが自ら閉じた証明ではありません。対向プロセス、カーネル、プロキシ、ロードバランサー、ファイアウォール、古い接続状態のいずれも RST を生成できます。
時刻付きの失敗 1 件と正確な 4 タプルから始めます。再試行前に最初のエラー、要求 ID、失敗したバイト境界を保存してください。二回目の成功は証拠を消しても最初の失敗を説明しません。
1. 再試行前に 1 件の失敗を固定する
UTC 時刻、コマンド、要求またはジョブ ID、両端アドレスとポート、プロトコル段階、最初の失敗バイトを記録します。複数回の再試行を一つの事象に混ぜないでください。
リセット前に処理が確定した可能性を評価します。読み取りは再実行しやすい一方、書き込み、アップロード、決済、ジョブ投入は危険です。冪等キーか実状態を確認します。
2. メッセージを一つのソケットに結び付ける
`ss -tanp` またはランタイムで 4 タプルと PID を保存します。コンテナやネットワーク名前空間では、その接続を所有する空間で観測し、境界を記録します。
接続時の拒否と確立後のリセットを分け、応答前、転送中、成功に見えた出力後のどこで起きたかを記録します。
3. TCP ストリームと RST の向きを確認する
許可と最小権限の下で、対象を絞って `tcpdump` に保存します。インターフェース、時計、ドロップ数を記録し、不完全なキャプチャに無いパケットを不在の証明にしません。
正確なストリームで `RST` の送信元、宛先、ポート、シーケンスと直前のアプリ事象を記録します。可能なら両端で採取し、経路装置による注入や変換を切り分けます。
4. 端点と中間装置の証拠を照合する
見かけの送信元で 4 タプルをプロセスへ対応させ、同じ UTC 窓のサービス、カーネル、プロキシ、ロードバランサーのログを読みます。再起動、クラッシュ、タイムアウト、ポリシー、プール再利用、資源制限を確認します。
送信元 IP をアプリの責任と即断しません。NAT、サイドカー、リバースプロキシ、中間装置が RST を生成または中継できます。観測済み、証明済み、不明を分けます。
5. 証明された一枝だけを修復して閉じる
証拠が示す所有者だけを修復します。複数の設定を同時に変えると因果を失います。元ログとキャプチャは変更せず保存します。
安全な場合に同じ負荷を再現します。期待結果、重複副作用なし、同じ RST なし、両端ログ正常を受け入れ条件にします。再試行成功だけは根因証明ではありません。
