プロキシを通じてFacebook Adsを開こうとしたら、ダッシュボードの代わりに502コードの白い画面が表示される。あるいは、Wildberriesのパーサーが突然、5分ごとに503エラーを出す。最初の考えは「プロキシが壊れた、プールを変更する時だ」。しかし、半分のケースでは問題はプロキシではなく、サイト側にあり、IPを変更しても何も解決しない。数分で問題の原因を正確に特定し、動作しているプロキシを無駄に探す時間を浪費しない方法を見ていきましょう。
502および503コードの意味
プロキシを非難する前に、これらのコードはHTTPプロトコル自体が報告するものであり、あなたがアクセスしているサーバー側の問題を示していることを理解する必要があります。 502 Bad Gatewayは、中間サーバー（例えば、ロードバランサーやCloudflareのようなCDN）が上位サーバーから不正な応答を受け取ったことを意味します。簡単に言えば、あなたと最終アプリケーションの間のリンクが壊れているか、過負荷になっています。
503 Service Unavailableは、サーバーが一時的にリクエストを処理できないことを示しています。最も一般的な理由は、過負荷、メンテナンス、またはボットからの保護が作動したためです。重要なポイントは、503は一時的な利用不可であり、サーバーは生きていて、ただ今は応答する準備ができていないということです。
一見すると、両方のコードは明確に「サーバーに問題がある」と言っています。しかし、プロキシを使用する場合、状況は複雑になります。プロキシサーバー自体が502を生成する「中間リンク」となる可能性があり、ターゲットサイトにアクセスできない場合があります。また、503は、サイトが実際にダウンしているのではなく、保護システム（Cloudflare、Akamai、DataDome）がプロキシのIPを疑わしいと認識し、実際のページの代わりに503または429のコードを持つダミーページを返すことがよくあります。
プロキシを通じてこれらのエラーが頻繁に発生する理由
プロキシなしでサイトが安定して開く場合、プロキシを通じて502または503が頻繁に発生する理由は通常いくつかあり、すべてはプロキシがリクエストのチェーンにどのように組み込まれているかに関連しています。
プロキシサーバー自体の過負荷。 安価なデータセンターのプロキシでは、1つのIPに対して同時に多くのセッションが「ぶら下がっている」ことがあります。プロキシがトラフィックをプロキシするのが追いつかないと、接続を切断するか、自身の名前で502を返します。
ターゲットサイト側でのIPのブロック。 Facebook Ads、Instagram、Wildberries、Ozonは、データセンターのIPの範囲を一括で禁止するボット対策システムを積極的に使用しています。この場合、サイトは形式的には機能していますが、特定のIPに対しては503またはCAPTCHAへのリダイレクトを返します。
地理的な不一致。 プロキシがある国からで、アカウントが別の地域に関連付けられている場合、一部のサービスはセッションを一時的に「保留」し、アクセス拒否の代わりにゲートウェイエラーを返します。
プロトコルとポート。 アンチデテクトブラウザの設定でプロキシのタイプ（HTTPではなくSOCKS5、またはその逆）が誤って指定されている場合も、502に偽装されることがよくあります。ブラウザは物理的にトンネルを確立できず、ゲートウェイエラーを表示します。
クイックチェック：プロキシかサイトか
問題を解決する最も信頼性の高い方法は、変数を一つずつ排除することです。以下は、5分もかからない手順です。
ステップ1。 プロキシなしで、実際のIPから直接同じサイトを開きます。エラーが再発する場合、問題は確実にサイト側にあり、プロキシは関係ありません。
ステップ2。 プロキシなしで全てが正常に動作する場合、同じプールから別のIPにプロキシを変更します。エラーが消えた場合、特定のIPが禁止されたか過負荷になっていることが原因であり、サービス全体ではありません。
ステップ3。 同じプロキシを別のサイトでチェックします（例えば、httpbin.orgやwhatismyipのような中立的なリソースを開きます）。プロキシが全く何も開けない場合、問題はプロキシサーバー自体にあり、ターゲットサイトにはありません。
ステップ4。 プロキシが他のサイトを正常に開くが、特定のリソースで安定して503が発生する場合、これはほぼ常にボットからの保護によるもので、特定のIPが疑わしいと見なされています。このような場合、プロキシのタイプを変更することが役立ちますが、単に同じプール内でのローテーションではありません。
Dolphin Anty、AdsPower、Multiloginでの診断
アンチデテクトブラウザを通じてアカウントを運営している場合、診断はブラウザ内で直接行う方が便利です。
Dolphin Antyでは、プロファイルを開き、プロキシ設定に移動し、接続テストボタンをクリックします。テストが「プロキシが応答しない」またはタイムアウトを示す場合、問題はプロキシサーバーレベルにあり、ブラウザでの502エラーはその論理的な結果です。テストが成功し、プロファイル内のサイトが502または503を返す場合、応答コードを記録し、隣のタブで別のプロファイルの別のIPで同じURLを開きます。これにより、システムの問題かローカルの問題かがわかります。
AdsPowerでは、同様の機能が「Proxy check」と呼ばれ、応答速度と地理的位置も表示されます。プロキシの地理的位置が期待されるものと一致しない場合（例えば、アメリカのプロキシを購入したが、サービスがオランダを表示する場合）、これは置き換えや不適切な設定の疑いがあり、これもゲートウェイエラーを引き起こす可能性があります。
MultiloginおよびGoLoginでは、プロキシのチェックがプロファイル作成時の別のダイアログに分かれています。キャンペーンを開始する前に毎回使用してください。特に新しいアカウントを大量に作成している場合、5秒のチェックで502の原因を解明するのに1時間を無駄にすることを避けられます。
技術的な方法：curlを通じたチェック
パーシングやプログラムでプロキシを設定している方には、最も正確な診断方法はターミナルを通じた直接リクエストです。これにより、ブラウザの「装飾」なしで実際の応答コードを確認できます。
curl -x http://login:password@proxy_ip:port -I https://example.com -v
フラグ-Iはヘッダーのみを要求し、-vは詳細な出力を有効にします。これにより、どの段階で接続が切れたかがわかります—プロキシへのトンネルの確立時か、ターゲットサーバーへのリクエスト時か。
プロキシに接続する際にすぐにエラーが発生する場合（Connection refusedやConnection timed out）、問題はプロキシサーバー自体にあります。トンネルが確立されたが、ターゲットドメインから502または503のコードで応答が返された場合、問題はサイト側またはそのボット保護にあります。
プールから10個のプロキシをスクリプトで通過させ、応答コードの統計を収集することが役立ちます。これにより、プール全体にシステム的な問題があるのか、いくつかの「古くなった」IPが原因なのかがすぐにわかります：
for proxy in $(cat proxies.txt); do
code=$(curl -x "$proxy" -o /dev/null -s -w "%{http_code}" https://example.com)
echo "$proxy -> $code"
doneプール内のプロキシの30％以上が異なるサイトで502を返す場合、問題はプロバイダーまたはインフラ自体にあり、プール全体を変更する必要があります。特定のドメインでのみエラーが発生する場合、そのサイトのボット対策が原因です。
表：プロキシタイプ別のエラー原因
異なるタイプのプロキシは502および503エラーに対して異なる影響を受けるため、特定のタスクに合わせて選択する際に考慮することが重要です。
| プロキシタイプ | 502/503の一般的な原因 | エラーの頻度 |
|---|---|---|
| データセンターのプロキシ | ボット対策システムによるIP範囲の大量禁止、共用サーバーの過負荷 | 高い |
| レジデンシャルプロキシ | 時々、IPの供給元デバイスの不安定な接続 | 低い |
| モバイルプロキシ | セッション中にプロバイダーによるIPの変更、一時的な信号の途切れ | 中程度だが短期間 |
データセンターのIPは、ボット対策システムに事前に知られることが多いため、Facebook Ads、Instagram、マーケットプレイスのようなプラットフォームで503エラーの割合が最も高くなります。レジデンシャルおよびモバイルIPは、保護システムにとって通常のユーザーのように見えるため、誤検知の割合はかなり低いですが、ゼロではありません。
エラーの数を減らす方法
Facebook AdsやTikTok Adsの広告アカウントを運営するアービトラージャーにとって、IPがボット対策システムのブラックリストに載らないことが重要です。これが最も頻繁に503コードを引き起こします。このようなタスクでは、レジデンシャルプロキシはデータセンターのプロキシよりもはるかに安定しており、IPが実際のプロバイダーに属しているため、保護システムに疑われることが少なくなります。
InstagramやTikTokを複数のアンチデテクトプロファイルで同時に運営するSMMスペシャリストにとって、502の原因は同じIPに対するセッションの過負荷であることがよくあります。解決策は、各アカウントにユニークなIPを割り当て、プール内のアドレスの数を減らさないことです。
Wildberries、Ozon、Avitoの価格を監視しているセラーにとって、503は通常、サイトの保護が頻繁な同一リクエストのパターンを認識したことを意味します。この場合、プロキシのタイプを変更するだけでなく、リクエストの頻度を下げ、リクエスト間にランダムな遅延を追加し、新しいリクエストごとにIPをローテーションすることが役立ちます。
パーシングや自動化されたスクリプトの場合、大量のリクエスト時に接続の速度と安定性が重要であり、データセンターのプロキシは価格と速度の観点から合理的な選択ですが、負荷を多くのIPに均等に分散させて、1つのアドレスの制限に達しないようにすることが重要です。
診断チェックリスト
この手順を保存し、プロキシを通じて502または503が発生するたびに実行してください：
- プロキシなしでサイトを開く — エラーが再発するか。
- プロキシの接続を別々に確認する（whatismyip、httpbin）。
- 同じプール内でIPを変更し、リクエストを繰り返す。
- プロファイル設定でプロキシのタイプとポートを確認する（HTTP/SOCKS5）。
- curlを通じていくつかのIPを通過させ、応答コードを比較する。
- アカウントの関連付けに対するプロキシの地理的位置が変更されていないか確認する。
- エラーが特定のサイトでのみ再発する場合は、リクエストの頻度を下げる。
- プール全体でエラーが大量に発生する場合は、プロバイダーまたはプロキシのタイプを変更する。
結論
502および503コードは、プロキシをすぐに放棄する理由ではありません。ほとんどの場合、5分の診断で、問題がプロキシサーバー自体、ターゲットサイト、またはそのボット保護システムのいずれにあるかを理解することができます。プロキシなしでの確認、プール内でのIPの変更、curlやDolphin Anty、AdsPowerのようなアンチデテクトブラウザの組み込みツールを使用することで、余計な推測なしに90％の問題を解決できます。
原因が設定にあるのではなく、あなたのIPがボット対策システムのブラックリストに定期的に載っている場合は、タスクに応じてプロキシのタイプを見直す必要があります。広告アカウントのファーミングやソーシャルメディアの運営には、レジデンシャルプロキシが理にかなっています。これらは、サイトの保護システムに疑われることが少ないです。大量のリクエスト時に速度が重要なタスクには、データセンターのプロキシが適しており、モバイルアプリでの自然な動作が求められる場合には、モバイルプロキシが適しています。