一般的なプロキシエラーとその修正方法

プロキシエラーは、スクレイピング、SEOモニタリング、価格追跡、広告検証、ブラウザ自動化のワークフローに静かにダメージを与える可能性があります。ジョブは実行中のように見えるかもしれませんが、裏ではリクエストがタイムアウトし、セッションがリセットされ、ページがソフトブロックを返したり、地理的にターゲットを絞った結果が誤った場所から来たりしています。

最も一般的なプロキシエラーは、通常、認証の問題、レート制限、ブロックされたIP範囲、TLSまたはDNSの不一致、不安定なプロキシルート、セッションの不整合、またはリクエストのペーシングが不十分であることから発生します。解決策は必ずしも「別のプロキシを使用する」ではありません。信頼できるセットアップには、正しい認証情報、より良いルーティング、クリーンなセッション設計、バックオフ、コンテンツの検証、およびパイプラインが実際に改善されているかどうかを示すメトリクスが必要です。

ウェブスクレイピングプロキシを使用しているチームにとって、目標はシンプルです：失敗したリクエストを減らし、有効な出力を改善し、成功したリクエストあたりのコストを下げることです。

簡単な回答：プロキシエラーが発生する理由

プロキシエラーは、リクエストパスの1つのレイヤーが失敗するか、一貫性がなくなると発生します。

そのレイヤーは次のいずれかです：

• プロキシ認証
• IPの評判
• リクエストのボリューム
• セッションクッキー
• DNS解決
• TLSハンドシェイク
• ブラウザフィンガープリンティング
• ターゲット側のレート制限
• 地理ルーティング
• プロキシプールの健康

407エラーは通常、プロキシ認証を指します。429はレート制限を指します。403はターゲットがルートまたはセッションをブロックしたことを意味する場合があります。タイムアウトや502/504エラーは、不安定な上流ルートを指すことが多いです。CAPTCHAやインタースティシャルページは、通常、ターゲットがトラフィック、フィンガープリンティング、またはセッションシグナルに基づいて摩擦を適用していることを意味します。

プロキシエラーを修正する最良の方法は、最初に失敗しているレイヤーを特定し、次に最小限のターゲット修正を適用することです。

プロキシエラー診断表

この表を最初のガイドとして使用してください。

すべてのエラーを同じように扱わないでください。407、429、およびソフトブロックには異なる応答が必要です。

407 プロキシ認証が必要

407エラーは、プロキシサーバーが認証に失敗したためにリクエストを拒否したことを意味します。

一般的な原因は以下の通りです：

• ユーザー名が間違っている
• パスワードが間違っている
• トークンが期限切れ
• プロキシポートが間違っている
• 認証ヘッダーが欠落している
• IPが許可リストにない
• 不正なプロキシURL
• SOCKSエンドポイントでHTTP資格情報を使用している
• シークレットのローテーションが正しく展開されていない

407エラーの修正方法

まず、既知の良好なクライアントを使用してシンプルな単一リクエストテストを行います。プロキシホスト、ポート、ユーザー名、パスワード、およびプロトコルを確認します。

確認すべき項目：

• 資格情報の形式
• エンドポイントの種類
• 認証方法
• トークンの有効期限
• アカウントの状態
• IPの許可リスト
• 環境変数
• アプリケーションのシークレットストア

認証がIPベースの場合、リクエストが期待されるサーバーIPから来ていることを確認します。インフラが自動スケーリングされたり、クラウドリージョンが変更された場合、アウトバウンドIPが変更されている可能性があります。

監視すべき項目

環境、デプロイメント、およびプロキシアカウントごとに407の発生率を追跡します。突然の急増は通常、設定のずれ、資格情報の期限切れ、またはデプロイメントの問題を意味します。

403 Forbidden

403は、ターゲットサーバーがアクセスを拒否したことを意味します。これは、権限、ターゲット側のブロック、IPの評判、ブラウザのフィンガープリンティングの問題、またはリクエストパターンの問題によって引き起こされる可能性があります。

一般的な原因は以下の通りです：

• プロキシ範囲がブロックされている
• データセンターASNがフラグ付けされている
• 必要なヘッダーが欠落している
• 無効なセッションクッキー
• サポートされていない国または地域
• 攻撃的なリクエストレート
• ターゲットが自動化を検出している
• サイトポリシーによってアクセスが制限されている

403エラーの修正方法

