SOCKSとHTTPプロキシ：違い、速度、プロトコルの選択

HTTPとSOCKSプロキシは、中間サーバーを介してアプリを接続先につなぎます。ブラウザー、スクレイパー、APIクライアントでは、CONNECT対応HTTPプロキシが実用的な出発点です。アプリがSOCKSを想定する場合、別のTCPプロトコルが必要な場合、UDP転送に対応する場合にはSOCKS5が役立ちます。どちらもHTTPSサイトへの通信を運べます。

プロトコルは、プログラムとプロキシの通信方法を決めます。出口IPの由来、ローテーション、共有か専用かは別の選択で、プロキシの種類と構成の選び方で説明しています。HTTPからSOCKSへ変えるだけで、これらの性質は変わりません。

HTTPとSOCKSの接続処理

HTTP転送：プロキシがウェブリクエストを処理

通常の非暗号化HTTPリクエストでは、クライアントがURL、メソッド、ヘッダーをプロキシに送ります。プロキシが処理し、接続先から応答を取得します。設定によりHTTPルール、ヘッダー変更、キャッシュを使えます。これらは可能な機能であり、サービスがすべて有効にしているとは限りません。

SOCKS5：アプリのために接続を開く

クライアントは認証方式を合意し、必要なら認証し、接続先アドレスとポートを指定します。プロキシが要求されたTCP接続を作り、アプリのバイト列を中継します。同じ仕組みでHTTPS、SSHなどの対応TCPアプリケーションプロトコルを運べます。HTTPリクエストを解釈せずに転送できます。

CONNECT経由のHTTPS：2つの方式が近づく

一般的なHTTPプロキシからHTTPSサイトを開くとき、通常クライアントはCONNECTを送ります。トンネルが許可されると、その中でサイトとのTLSを確立します。プロキシは暗号化データを中継します。SOCKS5も、自身の接続手順の後に同じTLS通信を中継できます。

速度とプライバシーの比較で重要なのは、HTTPSをトンネルで運ぶHTTPプロキシも、暗号化された各ページのリクエストを解析しない点です。どちらも保護された通信を中継します。順序と、HTTP転送とトンネルの違いはHTTP・HTTPSプロキシで説明しています。

HTTPとSOCKS5の概要

以下はSOCKS5を比較します。古いSOCKS4・SOCKS4aは機能が少なく、主に既存ソフトウェアで必要な場合に関係します。

HTTPとSOCKS5のどちらが速いか

HTTP CONNECTは通常、プロキシとのやり取りが少なく、新しいHTTPS接続を早く使える場合があります。以下でその前提を示します。トンネルが開けば、長いダウンロードや後続リクエストで再利用できます。持続的な転送速度に、一定の優劣はありません。

新規接続：やり取りの回数を数える

プロキシへのTCP接続が準備できた後から、各要求が応答を待つものとして準備メッセージを数えます。プロキシまでのTLS層は使いません。HTTP認証は不要か、最初のCONNECTに含めた認証情報で成功する前提です。

この前提では、SOCKS5は認証なしで1往復、標準のユーザー名・パスワード認証で2往復を、クライアントとプロキシ間に追加します。往復時間（RTT）はメッセージがプロキシへ届き、応答が戻るまでの時間です。例のRTTが50 msなら、追加分は約50または100 msです。プロトコルの順序からの推定で、サービスの実測性能やリクエスト全体の時間ではありません。

どちらも、プロキシから接続先への接続と、クライアントによるサイトのTLS確立が必要です。DNS時間、処理、混雑は異なり得ます。HTTP認証のチャレンジがあればやり取りが増え、HTTPSプロキシへのTLSにも準備が必要です。実構成の比較には、これらも含めます。

接続の再利用：最初の差が各リクエストに分散する

接続プールは、後のリクエスト用に適切な接続を保持します。HTTPS接続の再利用により、毎回TCP、プロキシ交渉、サイトのTLSハンドシェイクを繰り返さずに済みます。クライアントと接続先がHTTP/2に対応すれば、複数のリクエストストリームが1つの接続を共有できます。HTTP CONNECT内でもSOCKS5接続内でも可能で、プロキシはTLS内のHTTP/2メッセージを解析する必要がありません。

