直接回答
timeout は期限切れになった deadline だけを示します。各段階を測定し、巨大な一括 timeout で接続障害や遅い生成を隠さないようにします。
このガイドで解決できること
危険な再試行なしで connect、read、first-byte、generation、proxy、job timeout を修正する。
症状と影響範囲を確認する
接続前、初回バイト前、生成中、stream 読み取り中のいずれかで client timeout が発生します。
短い request は成功しても、長い context、大きい output budget、同時実行、proxy 経路が短い hidden deadline を超えます。
- 設定を変更する前に、ステータスまたは例外、レスポンス本文、request ID、UTC 時刻、クライアント版、最終ホストを保存します。
- 最小リクエストと失敗するワークフローを比較し、全体障害、モデル固有、機能固有のどれかを切り分けます。
- 認証情報、完全なプロンプト、顧客データ、非公開ファイルをスクリーンショットやサポート資料に含めません。
主な原因と責任境界
エラーは一つのレイヤーから得た証拠であり、下流全体の故障を証明するものではありません。まず次の可能性を順に検証します。
- DNS、TCP、TLS が遅い、または network path に到達できない。
- model queue・generation が first-byte / read timeout を超える。
- SDK、reverse proxy、load balancer、job runner の deadline が不一致。
- connection pool 枯渇で network 送信前に待たされる。
レイヤー別に最小診断を行う
可変要素が最も少ないリクエストから開始します。アカウント、API ホスト、対象モデルは維持し、任意機能だけを外します。
一度に一項目だけ変更し、元のステータス、ヘッダー、本文、所要時間を残します。これによりクライアントのシリアライズとゲートウェイ・上流の挙動を分離できます。
- 01境界を確定DNS、TCP、TLS、first-byte、total duration を個別に測ります。
- 02基準を作成短い non-stream request 一件で基準を作ります。
- 03一項目を比較短い・長い input、output budget、stream、制御された同時実行を比較します。
- 04決定的な証拠を記録SDK、proxy、gateway、outer job の全 timeout を列挙し最短値を探します。
curl -sS -o /tmp/timeout-body.json --connect-timeout 10 --max-time 60 -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total} status=%{http_code}
' 'https://<your-api-host>/v1/models' -H "Authorization: Bearer ${API_KEY:?set API_KEY first}"
確認した根本原因に修正を適用する
証拠で確定したレイヤーだけを最小限変更します。決定的な設定エラーを広範な再試行や検証無効化で隠さないでください。
- 01障害レイヤーを修正実測に基づき connect、read、total deadline を分けて設定します。
- 02必要な動作を復元timeout を増やす前に context、output budget、queue pressure を減らします。
- 03一時回避策を除去外側が正常な長時間 request を先に終了しないよう deadline を整合します。
connect_timeout = 10s
read_or_idle_timeout = 90s
overall_job_deadline = 120s
retry_attempts = 2
# 数值仅为示意，应以真实模型延迟、代理限制和业务 SLO 校准。一度の成功ではなく修正結果を検証する
最小確認が成功したら元の経路を再実行し、通常のストリーミング、同時実行数、タイムアウト条件でも安定することを確認します。
- 接続障害が明確な connect deadline で早く終了する。
- read と total budget が無制限にならず想定 latency を覆う。
- 制御負荷で connection pool が枯渇しない。
- 副作用を持つ request が曖昧な timeout 後に盲目的に再実行されない。
セキュリティ境界とエスカレーション資料
認証、通信、権限、検証を弱めず、かつ機密情報を公開しない範囲で、再現とエスカレーションに必要な証拠を収集します。
- すべての timeout を無効化しない。
- timing trace に authorization data を含めない。
- tool・write operation の retry 前に idempotency と task state を使う。
- phase timing、host、model、payload size、request ID を機密除去して共有する。
公式情報と検証範囲
本ガイドはプロトコル仕様とクライアント公式文書を根拠にしています。エラー文、再試行ヘッダー、設定項目はサービスやバージョンで変わるため、参照元を確認し、ログとリクエスト例を秘匿してから共有してください。
技術検証方法を見る