レジデンシャルプロキシのリクエストがタイムアウトする理由

プロキシのタイムアウトに関する診断ガイド: 接続と読み取りの違い、過度に厳しいジオフィルター、データセンター向けに調整されたタイムアウト、そして本当の原因を素早く見つけるためのチェック方法について解説します。

「リクエストがタイムアウトする」は私たちが受け取るサポート連絡の中でも最も多いものの一つですが、同時に最も原因を特定しにくいものでもあります。タイムアウトは症状であって、原因ではありません。ゲートウェイが条件に合う出口IPを見つけられなかった場合も、クライアントが8秒必要な接続を5秒で諦めた場合も、ターゲットサイトが遅い場合も、あるいはあなたのコンテナの設定が誤っていてそもそもプロキシに到達していない場合も、同じエラーが表面化します。

これは診断ガイドです。実際に何が起きているのかを、最も早く見つけられる順番で特定する方法を示します。レイテンシの削減の姉妹編にあたります。あちらは動作しているセットアップを高速化する話でしたが、こちらはハングまたは失敗しているセットアップと、その理由についての話です。

ステップ0: それは本当にタイムアウトか

診断を始める前に、正確に分類してください。というのも、「タイムアウトしている」と報告される失敗には3種類あり、それぞれ対処法が異なるからです。

接続タイムアウト（Connect timeout） — クライアントがそもそもゲートウェイへの接続を確立できなかった場合。これはあなた側を示しています。ネットワークのegress、ファイアウォール、ホスト/ポートの誤り、あるいはコンテナ設定の問題です。
読み取り/レスポンスタイムアウト（Read / response timeout） — 接続は正常に確立され、リクエストは送信されたものの、応答が時間内に返ってこなかった場合。これは出口またはターゲットを示しています。条件に合うIPが存在しない、出口デバイスが遅い、あるいはターゲットサイトが遅いという場合です。
そもそもタイムアウトではない — 407（認証エラー）、502（フィルタに一致するIPがない）、あるいはハングしたCAPTCHAページなど。これらは、あらゆるものを一つの例外としてまとめて捕捉するラッパーコードによって、しばしばタイムアウトとして「報告」されます。

多くのクライアントでは、接続タイムアウトと読み取りタイムアウトを明示的に分離できます。これを行うことが最も価値のある診断ステップであり、通常はたった1行の変更で済みます。

import requests

# (connect_timeout, read_timeout) - separate them, don't pass a single number
r = requests.get(url, proxies=proxies, timeout=(10, 30))

最初の10秒以内に失敗する場合は接続の問題です。接続を乗り越えて30秒で失敗する場合は読み取りの問題です。該当するセクションに進んでください。

原因1: 地理フィルタが厳しすぎる

これが最も一般的な実際の原因であり、最も簡単に修正できます。

すべてのターゲティングフラグは、対象となる出口IPのプールを狭めます。country-usは非常に大きな集合から選択します。country-us-city-scranton-asn-12345はほとんど何も選択できないかもしれません。一致する出口が少ない、あるいは全くない場合、リクエストは待機した後失敗し、使用しているクライアントによってはタイムアウトや502として表面化します。

診断方法として、フラグを一つずつ緩めてみてください。

# Does it work with country only?
curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30

# Then add the city back and compare
curl -x customer-USER-country-us-city-chicago:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30

国指定のみで成功し、より狭いフィルタでタイムアウトするなら、原因が特定できたことになります。修正方法： データが本当に必要とする精度だけを維持してください。ユースケース上その都市が本当に必要な場合は、プールが小さくスループットが低くなることを見込み、予算を確保してください（都市レベルのターゲティングが重要になる場合で、そのコストに見合う場合を扱っています）。

原因2: タイムアウトがデータセンター向けに調整されており、レジデンシャル向けではない

僅差で二番目に多い原因であり、実際には壊れていないリクエストで「タイムアウト」を発生させます。

レジデンシャルトラフィックは家庭内ネットワーク上の実在する消費者デバイスを経由するため、データセンタープロキシにはないレイテンシの下限があります（レジデンシャル対データセンター）。データセンターでは全く妥当な5秒の合計タイムアウトも、健全なレジデンシャルリクエストを途中で打ち切り、失敗として報告してしまいます。

診断方法として、調整する前に測定してください。実際のターゲットに対して、プロキシ経由でp50とp95のレイテンシを収集します（プロキシの速度・成功率・位置精度をテストする方法に手法があります）。タイムアウトがp95を下回っている場合、あなたは自ら失敗を作り出していることになります。