URLごとにHTTPクライアントオブジェクトを新規作成すると、接続プールを捨てる場合があります。ここでのクライアント再利用は、ソフトウェアのオブジェクトと接続を保持することであり、プロキシに出口IP維持を求めることではありません。同じホストへ繰り返すバッチでは、プロトコル変更より多くの準備を省ける場合があります。新しい接続先、閉じた接続、プロキシ設定変更では、新トンネルが必要になる場合があります。

大容量転送：使える帯域幅を見る

トンネル確立後の速度は、経路、パケット損失、利用可能な帯域幅、プロキシ負荷、サービス上限に左右されます。CONNECTでのHTTPS中継も、すでにバイト列を転送する作業です。「HTTPを読まないのでSOCKS5は速い」という説明は、このケースを見落としています。

非暗号化HTTPでは、設定されたキャッシュやコンテンツ処理が結果を変える場合があります。キャッシュ応答と、同じ内容を元サーバーから取る処理は、負荷が異なります。公平な比較では区別が必要です。

大規模なウェブスクリプトはどの方式を使うか

SOCKS5を使っても、ウェブスクリプトはHTTPリクエストを送ります。変わるのはサーバーへの到達方法です。ページ取得やHTTPS API呼び出しの新規スクリプトは、特別な要件がなければ、実績のあるHTTPクライアントとHTTP CONNECTから始めます。同じ要求ロジックでSOCKS5を試せるよう、プロキシは設定で選べる形にします。比較が重要なら、両方対応のライブラリを選んでください。

HTTPもSOCKS5も、非同期ソフトウェアで使えます。並行実行するかを決めるのはプロトコルではありません。選んだ方式で並行リクエストを使え、接続プールを保持し、進行中の操作数を制限できるかをライブラリで確認します。完了量とエラーを見ながら並行数を増やします。プロキシ、ネットワーク、接続先が限界に達すると、追加接続は待ち行列と再試行を増やす場合があります。

規模拡大前に速度を比較する方法

1. 同じプログラム、要求先、応答サイズ、並行数を使います。可能なら同じ出口IPと経路のプロトコル接続先を比較します。できなければ、出口地域とサービス上限を同程度に保ち、違いを記録します。
2. 新規接続を使う系列と、ウォームアップ後に通常のプールを使う系列を実行します。DNS動作、TLS保護、認証、HTTPバージョン、再試行方針を揃えるか、異なる理由を記録します。
3. 1秒あたりの成功完了操作数と、再試行を含むバッチ全体の時間を測定します。完了時間の中央値と95パーセンタイル、タイムアウト、失敗も記録します。95パーセンタイルは、測定操作の95%が完了する時間です。
4. ダウンロードでは、1秒あたりの受信した有用なバイト数を記録します。短いリクエストでは、接続準備、最初のバイトまでの時間、応答全体の時間を分けます。最初のバイトまでの時間には、接続先が応答を生成する待ち時間も含まれます。
5. 両構成を交互に繰り返し、予定のプロキシ経路を確認します。別の出口プールを使ったり直結にフォールバックしたりしたテストでは、プロトコルだけの影響を切り分けられません。

許容できるエラー率で、実際の仕事を早く終える構成を選びます。高速な認証失敗や不完全な応答は、有用なスループットではありません。同程度なら、選んだアプリで保守しやすいほうを優先します。

アプリの対応を最初に確認する理由

「プロキシ」という欄だけで、全プロトコル・認証への対応は保証されません。たとえばChrome内蔵のSOCKS5はTCPリクエストに対応しますが、SOCKS5のユーザー名・パスワード認証やUDP転送は実装していません。サービス側に機能があっても、未対応のブラウザー方式に使わせることはできません。

SSH、ファイル転送、その他のTCPアプリでは、ネイティブなSOCKS対応が便利です。HTTP CONNECTも、アプリがトンネルを作れ、プロキシが接続先ポートを許可すれば、ほかのTCPプロトコルを運べます。したがって、HTTPプロキシは必ずしもウェブ専用ではありません。

