直接回答
reset は TCP connection が予期せず閉じられた状態です。発生段階と connection 再利用の有無から stale pool と upstream 終了を分けます。
このガイドで解決できること
副作用を重複させず ECONNRESET、socket hang up、connection reset を解決する。
症状と影響範囲を確認する
request または response 転送中に ECONNRESET、socket hang up、connection reset by peer が発生します。
idle connection 再利用、長い stream、大きい upload、proxy timeout 付近に集中することがあります。
- 設定を変更する前に、ステータスまたは例外、レスポンス本文、request ID、UTC 時刻、クライアント版、最終ホストを保存します。
- 最小リクエストと失敗するワークフローを比較し、全体障害、モデル固有、機能固有のどれかを切り分けます。
- 認証情報、完全なプロンプト、顧客データ、非公開ファイルをスクリーンショットやサポート資料に含めません。
主な原因と責任境界
エラーは一つのレイヤーから得た証拠であり、下流全体の故障を証明するものではありません。まず次の可能性を順に検証します。
- server・proxy の idle timeout 後に古い keep-alive connection を再利用した。
- proxy、firewall、load balancer、upstream が能動的に接続を閉じた。
- 別レイヤーが read/write 中に client が cancel・abort した。
- hop 間で pool limit と lifecycle が不整合。
レイヤー別に最小診断を行う
可変要素が最も少ないリクエストから開始します。アカウント、API ホスト、対象モデルは維持し、任意機能だけを外します。
一度に一項目だけ変更し、元のステータス、ヘッダー、本文、所要時間を残します。これによりクライアントのシリアライズとゲートウェイ・上流の挙動を分離できます。
- 01境界を確定write 中、first-byte 待ち、response 読み取り中のどこで reset したか記録します。
- 02基準を作成モデル一覧と短い non-stream request で基準を作ります。
- 03一項目を比較forced new connection と通常の keep-alive を比較します。
- 04決定的な証拠を記録UTC 時刻、connection metadata、request ID で proxy log を照合します。
curl -sS --http1.1 -H 'Connection: close' --connect-timeout 10 --max-time 60 -o /tmp/reset-body.json -w 'remote=%{remote_ip} status=%{http_code} total=%{time_total}
' 'https://<your-api-host>/v1/models' -H "Authorization: Bearer ${API_KEY:?set API_KEY first}"
確認した根本原因に修正を適用する
証拠で確定したレイヤーだけを最小限変更します。決定的な設定エラーを広範な再試行や検証無効化で隠さないでください。
- 01障害レイヤーを修正client idle lifetime を最短の server・proxy idle timeout より短くします。
- 02必要な動作を復元pool size、queue wait、keep-alive、read deadline を hop 間で調整します。
- 03一時回避策を除去再実行安全な操作だけを上限付き backoff と cleanup 付きで retry します。
一度の成功ではなく修正結果を検証する
最小確認が成功したら元の経路を再実行し、通常のストリーミング、同時実行数、タイムアウト条件でも安定することを確認します。
- pool size、idle lifetime、queue timeout が負荷下で安定する。
- upstream idle deadline 前に client が connection を破棄する。
- 安全な request だけが回数・総時間上限内で retry される。
- reset 後に tool call・external write が重複しない。
セキュリティ境界とエスカレーション資料
認証、通信、権限、検証を弱めず、かつ機密情報を公開しない範囲で、再現とエスカレーションに必要な証拠を収集します。
- reset 検証のため TLS・proxy control を無効化しない。
- 曖昧な write は retry 前に完了済みの可能性を考慮する。
- header・payload を含む network trace を機密除去する。
- phase、reuse 状態、UTC 時刻、proxy layer、request ID で共有する。
公式情報と検証範囲
本ガイドはプロトコル仕様とクライアント公式文書を根拠にしています。エラー文、再試行ヘッダー、設定項目はサービスやバージョンで変わるため、参照元を確認し、ログとリクエスト例を秘匿してから共有してください。
技術検証方法を見る