まず、ページが通常のブラウザを通じてアクセス可能かどうか、またワークフローが許可されているかを確認します。ページがログインを必要とする場合、セッションが有効であることを確認します。

次に、原因を特定します：

• クリーンなクライアントからの単一リクエストをテストします。
• データセンターと住宅ルートを比較します。
• 同時実行数を減らします。
• ヘッダーとクッキーを確認します。
• 地域と言語設定を検証します。
• 返されたコンテンツがハードブロックかソフトブロックかを確認します。

データセンター範囲をブロックする公開ページの場合、住宅プロキシが成功率を向上させる可能性があります。寛容なターゲットの場合、データセンターのプロキシが依然としてコスト効率が良いかもしれません。

より広範なルーティングの決定については、データセンター対住宅対ISPプロキシの説明を参照してください。

401 Unauthorized

401は通常、ターゲットが有効な認証を必要とし、リクエストがそれを提供していないことを意味します。

一般的な原因は以下の通りです：

• ログインセッションが期限切れ
• ベアラートークンが欠落している
• 無効なAPIキー
• クッキーが保持されていない
• ログインフローが壊れている
• セッションが以前のIPに結びついている
• アカウントが再認証を必要としている

401エラーの修正方法

APIワークフローの場合、トークンを更新し、認証ヘッダーを確認します。

ブラウザワークフローの場合、クッキー、ローカルストレージ、およびセッション状態を保持します。ターゲットがログイン状態をネットワークアイデンティティに結びつけている場合、セッション中にIPをローテーションすることは避けてください。

アカウントベースのワークフローには、スティッキーまたはスタティックセッションを使用します。ルートの動作についての詳細は、ローテーション対スタティックプロキシを参照してください。

429 Too Many Requests

429は、ターゲットがワークロードをレート制限していることを意味します。

一般的な原因は以下の通りです：

• 1つのIPからのリクエストが多すぎる
• 1つのサブネットからのリクエストが多すぎる
• ドメインごとの同時実行数が高い
• バーストスケジューリング
• リトライストーム
• 高摩擦エンドポイントへの繰り返しアクセス
• エラー後のバックオフがない

429エラーの修正方法

よりスムーズなトラフィックシェーピングを使用します。

推奨される修正：

• ドメインごとの同時実行数を減らす
• ランダムなジッターを追加する
• 指数バックオフを使用する
• ジョブを長いウィンドウに分散させる
• 安定した応答をキャッシュする
• すぐにリトライしない
• 高リスクエンドポイントを低リスクページから分離する
• ワークフローが許可する場合のみローテーションする

単にリトライを増やすだけではありません。深いリトライはコストを増加させ、レート制限を悪化させる可能性があります。

監視すべき項目

リトライの深さ、ブロック率、およびCPSRを追跡します。

CPSRは成功したリクエストあたりのコストを意味します。簡単に言うと、CPSRはプロキシの支出、計算、再試行、失敗の後に各有効な結果のコストを示します。

429エラーが減少してもCPSRが上昇する場合、修正が効率的でない可能性があります。

502および504ゲートウェイエラー

502または504は通常、クライアント、プロキシプロバイダー、およびターゲットサーバー間の上流の問題を指します。

一般的な原因には以下が含まれます：

• 不安定なプロキシ出口
• 過負荷のルート
• ターゲットサーバーの遅延
• プロキシチェーンの失敗
• 地域的なルーティングの問題
• タイムアウトが短すぎる
• 不良な上流接続

502および504エラーの修正方法

バックオフを伴う制限付き再試行を使用します。無限に再試行しないでください。

推奨される修正：

• 遅延を伴って1〜2回再試行
• 繰り返し失敗した後にプロキシルートを切り替え
• 地域およびプロキシプールで監視
• 失敗した出口を隔離
• ターゲットが通常遅い場合のみタイムアウトを増加
• 影響を受けるドメインでの同時接続を減少
• ネットワークエラーをターゲットブロックから分離

重いJavaScriptページの504エラーは、単純な静的HTMLページとは異なるタイムアウトが必要な場合があります。

接続タイムアウトとECONNRESET

タイムアウトや接続リセットは、接続が完了できないか、予期せずに閉じられたときに発生します。

一般的な原因には以下が含まれます：

• 死んだプロキシ出口
• 過負荷のターゲット
• 不安定なネットワークパス
• ブロックされた接続
• 開いているソケットが多すぎる
• タイムアウト設定が攻撃的すぎる
• ターゲットからプロキシルートが遠すぎる
• ターゲットが疑わしいセッションを閉じる