ブラウザー設定は、別のプログラムやブラウザーの全機能を自動的に覆うわけではありません。外部アダプターにも独自の範囲と制約があります。バージョンの違いと交渉は、SOCKS5・SOCKS4プロキシで説明しています。

接続先のホスト名を誰が解決するか

SOCKS5では、アプリがローカルで名前解決してIPを送るか、ホスト名を送りプロキシに解決させます。curlのsocks5://はローカルでの接続先解決、socks5h://はプロキシ側での解決を選びます。追加の文字はクライアント動作を選ぶもので、新しいSOCKSプロトコルではありません。

HTTPプロキシも、URLやCONNECTで受けた接続先名を解決できます。したがって、どちらもリモートDNS解決を使えます。プロキシ側の照会は別サーバーのアドレスを返す場合があり、対象のローカル照会を避けられます。ただし、クライアントはプロキシ自体のホスト名を解決する場合があり、他アプリのDNS設定は独立しています。プロトコル名から推測せず、クライアント側で動作を選びます。

どの接続が暗号化されるか

サイト内容の保護と、プロキシまでの接続保護を分けます。通常のHTTPSでは、どちらのトンネルでも、クライアントとサイト間のアプリデータが暗号化されます。正常な証明書検証と、TLS傍受を設定していないことが前提です。

HTTPSプロキシはクライアントとプロキシ間にTLSを加え、その区間の要求と認証情報を守ります。プロキシアドレス内のhttps://は通常、この保護を表します。単に「HTTPSサイト用プロキシ」とある設定は、CONNECT対応の通常のHTTPプロキシを意味する場合もあります。

通常のHTTPプロキシへのHTTP Basic認証情報と、標準SOCKS5のユーザー名・パスワード交換は、保護されない経路を観測する人に読まれます。後でサイトと作るTLSは、先のプロキシログインをさかのぼって守りません。この保護が必要なら、通常のSOCKS5には別の安全な転送路が必要です。

プロキシは自身のTLS接続の端点であり、要求された接続先を知っています。最終接続先が通常のHTTPなら、プロキシへのTLSはその先のHTTP接続を暗号化しません。同様に、SOCKSが内容を解析する必要がないからといって、平文が隠れるわけではありません。

UDPやHTTP/3で選択は変わるか

UDPが実際に必要なアプリ向けに、SOCKS5はUDP ASSOCIATEを定義しています。両端の実装と、データグラムを運べる経路が必要です。通常のHTTP CONNECTはTCPトンネルです。CONNECT-UDPなどの追加方式でHTTPによるUDP転送もできますが、両端の実装が必要です。

HTTP/3はUDP上のQUICを使います。HTTPSページが開いても、HTTP/3の動作証明にはなりません。TCP上のHTTP/2やHTTP/1.1を使った可能性があります。ウェブスクリプトにはその代替で足りても、データグラム必須の機能のUDPは代替できません。経路と制約はプロキシ経由のUDPとQUICをご覧ください。

SOCKSのほうがクライアントを隠せるか

非暗号化HTTP転送では、元のクライアント情報を含むForwardedなどのヘッダーを追加できます。通常のHTTPS CONNECTでは、サイトのTLSを終端しない限り、そのヘッダーを暗号化要求に挿入できません。SOCKS5もHTTPヘッダーを自動追加しません。

どちらの方式も、匿名性やサイトへのアクセスの保証にはなりません。運営者は接続メタデータを、接続先はアカウント、Cookie、アプリ動作を認識できます。出口IPの評判と共有人数は別の要素です。同じサービスでHTTPからSOCKSに変えても、自動でブロック解除やサイトセッションのリセットはされません。

最終的な選び方

最初にアプリの対応プロトコルとアクセス方式を確認します。一般的なウェブ自動化はHTTP CONNECTが適切な最初の候補です。SOCKS前提のアプリや対応UDP方式にはSOCKS5が適する場合があります。必要なDNS動作とプロキシまでの保護を選び、実際の負荷で性能を比較します。

選択プロトコル用の実際のホスト名とポートを使います。設定のhttp://をsocks5://に変えても、未対応サーバーでSOCKSは有効になりません。規模拡大前に、予定のプロキシから要求が出ることと、失敗時に意図しない直結が密かに使われないことを確認します。