curl のプロキシタイムアウト：失敗した段階を探す
プロキシ接続、トンネル交渉、TLS、応答の停止を分け、curl のタイムアウト設定から問題箇所を絞り込みます。
curl の詳細出力で最後に完了した処理を探します。「プロキシには接続したが CONNECT の応答がない」なら、単なる「プロキシがタイムアウトした」より問題を大きく絞れます。
時間制限付きのリクエストを使い、ローカルの例を自分の HTTP プロキシに置き換えます。比較用の別の接続先はHTTP プロキシ一覧などで探せます。
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/--connect-timeout 5 は、該当する名前解決やハンドシェイクを含む接続確立全体に一つの時間枠を与えます。各段階にそれぞれ 五秒を与える設定ではありません。--max-time 15 は接続後の転送時間も含め、処理全体を制限します。
| 進行が止まる箇所 | 次に調べる内容 |
|---|---|
| プロキシに接続できない | プロキシのホスト名解決、待ち受けポート、経路、ファイアウォールの方針。 |
| プロキシには接続済みだがトンネル応答がない | プロキシの負荷、認証交渉、アクセス方針、プロキシから宛先への到達性。 |
| トンネルは受理されたが TLS が未完了 | 宛先への到達性、TLS 交渉、管理下での通信傍受。 |
| 宛先のヘッダーは届くが本文が止まる | オリジンサーバーの転送動作、中継機器でのバッファリング、アプリケーションが意図的に送信を控えていないか。 |
基本的なハンドシェイクの順序は、CONNECT が HTTPS を運ぶ仕組みを参照してください。接続用の時間枠付近で止まるなら接続確立、後で全体の上限に達して止まるなら未完了の転送が疑われます。順序と時間を併せて判断してください。時間だけでは原因となる構成要素を特定できません。ログの表現は curl のビルドによって異なり、TCP ポートが開いていても CONNECT が動く証拠にはなりません。
一方の条件を固定する
許可された直接経路で同じ宛先にアクセスし、比較します。
curl --noproxy '*' --connect-timeout 5 --max-time 15 --verbose https://example.com/次に、同じプロキシ経由で別の無害な宛先を比較します。一つだけ失敗するなら、その経路や宛先のアクセス方針を調べます。すべてが同じ接続確立の段階で止まるなら、共通のプロキシ経路を調べます。開始時刻、接続先、宛先、最後に完了した段階を保存し、ログを共有する前に認証情報、トークン、Cookie、非公開の名前を削除してください。
接続は開いたままなのに有効な進展がない場合
ファイル転送では、接続確立と全体の時間制限に加え、低速時の制限が必要になることがあります。
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 60 --speed-limit 100 --speed-time 20 https://example.com/この設定は、継続する転送速度が 20 秒間毎秒 100 バイト未満のままなら中止し、全体の上限も 60 秒に保ちます。値は処理内容に応じて選びます。イベントストリームは長く無通信でも正常な場合があるため、ダウンロード用のルールで誤って中止される可能性があります。
すべての上限を延ばしても症状が出る時点を遅らせるだけです。即座に何度も再試行すると、過負荷の経路に接続を増やすおそれがあります。少数の意図した比較で診断してください。その後アプリケーションで採用する再試行方針には、独自の総時間枠と、処理を繰り返しても安全かどうかの検討が必要です。