レジデンシャルプロキシでよくあるエラーとその対処法

プロキシの問題は、その渦中にいるときは様々に見えるものですが、実際にはかなり反復的です。うまくいかない事象のほぼすべては9つのパターンに分類でき、たいていの場合、応答そのものがどのパターンに当てはまるかを教えてくれます。これは索引です。自分の症状を見つけ、想定される原因と即座の対処法を得て、詳しい内容が必要なときはリンクをたどってください。

早見表

症状	通常の意味	まず行うこと	再試行すべきか
407 Proxy Authentication Required	認証情報が間違っている、またはユーザー名内のフラグが不正な形式	フラグなしのユーザー名単体でテストする	再試行しない
502 Bad Gateway	その時点でフィルタに一致するアドレスがなかった	フィルタを広げる	フィルタを広げた後のみ
509 Bandwidth Limit Exceeded	プランの割り当てを使い切り、超過分が無効になっている	ウォレットとプランを確認する	再試行しない
接続拒否またはハング	そもそもゲートウェイに到達していない	nc -vz p.shifter.io 443	再試行しない、まず接続性を修正する
タイムアウト	ターゲットの遅延、フィルタが厳しすぎる、または自分側の同時接続数	接続時間と読み取り時間を切り分ける	バックオフ付きで再試行する
403 またはチャレンジページ	プロキシではなくターゲットがIDを拒否している	セッションを破棄し、ヘッダーを確認する	同じセッションでは再試行しない
429 Too Many Requests	ターゲットがリクエストレートを制限している	Retry-Afterに従い、その後ペースを落とす	待機後に再試行する
内容が間違っている、または空の 200	ソフトブロック、または誤ったロケール	本文を検証し、地域シグナルを確認する	原因が解決するまで再試行しない
毎リクエスト同じIP	ほぼ常にクライアント側のコネクション再利用	別プロセスでテストする	該当なし

407: 認証が拒否される

ゲートウェイが認証情報を拒否したということは、トラフィックはゲートウェイに到達しており、接続自体は問題ないということです。

ほぼすべての原因はこの3つに集約されます。認証情報のタイプミス、拡張ユーザー名内のフラグの形式不正、あるいはパネルでパスワードがローテーションされたのに古いコピーがどこかにまだ配置されている、というものです。真ん中のケースは最も気づきにくいものです。country-gb の代わりに country-uk のような認識されない値を使うと、ユーザー名全体が解析不能になり、ターゲティングエラーではなく認証エラーとして報告されるためです。

診断方法は常に同じです。まずすべてのフラグを取り除き、ユーザー名単体でテストします。それで成功すれば、原因はフラグ側にあるので、一つずつ戻して追加していきます。それでも失敗する場合は、パネルからパスワードを再度コピーしてください。詳細は407と認証情報エラーの修正にあります。

407を再試行してはいけません。これは終端的なエラーであり、再試行ループはそれに対して帯域を消費するだけでなく、外部から見ると認証情報の総当たり攻撃のように見えてしまいます。

502: フィルタに一致するものがない

認証情報は受理されたものの、要求した組み合わせに利用可能なアドレスがなかったということです。これはターゲティングの問題であり、故障ではありません。

これは、都市が非常に狭い範囲であったり、特定のASNであったり、あるいはその両方の組み合わせであったりするフィルタで多く発生し、現地のプールが薄い時間帯ではより起こりやすくなります。これは可用性が人間の活動に連動しているためです。フィルタを広げる、都市から地域や国のレベルに落とす、あるいは厳密なマッチングを外してゲートウェイがより広いプールにフォールバックできるようにしてください。厳密なマッチングを意図的に利用している場合、このエラーはシステムが意図通りに動作していることを示しています。背景情報は国別の可用性にあります。

509: 帯域切れ

プランの割り当てを使い切り、超過利用が有効になっていないため、リクエストが停止します。接続や設定には何の問題もありません。超過利用を有効にするために残高を追加するか、サイクルのリセットを待ってください。これが定期的に発生する場合、プランのサイズが不足しているということであり、これは月間帯域の見積もりで扱われている予測の問題です。

