テクノロジー · 実用ガイド
curl エラー56「Recv failure」：再試行前にリセット段階を特定する
「Connection reset by peer」は受信経路が突然終わったことだけを示し、原因の機器やプロセスは示しません。実効curl、バイト方向、最後に完了した段階を保存します。
「Connection reset by peer」は受信経路が突然終わったことだけを示し、原因の機器やプロセスは示しません。実効curl、バイト方向、最後に完了した段階を保存します。
CURLE_RECV_ERRORはコード56で受信失敗を示します。 TCP resetはendpointまたは経路装置から届き、curlだけでは送信元を証明できません。
1. 失敗requestを安全に固定
curl実体、`curl -V`、host/port、proxy変数、container/service、DNS、秘密を除いたcommandを記録し、error56、時刻、request ID、送受信bytesを保存します。
再試行前にmethodと副作用を分類します。POST、PUT、uploadは応答がなくても処理済みの可能性があるため、idempotency keyまたはserver状態を確認します。
2. 最後の完了段階を記録
`--verbose`または秘密を除いた時刻付きtraceで一度再現し、TCP、CONNECT、TLS、request header/body、response header/bodyの最後の確認点を示します。
方向を保存します。upload中のresetとresponse受信後のresetは別です。長さとbytesは残し、credentialと機密bodyは残しません。
3. connection ownerを照合
timestamp、接続tuple、hostname、protocol、request IDをorigin、reverse proxy、load balancer、egress logと照合します。resetはconnection eventでありorigin appとは限りません。
directとproxyを比べる時は一変数だけ変更し、別clientの成功はDNS、IP family、proxy、TLS、HTTP、payloadが同じと証明してから使います。
4. 原因を一つだけ変更
最初の矛盾証拠を所有する境界を修正します。serverの読取または明示reject、proxy route/idle policy、crash worker、protocol期待などです。TLS検証無効化を近道にしません。
`--retry`は操作の意味とinstalled curlの条件を確認後に使います。成功しても重複処理や閾値を隠す場合があります。
5. 同じ経路とpayloadを受入
同じuser、binary、network、payload classで再試行し、exit0、期待status、完全body/checksum、peer logのresetなし、二回目の成功を要求します。
最後の正常段階、双方向bytes、観測者、相関log、一変更、受入結果を短いledgerに保存します。