修正方法： 推測ではなく、測定したp95より余裕を持って高いタイムアウトを設定してください。出発点として、レジデンシャルでは接続タイムアウトを約10秒、読み取りタイムアウトを30秒以上とするのが妥当です。そこから自分の数値に基づいて調整してください。

原因3: プロキシではなくターゲットが遅い

確認は簡単ですが、誤解もしやすい部分です。同じリクエストパスを、高速でニュートラルなエンドポイントと、同じプロキシ経由の実際のターゲットの両方で計測してください。

# Neutral endpoint - measures proxy overhead
requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

# Your real target - measures proxy overhead + target latency
requests.get("https://your-target.example/page", proxies=proxies, timeout=(10, 30))

ニュートラルなエンドポイントが高速で、ターゲットが遅い場合、プロキシは問題ではなく、どれだけプロキシを調整しても解決しません。そのターゲットについては読み取りタイムアウトを引き上げるか、取得するページの量を減らしてください。

原因4: 同時実行数が多すぎる

負荷がかかっているときにのみ現れ、単一リクエストでテストすると消えるタイムアウトはここに該当します。

考えられるメカニズムは2つあります。ローカルリソース（コネクションプールのスロット、ファイルディスクリプタ、イベントループの容量）を使い果たしており、リクエストがプロキシに到達する前に自分側でキューイングされている場合。あるいは、ターゲットがあなたをレート制限しており、クリーンな429を返す代わりにハングさせている場合です。

診断方法として、同時実行数を1に落として再テストしてください。タイムアウトが消えるなら、負荷が原因です。修正方法： 一つのグローバルな数値ではなく、ホストごとの同時実行数制限を適用してください。これはプロキシの負荷分散で扱っているアーキテクチャです。

原因5: コネクション処理

正反対の2つの誤りがあり、どちらもタイムアウトを引き起こします。

コネクションの再利用がない場合。 リクエストごとに新しい接続を作成すると、毎回プロキシ経由で完全なTCP + TLSハンドシェイクを行うことになり、遅くなり、タイムアウトの余裕もはるかに少なくなります。プーリングを行うセッション/クライアントを使用してください。

古いプールされたコネクション。 コネクションをプールしつつリクエストごとに出口IPをローテーションしている場合、プールされたソケットがもはや有効でない出口を指している可能性があり、それらはハングします。プーリングとスティッキーセッションを組み合わせ、プールされたコネクションを一つの出口に固定し、定期的にコネクションを再利用してください。

原因6: 出口デバイス自体

レジデンシャルの出口は、実在する家庭内ネットワーク上の実際の消費者デバイスです。混雑した回線上にあるものもあれば、モバイルのものもあり、リクエストの途中で切断されるものもあります。遅いリクエストや失敗するリクエストが一定の割合で存在するのは、レジデンシャルにおいては正常であり想定内であり、欠陥ではありません。

修正方法： 最悪のデバイスに合わせてタイムアウトを引き上げないでください。それはすべての失敗を単に遅くするだけです。早く失敗させ、新しいアイデンティティで再試行することで、別の出口を得られます。昨日のフェイルオーバーガイドでは、トランスポート層の失敗を分類し正しく再試行する方法を扱っています。プールの品質が、そのテール（尾部）がどれだけ厚くなるかを決定します（IPレピュテーション）。

原因7: そもそもプロキシに到達していない

すべてがタイムアウトする場合、特にコンテナ環境では早めに確認する価値があります。

リクエストが実際にゲートウェイを経由してegressしているか確認してください。

curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org
# Returns a residential IP -> proxy is working.
# Returns your own IP    -> your client is ignoring the proxy.
# Hangs entirely         -> local egress is blocked (firewall, VPN, corporate network).

DockerやKubernetesでは、これが頻繁な原因です。クライアントがHTTP_PROXYを全く尊重していない、NO_PROXYの設定が誤っている、あるいはコンテナ内ではlocalhostが思っている意味を持たない、といったケースです。Docker設定ガイドではこれらを具体的に扱っています。

原因8: 認証情報エラーの偽装

ターゲティングフラグのタイプミスやサポートされていないパラメータによる不正な形式のユーザー名、あるいは誤った認証情報は、クライアントが407をどう処理するかによって、ハングや一般的な失敗として現れることがあります。最も緩い設定でもなお失敗する場合は、ネットワークの問題を疑う前に、認証情報の文字列を一文字ずつ確認してください。

診断の順序

以下を順番に実行してください。それぞれが大きな原因のカテゴリを排除します。