接続拒否、または永遠にハングするリクエスト

そもそもゲートウェイと通信できていません。通常の原因は2つあります。p.shifter.io:443 ではなく古いポートベースのホストを指定している、あるいは自分のネットワークがそのポートでの外向きトラフィックをブロックしている、のいずれかです。

プロキシに関する何かを想定する前に、まず生の接続性をテストしてください。

nc -vz p.shifter.io 443

これが失敗する場合、それは自分側の出口またはファイアウォールの問題です。成功するのにリクエストがまだ失敗する場合は、上記の認証の経路に入ります。

タイムアウト

最も曖昧なクラスです。いくつもの異なる問題が同じ症状を生み出すためです。最も有用な一手は、接続時間と合計時間を切り分けることです。これらは正反対の方向を示すためです。

curl -o /dev/null -s -w "connect: %{time_connect}s  total: %{time_total}s\n" \
  -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

接続が遅い場合は、プロキシ経路か、フィルタが厳しすぎてアドレス選択が遅くなっていることを示しています。接続は速いのに合計が遅い場合は、ターゲット側が遅いということであり、これはプロキシを変更しても解決しません。また、自分のタイムアウト設定が単にデータセンターのレイテンシ向けに調整されていないかも確認してください。レジデンシャル接続は正当に遅く、2秒のタイムアウトはエラーではない理由で常に失敗するためです。完全な診断はリクエストがタイムアウトする理由に、調整のオプションはレイテンシの削減にあります。

403、キャプチャ、チャレンジページ

これらはプロキシではなくターゲットから返されるものであり、認証と接続の両方がうまくいっていたことを意味します。ターゲットがリクエストを見て、それを拒否したのです。

即座の対応は、そのセッションを破棄し、同じIDで再試行するのではなく新しいセッションを取得することです。持続的な対応は原因を突き止めることであり、可能性の高い順に、まずペース、次にリクエストの形状、次に振る舞い、最後にアドレスの品質です。ペースを落とすことは他の何よりも多くの問題を解決します。レート制限とスロットリングを参照してください。ペースが妥当であれば、次に疑うべきは互いに矛盾しているヘッダーとユーザーエージェントです。回復の手順はIPがBANされたときの対処法にあります。

429: リクエストが多すぎる

ターゲットがレート制限をかけています。403と同様、これはゲートウェイではなくターゲット側から来るものなので、認証情報も接続も問題ありません。これは、リクエストが1人の訪問者、1つのセッション、または1つのネットワークに対してターゲットが受け入れる速度より速く到着していることを意味します。

すぐに再試行するのではなく、ペースを落としてください。応答にRetry-Afterヘッダーが付いている場合は、そのターゲットへの次のリクエストまで少なくともその時間だけ待機してください。付いていない場合は、指数的にバックオフし、そのターゲットに対する同時実行数を減らし、1つのセッションに多くを押し込むのではなく、より多くのセッションにリクエストを分散させてください。429を同じペースで再試行すると、一時的な制限がブロックに変わってしまいます。ペース調整の方法は、上記の403のセクションにリンクされているレート制限ガイドに記載されています。

望んでいたものではない200

最もコストのかかる失敗です。何も間違っているように見えないためです。チャレンジページ、空の結果セット、切り詰められた一覧、あるいは一般的な地域向けページのいずれも成功ステータスとともに届くことがあり、ステータスコードを数えるパイプラインはそれらをデータとして記録してしまいます。

内容が欠落しているのではなく間違っている場合、まず疑うべきは地理情報です。出口国と矛盾する Accept-Language ヘッダーや、プロキシではなく自分の所在地からホスト名を解決してしまうDNSリークは、どちらも間違った市場向けのもっともらしいコンテンツを生み出します。地理、タイムゾーン、ロケールの一致とDNSリークの防止を参照してください。