タイムアウトの修正方法

接続タイムアウトを読み取りタイムアウトから分離することから始めます。確立できない接続は、遅いページ応答とは異なります。

推奨される修正：

• ターゲットに近い地域プロキシルートを使用
• 接続タイムアウトを短縮
• 現実的な読み取りタイムアウトを設定
• 繰り返し失敗した後に出口を回転
• ワーカーごとのオープン接続を制限
• p95レイテンシを監視
• 高失敗率のプロキシ出口を隔離

ブラウザの自動化の場合、ブラウザのクラッシュやナビゲーションタイムアウトも別々に監視してください。

TLSおよびSSLエラー

TLSエラーは、安全な接続のセットアップ中に発生します。

一般的な原因には以下が含まれます：

• SNIの不一致
• サポートされていないTLSバージョン
• 証明書の検証失敗
• 古いクライアントライブラリ
• ALPNの不一致
• 現代の暗号サポートを要求するターゲット
• 誤ったプロキシプロトコルを介して送信されたHTTPSリクエスト

TLSエラーの修正方法

リクエストが正しいホスト名とプロトコルを使用していることを確認します。必要に応じて、プロキシタイプがHTTPSトンネリングをサポートしていることを確認してください。

推奨されるチェック：

• SNIがターゲットホスト名と一致することを確認
• HTTPクライアントまたはブラウザランタイムを更新
• 現代のTLSバージョンを使用
• レガシー暗号設定を避ける
• 証明書検証の動作を確認
• 通常のブラウザリクエストと比較

TLSの動作もボット検出に寄与する可能性があります。User-AgentがChromeを主張しているが、TLSプロファイルがChromeに似ていない場合、ターゲットはセッションを信頼しない可能性があります。

ブラウザとクライアントの一貫性の問題については、Webスクレイピングのためのブラウザフィンガープリンティングを確認してください。

DNS解決エラー

DNSエラーは、ターゲットホスト名が解決できないか、正しく解決されていないことを意味します。

一般的な原因には以下が含まれます：

• 不良なDNSリゾルバ
• 地域DNSの不一致
• スプリットホライズンDNS
• ブロックされたDNSルート
• 古いキャッシュされたレコード
• IPv6/IPv4の不一致
• 期待されるリゾルバをバイパスするプロキシ

DNSエラーの修正方法

信頼できるリゾルバを使用し、リクエストを送信するのと同じランタイムからDNSの動作を検証します。

推奨される修正：

• ターゲットホスト名の解決を確認
• プロキシルートからテスト
• DNS地域をプロキシ地域と一致させる
• 古いDNSキャッシュをクリア
• レコードを一時的にのみ固定
• 地域ごとのDNS失敗を監視

地理的に敏感なワークフローでは、リゾルバの場所が返されるコンテンツに影響を与える可能性があるため、DNSが重要です。

CAPTCHAおよびインタースティシャルページ

CAPTCHAまたはインタースティシャルページは通常、ターゲットが摩擦を適用していることを意味します。

• 高リクエストレート
• 疑わしいIPの評判
• ブラウザフィンガープリンティングの不一致
• セッション履歴なし
• リトライが多すぎる
• 地理的不一致
• WebRTCまたはDNSリーク
• 異常なナビゲーション行動

CAPTCHAの頻度を減らす方法

目標は予防であり、回避ではありません。

推奨される修正:

• 同時接続数を減らす
• チャレンジ後にバックオフを追加する
• 適切な場合はスティッキーセッションを使用する
• プロキシの地域、タイムゾーン、言語を揃える
• セッションワークフローのためにクッキーを保持する
• ブラウザプロファイルの一貫性を検証する
• リトライストームを避ける
• 利用可能な場合は承認されたAPIまたはフィードを使用する

ほぼすべてのリクエストでCAPTCHAプロンプトが表示される場合は、無理に進めるのではなく、ワークフローを再評価してください。

WebRTC関連の問題については、WebRTCリーク: なぜそれがアンチデテクトセットアップを壊すのかを参照してください。

地理的不一致エラー

地理的不一致は、プロキシの位置、ブラウザの設定、ターゲットストアフロント、または返されたコンテンツが一致しないときに発生します。

例:

• プロキシがある国で出口しているが、コンテンツが別の国を示している
• 市レベルのSEO結果が間違った地域から来ている
• 価格が間違った通貨で表示される
• 配送オプションがターゲット地域と一致しない
• タイムゾーンがIPの位置と矛盾している
• クッキーが古い地域を保持している