接続タイムアウトと読み取りタイムアウトを分離する。 接続失敗はあなた側、読み取り失敗は出口またはターゲットを示します。
そもそもプロキシを経由しているか確認する（上記のipifyチェック）。
countryのみでテストする。 それでうまくいくなら、地理フィルタが厳しすぎたということです。
ニュートラルなエンドポイントとターゲットを比較する。 プロキシのオーバーヘッドとターゲットの遅さを切り分けます。
同時実行数を1に落とす。 タイムアウトが消えるなら、プロキシではなく負荷が原因です。
測定したp95に対してタイムアウトを確認する。 それを下回っている場合、あなたが自ら失敗を作り出しています。

6つのチェックであり、実際にはそのうちの一つが、私たちが目にするほぼすべてのタイムアウト報告の説明になります。

タイムアウトが実際には問題ない場合

遅いリクエストや失敗するリクエストの少量のテールは、レジデンシャルプロキシに固有のものです。実際の消費者デバイスは本質的にばらつきがあるからです。タイムアウトをどんどん長くして100%の成功率を追い求めるのは間違った目標であり、失敗の数を減らさずに、失敗を遅くするだけです。

正しい目標はSLOです。ワークロードに対して許容できる成功率とp95を定義し、テール部分では早く失敗させ、新しいアイデンティティで再試行してください。30秒でリクエストを失敗させ再試行で成功するパイプラインの方が、120秒待ち続けるパイプラインよりも健全です。

FAQ

都市やASNフィルタを使うとタイムアウトするのに、国指定のみだとしないのはなぜですか？ 各フラグが対象となる出口プールを狭めるためです。国＋都市＋ASNでは、一致するIPが非常に少なくなり、リクエストが待機した後失敗することがあります。データが本当に必要とする精度まで緩め、厳密なターゲティングが本当に必要な場合はスループットの低下を見込んでください。

レジデンシャルプロキシにはどのようなタイムアウト値を使うべきですか？ まず測定してください。タイムアウトは観測したp95より余裕を持って高く設定すべきです。出発点として、接続で約10秒、読み取りで30秒以上がレジデンシャルでは妥当であり、そこから自分の数値に基づいて調整してください。データセンター向けに調整されたタイムアウトは、健全なレジデンシャルリクエストを打ち切ってしまいます。

プロキシとターゲットのどちらが遅いのか、どう見分ければよいですか？ 同じプロキシ経由で、高速なニュートラルエンドポイントと実際のターゲットの両方を計測してください。ニュートラルエンドポイントはプロキシのオーバーヘッドを計測します。その差がターゲット自身のレイテンシです。ニュートラルエンドポイントが高速であれば、プロキシは問題ではありません。

単純なリクエストでさえ、すべてがタイムアウトします。何が問題でしょうか？ そもそもプロキシに到達しているか確認してください。IPエコーエンドポイントをプロキシ経由でcurlしてみます。自分のIPが返ってくる場合、クライアントがプロキシを無視しています。完全にハングする場合、ローカルのegressがブロックされています（ファイアウォール、VPN、コンテナ設定）。その後、認証情報とフラグを確認してください。

タイムアウトを単に長くすればよいのでしょうか？ 通常はそうではありません。原因が厳しすぎる地理フィルタ、遅いターゲット、あるいは不良な出口デバイスである場合、タイムアウトを長くしても失敗にかかる時間が長くなるだけです。原因を修正し、避けられないテール部分については、早く失敗させて新しいアイデンティティで再試行してください。

結論

タイムアウトは少なくとも8つの異なる原因を持つ症状であり、修正方法はどの原因であるかに完全に依存します。接続と読み取りを分離し、実際にプロキシを経由しているか確認し、地理フィルタを緩め、ターゲットの遅さとプロキシのオーバーヘッドを切り分け、同時実行数1でテストし、測定したp95に対してタイムアウトを確認してください。この一連の手順で、大多数のケースが解決し、通常は数分で済みます。

そしてテール部分は受け入れてください。レジデンシャルの出口は実在するデバイスであり、ある程度のばらつきは実ユーザーの信頼性を得るための代償です。早く失敗させ、新しいアイデンティティで再試行し、あるリクエストがタイムアウトするかどうかではなく、成功率とp95でセットアップを判断してください。6つのチェックを終えてもまだ解決しない場合は、レジデンシャルゲートウェイのドキュメントと私たちのチームが絞り込みをお手伝いできます。接続/読み取りの分離結果と、失敗している認証情報文字列のサンプルをご用意いただければ、通常はすぐに回答できます。