内容がチャレンジやスタブである場合は、それをブロックとして扱ってください。ブロックまたは偽のコンテンツの検知を参照。いずれにせよ教訓は同じです。応答を成功として数える前に本文を検証してください。さもなければ監視には何の意味もありません。

毎リクエスト同じアドレス

ローテーションが壊れているように見えますが、ほぼ壊れていません。通常の原因は、HTTPクライアントが1つのコネクションを再利用していること、そして出口アドレスがリクエストごとではなく、コネクション確立時に選ばれることにあります。

まず別プロセスでテストしてください。

for i in 1 2 3; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 http://ip-info.com/json | head -c 60; echo
done

これでローテーションするのに自分のアプリケーションではローテーションしない場合、原因はクライアント側のコネクションプーリングです。どちらもローテーションしない場合は、ユーザー名内にスティッキーセッションを要求する sid フラグがないか確認し、見えているアドレスが単に自分自身のものではないこと、つまりプロキシがまったく適用されていないという事態ではないことを確認してください。詳しい原因はIPがローテーションしないにあります。

ブラウザでの場合: ERR_PROXY_CONNECTION_FAILEDとERR_TUNNEL_CONNECTION_FAILED

ブラウザはしばしば、プロキシのステータスコードを独自のエラー名の背後に隠してしまいます。ほとんどのケースは2つでカバーされます。

• ERR_PROXY_CONNECTION_FAILEDは、ブラウザがプロキシに全く到達できなかったことを意味します。上記の接続拒否と同様に扱ってください。ホストがp.shifter.ioでポートが443であることを確認し、次にネットワーク、ファイアウォール、アンチウイルスソフトが接続をブロックしていないか確認してください。
• ERR_TUNNEL_CONNECTION_FAILEDは、ブラウザはプロキシに到達したものの、プロキシがターゲットへのトンネルを開かなかったことを意味します。これは通常407(認証情報または不正な形式のフラグ)または502(フィルタに何も一致しなかった)なので、407のセクションと同様に、まずユーザー名単体でテストしてください。

TLSと証明書のエラー

あまり一般的ではなく、通常は環境に起因します。古いTLSライブラリがゲートウェイの暗号スイートを拒否している場合や、企業のミドルボックスが信頼チェーンを壊している場合です。まずクライアントライブラリを更新してください。証明書検証を無効にすればエラーは消えますが、これは診断を確認するためだけに使い、出荷するものには決して使わないでください。

全体的な対応の順序

何かが壊れていて、どこから始めればいいか分からないとき。まず生の接続性を確認し、次にフラグなしの単体の認証情報をテストし、次にフラグを一つずつ戻し、最後にステータスコードを信じるのではなく、応答が本当に要求した通りのものかを確認します。この順序で数分のうちに問題の層を切り分けられます。これは症状がエラーコードであっても、微妙におかしいデータであっても同じ手順です。

急性のものではなく継続的な問題については、手動で気づく前にこれらを検知する計測手法が大規模なプロキシ健全性の監視にあります。

よくある質問

まとめ

9つのパターンでほぼすべてをカバーできます。407は認証情報かフラグの形式不正であり、再試行する価値は決してありません。502は故障ではなく空のフィルタです。509は帯域です。接続拒否はそもそもゲートウェイに到達していないことを意味します。タイムアウトは何よりもまず接続時間と合計時間を切り分ける必要があります。403やチャレンジは、ターゲットが拒否しているということなので、IDを変更してから原因を突き止めてください。429はターゲットがペースを落とすよう求めているので、Retry-Afterに従い、ペースを落としてください。内容が間違っている200は最も危険なものであり、だからこそ本文の検証は省略できません。そして毎リクエスト同じアドレスになるのは、ほぼ常に自分のクライアント側でのコネクション再利用です。接続性から外側に向かって作業を進め、ステータスコードが主張することではなく、実際に返ってきたものを確認してください。

ゲートウェイ自体については接続方法、用語については用語集、製品についてはresidential proxiesとGB単位の料金で解説しています。