地理的不一致を修正する方法

プロキシプロバイダーのラベルだけに頼らないでください。返されたコンテンツを検証してください。

確認する項目:

• 通貨
• 言語
• ローカルパックの住所
• 店舗の位置
• 配送地域
• ページURL
• 国のバナー
• ローカライズされたスニペット

ローカルSEOおよび地理特有のモニタリングには、住宅ルートがより信頼性が高いことが多いです。住宅プロキシを使用したローカルSEOモニタリングを参照してください。

ソフトブロック: プロキシエラーの見逃し

ソフトブロックとは、ページが正常に返されるが、コンテンツが無効である場合です。

例:

• CAPTCHAコンテンツを含むHTTP 200
• 価格がない商品ページ
• オーガニック結果が欠けているSERPページ
• 一般的なエラーテンプレート
• 空の在庫データ
• 間違った地域のページ
• プレースホルダーコンテンツ
• 繰り返し同一の応答

ソフトブロックは、実際のデータとしてダッシュボードに入る可能性があるため危険です。

ソフトブロックを検出する方法

成功をカウントする前に、コンテンツ構造を検証してください。

価格モニタリングの場合、確認する項目:

• 商品タイトル
• SKU
• 価格
• 通貨
• 在庫状況
• 地域

SEOモニタリングの場合、確認する項目:

• オーガニック結果の数
• ローカルパックデータ
• ターゲットロケーション
• 期待されるSERP機能

スクレイピングパイプラインの場合、必要なフィールドとスキーマルールを確認してください。

測定すべきこと

プロキシの信頼性は、生のリクエストではなく、有効な出力を通じて測定されるべきです。

これらをドメイン、ルート、プロキシタイプ、地域、ワークロードごとに追跡してください。

決定フレームワーク: 正しいレイヤーを修正する

トラブルシューティング時にこのパスを使用してください。

1. 認証エラー? 認証情報、ホワイトリスト、ポート、シークレットのローテーションを修正してください。

2. レート制限エラー? 同時接続数を減らし、ジッターを追加し、バックオフを適用してください。

3. ネットワークエラー? ルートの健康、タイムアウト、DNS、および地域のレイテンシを確認してください。

4. TLSまたはプロトコルエラー？ クライアントバージョン、SNI、ALPN、および証明書の動作を検証します。

5. ハードブロック？ プロキシタイプ、ヘッダー、ブラウザフィンガープリント、およびリクエストのタイミングを確認します。

6. ソフトブロック？ ページコンテンツとパーサーの期待を検証します。

7. ジオミスマッチ？ プロキシの場所、ブラウザのロケール、クッキー、およびターゲットストアフロントを整合させます。

これにより、トラブルシューティングが集中します。

実世界のシナリオ：Eコマース価格監視

価格チームは数千の製品ページを監視しています。システムは、突然の価格欠落の増加を報告します。

最初、チームは小売業者がレイアウトを変更したと仮定します。しかし、失敗サンプルは空の製品コンテナを持つHTTP 200レスポンスを示しています。この問題はソフトブロックです。

修正には以下が含まれます：

• 同時実行数を減らす
• 敏感な製品ページを住宅プロキシに切り替える
• 地域ストアフロントチェックのためにスティッキーセッションを使用する
• レコードを保存する前に価格と通貨を検証する
• パース失敗時にHTMLサンプルをキャプチャする

欠落した価格率が低下し、CPSRが改善されるのは、リトライが減少するためです。

実世界のシナリオ：SEOランク追跡

SEOプラットフォームは、数百の場所で市レベルのSERPを収集します。

レポートは不安定なローカルランキングを示しています。調査の結果、チームは一部のプロキシルートが正確なターゲット都市の結果ではなく、近隣都市の結果を返すことを発見しました。

修正には以下が含まれます：

• ローカルパックのアドレスを検証する
• ジオ精度フラグをログに記録する
• 住宅プロキシのルーティングを厳密にする
• Accept-Languageと検索パラメータを整合させる
• 広範な全国チェックをローカルチェックから分離する

その結果、クリーンなランキングデータと偽のランキング変更が減少します。

避けるべき一般的なミス

すべてのエラーを同じ方法でリトライする

407、429、タイムアウト、ソフトブロックは異なる応答を必要とします。

ソフトブロックを無視する

