SOCKS5プロキシのプールを購入し、Dolphin AntyやAdsPowerにデータを入力したが、プロファイルが開かず、パーサーがタイムアウトを出し、モバイルアプリは接続を全く認識しない。これはプロキシの欠陥でも設定ミスでもない。これはSOCKS5プロトコル自体の特性であり、プロキシの販売者は支払い前にほとんど説明しない。すべての7つの制限を順に解説し、それぞれにどう対処するかを見ていきます。
SOCKS5とは何か、なぜHTTPよりも選ばれるのか
SOCKS5は、クライアントとサーバー間でトラフィックパケットを単に転送する低レベルのプロキシプロトコルであり、その内容には立ち入らない。HTTP/HTTPSプロキシとは異なり、特定のアプリケーションプロトコルに依存せず、ブラウザトラフィックだけでなく、トレント、メールクライアント、ゲーム接続、デスクトップアプリケーションのトラフィックも流すことができる。これがSOCKS5がマルチアカウント、パーシング、Telegramボットでの作業に広く販売される理由である。 問題は、「汎用性」がSOCKS5の最大の弱点でもあることだ。プロトコルは、アプリケーションレベルではなく、トランスポート接続レベル（TCP/UDP）で機能する。パケット内に何があるか、HTTPリクエスト、DNS解決、WebRTCハンドシェイクを理解しない。そのため、プロキシの特定の動作を期待するソフト（例えば、アンチデテクトブラウザやモバイルアプリのSDK）は不安定に動作し、どこかでトラフィックがプロキシをバイパスし、どこかで接続が切れ、どこかではアプリケーションがプロキシサーバーを認識しない。
以下は、理論ではなく、アービトラージャー、SMM専門家、マーケットプレイスのセラーがSOCKS5プールを支払った後に直面する具体的な状況である。
制限1：SOCKS5はHTTPヘッダーを転送しない
HTTPプロキシはリクエストヘッダーを修正できる — X-Forwarded-Forを挿入または隠すことができ、ネットワークレベルでUser-Agentを変更することができる。SOCKS5はこれを全く行わず、単にバイトを転送する。アンチデテクトブラウザ（Dolphin Anty、AdsPower、Multilogin、GoLogin）にとってはそれほど重要ではない。なぜなら、User-Agentやその他のフィンガープリンティングをブラウザエンジンレベルで自分たちで行うからだ。しかし、独自のスクリプトパーサーや単純なパーサースクリプトを使用している場合、プロキシが自動的にヘッダーをクリーンアップすることを期待していると、実際のネットワークフィンガープリンティングが漏れることになる。
実際には、サイトはプロキシのIPアドレスと接続ヘッダーに送信されるデータ（例えば、オペレーティングシステムのタイムゾーンやシステムの言語）との不一致を認識する。Wildberries、Ozon、Facebook Adsにとっては、これはアカウントの追加確認のトリガーの一つである。
制限2：DNSリクエストがプロキシをバイパスする
これは、SOCKS5を購入した後の「奇妙な」動作の最も一般的な理由かもしれない。多くのプログラムは、デフォルトでドメインをローカルでIPアドレスに解決し、プロバイダーのDNSサーバーを介してTCP接続をプロキシを通じて送信する。その結果、プロキシサーバーは物理的にドイツにあるが、DNSリクエストはロシアのローカルDNSに対してfacebook.comのIPを尋ねる。サイトやアンチフロードシステムは、IPのジオロケーションとDNSリゾルバーの非同期を認識し、これはブロックまたは追加の検証の直接的な信号となる。
解決策は、プロキシを介したDNS解決を強制的に有効にすること（Proxy DNSまたはRemote DNSオプション）。アンチデテクトブラウザでは、この設定は通常、プロファイルの「詳細」セクションに隠されており、デフォルトではオフになっていることがあるため、新しいプロファイルごとに手動で確認する必要がある。
制限3：WebRTCがプロキシを貫通する
WebRTCは、ブラウザでのビデオ通話やストリーミングのための技術であり、デバイス間で直接P2P接続を確立する。問題は、WebRTCがシステム内のSOCKS5プロキシ設定を完全に無視し、STUNサーバーを介して実際の外部IPアドレスを直接公開することである。これは、プロキシが有効になっているブラウザでも、WebRTCが別途無効にされていない限り発生する。
InstagramやTikTokのアカウントを数十個管理しているSMM専門家にとって、この漏洩は特に危険である：プラットフォームは、15の「異なる」アカウントが実際にはWebRTC漏洩を介して1つの実際のIPから出ていることを瞬時に認識する。各プロファイルに異なるプロキシがあってもだ。プロフェッショナルなアンチデテクトブラウザは、デフォルトでWebRTCをブロックするか、プロキシのIPに置き換えるが、手動でSOCKS5をシステム設定を通じて設定している通常のChromeを使用している場合、WebRTCは100％の確率で漏洩する。
制限4：すべてのソフトがSOCKS5を完全にサポートしているわけではない
多くのデスクトップおよびモバイルアプリは「プロキシ」をサポートしていると主張しているが、実際にはHTTP/HTTPSトンネリングのみを実装しており、SOCKS5は形式的に追加されているか、全く追加されていないことがある。これは、一部のマーケットプレイスのパーサー、古いバージョンのTelegramボット、および一部のソーシャルメディアへの自動投稿サービスに関係している。このようなプログラムでは、SOCKS5用のフィールドがインターフェースに存在することがあるが、接続時にタイムアウトエラーが発生するか、接続が「通らない」ことがある。
特定のソフトウェア用にSOCKS5プールを購入する前に、文書やサービスのサポートに確認して、SOCKS5のバージョン（SOCKS4ではなく、認証やUDPに関する制限がある）を完全にサポートしていることを確認する必要がある。
制限5：認証はどこでも同じではない
SOCKS5は、IP（ホワイトリスト）とユーザー名・パスワードによる2つの認証方法をサポートしている。問題は、一部のソフトウェア、特にモバイルアプリやSDKが、これらの方法のうちの1つでしか動作せず、時にはAndroidやiOSのプロキシ設定レベルでユーザー名・パスワードによる認証を全くサポートしていないことがある。プロキシプールがユーザー名・パスワード専用に設定されている場合、アプリがIPによるホワイトリストを期待していると、接続は確立されず、エラーは非常に非情報的なものになる（「サーバーに接続できませんでした」）。
さらに、一部のプロバイダーでは、IPによる認証が作業用コンピュータやサーバーの静的外部アドレスを必要とし、異なるネットワーク（自宅/オフィス/カフェ）を介してノートパソコンで作業する場合は不便である。IPは毎回変わり、ホワイトリストを手動で更新する必要がある。
制限6：同時接続の制限
SOCKS5プロキシ、特にデータセンターのものは、1つのポートからの同時TCPセッションの数に制限があることが多い。1つのブラウザプロファイルでは目立たないが、同じプロキシを介してWildberriesやOzonのカードをマルチスレッドでクロールする場合、接続の制限が明示的なエラーなしに一部のリクエストを切断することがある — 単に一部のページが読み込まれず、スクリプトが応答を待ってハングすることになる。
これは、価格の高負荷パーサーを使用する際に特に重要である：1つのSOCKS5ポートを介して50のスレッドを計画していたが、実際の制限が10である場合、パーシング速度は5倍に低下し、競合の価格監視が数時間遅れることがわかる。
制限7：モバイルSDKとアンチフロードシステム
多くのモバイルアプリ（マーケットプレイスやソーシャルメディアのアプリを含む）は、OSレベルのプロキシ設定をバイパスし、独自のネットワークスタックを介してサーバーに直接接続する組み込みSDKを使用している。AndroidやiOSのシステム設定で設定されたSOCKS5は、ブラウザや一部のシステムアプリケーションのトラフィックのみをカバーし、サードパーティアプリケーションのトラフィック全体を保証するものではない。
そのため、モバイルアプリ（Instagram、TikTok、Wildberries Seller）が完全に機能するためには、OSレベルのSOCKS5ではなく、特化したモバイルプロキシを使用することが一般的であり、これは携帯電話のキャリアを介してインターネットに接続することをエミュレートし、プラットフォームのすべてのアンチフロードメカニズム（ネットワークの種類（Wi-Fi/LTE）やキャリアの確認を含む）と正しく機能する。
購入前にSOCKS5を確認する方法
特定のタスクのために50-100ポートのプロキシプールを購入する前に、実際の使用シナリオで1つまたは2つのプロキシをテストすることが重要である。以下は、確認のための最小限のチェックリストである：
- IPおよびDNSリークを確認するサービスを介してDNS解決を確認 — ジオロケーションは両方のケースで一致する必要がある。
- プロキシを有効にしたブラウザでWebRTCリーク確認のテストページを開く — 実際のIPは表示されるべきではない。
- このプロキシを使用して必要なソフト（アンチデテクトブラウザ、パーサー、ボット）を実行する — 一部の制限は特定のアプリケーションレベルでのみ現れる。
- プロバイダーに認証の種類（ユーザー名・パスワードまたはIPホワイトリスト）とポートの同時接続の制限を確認する。
- マルチスレッドパーシングを計画している場合は、複数の並行スレッドでの速度と安定性を確認する。
この確認には15-20分かかるが、特定のソフトに対して機能しない可能性のあるプロキシプールの購入にかかる予算を節約することができる。
SOCKS5の代わりに何を選ぶべきか：オプションの比較
SOCKS5は悪いプロトコルではないが、すべてのタスクに対して汎用的ではない。どのソフトウェアを使用しているかによって、他のタイプのプロキシや組み合わせを選択する方が理にかなっている。
| タスク | 推奨されるプロキシタイプ | 理由 |
|---|---|---|
| Facebook Ads、TikTok Adsのマルチアカウント | レジデンシャルプロキシ | 実際の家庭ユーザーのIP、低い自動ブロック率 |
| Instagram、TikTokのアカウント管理、モバイルSDK | モバイルプロキシ | キャリアのネットワークタイプに合致し、モバイルアプリのアンチフロードを通過する |
| Wildberries、Ozonの大量パーシング（匿名性に厳しい要件なし） | データセンタープロキシ | 高速、低価格、簡単な監視タスクに適している |
| トレント、メールクライアント、ウェブ特有のないカスタムソフト | SOCKS5 | HTTP特有に依存しない汎用プロトコル |
注意：プロトコル（HTTP/HTTPSまたはSOCKS5）とIPタイプ（レジデンシャル、モバイル、データセンター）は異なるパラメータである。信頼できるプロバイダーのレジデンシャルおよびモバイルプロキシは通常、両方のプロトコルをサポートしているため、「SOCKS5またはレジデンシャル」という質問ではなく、「タスクに必要なIPタイプ + 私のソフトがサポートするプロトコルは何か」ということになる。
結論
SOCKS5は機能するプロトコルだが、すべてのソフトウェアに対する「魔法の薬」ではない。購入後の問題の大部分は、プロキシの欠陥ではなく、プロトコルがアプリケーションレベルでのタスクを解決しないことに関連している：ヘッダーを置き換えず、プロキシを介したDNS解決を保証せず、WebRTC漏洩をブロックせず、モバイルSDKで常にサポートされるわけではない。プロキシプールを購入する前に、常に特定のシナリオを自分のソフトでテストし、抽象的なIP確認ではなく、具体的なシナリオを確認してください。
あなたのタスクが広告管理やソーシャルメディアのアカウント管理であるなら、レジデンシャルプロキシに注目してください — これは実際のIPアドレスによってDNSやヘッダーの問題を解決します。モバイルアプリやSDKで作業する場合は、最初からモバイルプロキシを使用する方が理にかなっており、厳しい匿名性の要件がない大量パーシングには、高速で手頃なデータセンタープロキシを使用するのが良いでしょう。