成功したステータスコードは、データが有効であることを意味しません。

IPを頻繁にローテーションする

過剰なローテーションはセッションの信頼とクッキーを壊す可能性があります。

プレミアムプロキシをどこでも使用する

有効な出力を改善する場所では住宅またはISPルートを使用します。耐性のあるページにはデータセンターのルートを維持します。

DNSとTLSを忘れる

ライブラリの更新やインフラの変更後にDNSとTLSの動作が変わることがあります。

計測前にスケーリングする

成功率、ブロック率、レイテンシ、およびCPSRが測定されるまでボリュームを増やさないでください。

ベストプラクティスチェックリスト

プロキシ駆動のワークフローをスケーリングする前に：

• 資格情報とプロキシエンドポイントの設定を確認します。
• エラーをタイプ別にセグメント化します。
• 成功率、ブロック率、ソフトブロック率、およびCPSRを追跡します。
• ドメインごとの同時実行制限を使用します。
• リトライ予算と指数バックオフを追加します。
• データを保存する前にコンテンツを検証します。
• マルチステップワークフローのためにスティッキーセッションを使用します。
• プロキシ地域をブラウザのロケールおよびターゲットストアフロントと整合させます。
• DNSおよびTLSの失敗を監視します。
• 不良プロキシ出口を隔離します。
• デバッグのために失敗サンプルを保存します。
• クライアントまたはブラウザの更新後に再テストします。

セットアップサポートについては、SquidProxiesの プロキシチュートリアル およびより広範な プロキシユースケース を確認してください。

よくある質問

最も一般的なプロキシエラーは何ですか？

最も一般的なプロキシエラーは、407認証エラー、403禁止レスポンス、401未認証レスポンス、429レート制限、502および504ゲートウェイエラー、TLSエラー、DNS失敗、接続タイムアウト、CAPTCHAページ、およびジオミスマッチです。

407 Proxy Authentication Requiredとはどういう意味ですか？

これは、認証が失敗したためにプロキシがリクエストを拒否したことを意味します。ユーザー名、パスワード、トークン、ポート、プロキシプロトコル、およびIP許可リストの設定を確認してください。

429 Too Many Requestsとはどういう意味ですか？

これは、ターゲットがトラフィックをレート制限していることを意味します。同時実行数を減らし、ジッターを追加し、バックオフを使用し、すぐにリトライしないようにします。

HTTP 200を受け取るが有用なデータがないのはなぜですか？

これはしばしばソフトブロック、パーサーの失敗、同意ページ、間違った地域のページ、またはJavaScriptレンダリングの問題です。成功をカウントする前にページ構造を検証してください。

プロキシのタイムアウトを減らすにはどうすればよいですか？

より健康的なルートを使用し、接続タイムアウトを短縮し、現実的な読み取りタイムアウトを設定し、バックオフを伴う再試行を行い、高い失敗率のプロキシ出口を隔離してください。

いつデータセンターのプロキシの代わりに住宅用プロキシを使用すべきですか？

地理的な正確性、消費者のようなネットワークアイデンティティ、またはブロック耐性が重要な場合は住宅用プロキシを使用してください。低摩擦で高ボリュームの公開ページにはデータセンターのプロキシを使用します。

プロキシが問題かどうかはどうやってわかりますか？

プロキシの種類、地域、通常のブラウザのベースラインで同じリクエストを比較してください。失敗が一つのルートまたはプールに従う場合、プロキシ層が関与している可能性が高いです。

どのメトリックを監視すべきですか？

成功率、ブロック率、ソフトブロック率、再試行の深さ、CPSR、p95レイテンシ、セッションの生存、地理的正確性、認証失敗、プロキシプールの健康を追跡してください。

最後の考え

ほとんどのプロキシエラーは、失敗している層を特定すれば修正可能です。認証エラーには資格情報の修正が必要です。レート制限にはペーシングが必要です。タイムアウトにはルートの健康チェックが必要です。TLSおよびDNSの失敗にはプロトコルの検証が必要です。ソフトブロックにはコンテンツの検証が必要です。地理的不一致にはより良いルーティングとロケールの調整が必要です。

最も強力なシステムは盲目的な再試行に依存しません。エラーを分類し、ターゲットを絞った修正を適用し、有効な出力が改善されるかどうかを測定します。

明確なメトリックから始め、小規模なパイロットで変更をテストし、成功率、地理的正確性、レイテンシ、およびCPSRが安定したときにのみスケールアップしてください。