HTTPプロキシとSOCKS5は、サーバーの手前でIPアドレスを差し替えるという同じ目的を持ちながら、ネットワークスタックの異なる層で動作します。そこから他のすべてが導き出されます。どのトラフィックを通すのか、何を見て何を変更できるのか、DNSやUDPをどう扱うのか、そしてどのソフトウェアと互換性があるのか。速度は、一般に言われるほど違いません。以下では両プロトコルを解説し、違いを表にまとめ、10件中9件をカバーする選択ルールを示します。
要点
- HTTPプロキシはHTTPを理解します。リクエストを読み、どこへ向かうのかを把握し、ヘッダーを追加したり、レスポンスをキャッシュしたり、アドレスをブロックしたりできます。HTTPSは
CONNECTコマンドでブラインド転送します。非HTTPトラフィックは対象外です。 - SOCKS5は何も理解せず、理解しようともしません。短いハンドシェイクの後、双方向にバイトを転送するだけです。任意のプロトコルのTCP、必要に応じてUDPも通します。中身は何でも構いません。Webサイト、メール、Telegram、ゲーム、トレントなど。
- どちらもトラフィックを暗号化しません。データ保護は内側のプロトコル(HTTPS、TLS)の役割であり、プロキシの役割ではありません。
それぞれが動作する層
HTTPプロキシはアプリケーション層で動作します。クライアントは通常のHTTPリクエストを送りますが、最初の行に完全なアドレスが含まれます(GET http://example.com/page HTTP/1.1)。プロキシはサーバーへの接続を自ら開き、レスポンスを受け取り、クライアントに返します。すべての内容が平文で通過し、プロキシはそれを変更する権限を持ちます。
HTTPSの場合は仕組みが異なります。クライアントはCONNECT example.com:443コマンドでプロキシにトンネル確立を要求し、プロキシは2つのソケットを接続し、その後は暗号化されたバイトを転送するだけです。プロキシはホスト名とポートは見えますが、パス、ヘッダー、リクエストボディは見えません。
SOCKS5(RFC 1928)はより低層、トランスポート層とアプリケーション層の間に位置します。クライアントは認証方式についてプロキシと合意し、宛先アドレス(IPv4、IPv6、またはドメイン名)とポートを伝え、プロキシが接続を開き、それ以降は透過的なパイプとなります。内部のプロトコルを知らないため、あらゆるプロトコルで動作します。基礎から確認したい場合は、プロキシサーバーとは何かの記事から始めてください。
HTTPプロキシの仕組み
プロトコルを理解しているからできること
- キャッシュ。同じリソースへの再リクエストがサーバーに届かないことがあります。企業やプロバイダのプロキシはこう動作します。
- URLによるフィルタリング。プロキシはアドレスを見て、ブロックしたり、トラッカーを除去したり、リダイレクトしたりできます。
- ヘッダーの変更。
Via、X-Forwarded-For、Forwarded(RFC 7239)を追加でき、それによってあなたの実IPを露呈させます。不要なものを削除することもできます。 - 認証。ユーザー名とパスワードは
Proxy-Authorizationヘッダーで送信され、多くの場合Basicスキーム、つまりBase64エンコードで暗号化なしです。保護されていないチャネルでは見えてしまいます。
できないこと
HTTP以外のすべてです。メールプロトコル、SSH、ゲームサーバー、トレントクライアント、VoIPは、HTTPプロキシ経由ではまったく動作しないか、プログラムがCONNECTで接続をラップでき、プロキシが任意のポートへのトンネルを許可している必要があります。多くのプロキシはCONNECTをポート443のみに許可しています。
3段階の匿名性
ヘッダーの扱いから、HTTPプロキシは伝統的に3クラスに分類されます。透過型はX-Forwarded-Forに実IPを渡し、Viaで自身を正直に通知します。匿名型はアドレスを隠しますが、プロキシに関するヘッダーは残すため、サーバーは仲介者がいることを認識します。エリート型は何も追加せず、通常のクライアントに見えます。SOCKS5にはこの分類がありません。ヘッダーにアクセスできず、定義上何も追加しないからです。
SOCKS5の仕組み
ハンドシェイク
接続は、クライアントがサポートする認証方式を列挙し、サーバーが1つを選択することから始まります。認証なし、ユーザー名とパスワード(RFC 1929)、またはGSS-APIです。次にクライアントはコマンド、アドレスタイプ、ポートを含むリクエストを送信します。コマンドは3つあります。CONNECTは通常の送信TCP接続、BINDは着信接続の受け入れ(アクティブFTPなどで必要)、UDP ASSOCIATEはUDPデータグラムのリレーを開きます。
リモートDNS
SOCKS4との決定的な違いは、宛先アドレスをドメイン名で渡せることです。その場合、名前解決はあなたのコンピュータではなくプロキシが行います。curlやPythonではこの違いがURLスキームに反映されています。socks5://はローカルで名前解決し、socks5h://はプロキシ側で解決します。前者はDNSクエリをプロバイダに残し、後者はトラフィックとともに持ち去ります。アドレスを隠すことが重要なタスクにはsocks5hが必要です。
UDP
UDP ASSOCIATEを通じて、TCPが適さないものが流れます。メッセンジャーの音声・ビデオ通話、DNS、一部のゲームプロトコル、QUICなどです。実際には、SOCKS5経由のUDPをサポートするサーバーとクライアントはすべてではないため、そのような用途でプロキシを購入する前に個別に確認する必要があります。
暗号化なしのパスワード
SOCKS5のユーザー名とパスワード(RFC 1929方式)は、HTTP Basicと同様に平文で送信されます。プロキシまでのチャネル自体はどちらも保護されておらず、接続内のTLSだけがトラフィックを保護します。プロバイダがIP認証を提供している場合、それは同程度に安全で、プログラムのログにパスワードを残しません。
主な違いを1つの表に
| 基準 | HTTPプロキシ | SOCKS5 |
|---|---|---|
| 層 | アプリケーション層(HTTPを理解) | セッション層(バイトを転送) |
| トラフィック | HTTP、HTTPSはCONNECT経由 | 任意のTCP、オプションでUDP |
| 内容の可視性 | HTTPは可、HTTPSはホストのみ | 宛先アドレスのみ |
| リクエストの変更 | 可(ヘッダー、キャッシュ、フィルター) | 不可 |
| DNS解決 | プロキシ側 | プロキシ側(socks5h)またはローカル(socks5) |
| 暗号化 | なし(HTTPS内部のみ) | なし(内部プロトコルのみ) |
| 認証 | Proxy-Authorization、Basic | ユーザー名とパスワード(RFC 1929)、GSS-API、認証なし |
| ソフトウェア対応 | ほぼどこでも | 広いが普遍的ではない |
| オーバーヘッド | ヘッダーの解析 | 最小限 |
速度:違いが探される場所にはない理由
SOCKS5はヘッダーを解析せず、レスポンスをバッファリングしないため、理論上は各リクエストでマイクロ秒を節約します。プロキシまでのネットワーク遅延、プロキシからサーバーまでの遅延に比べれば、これは識別できません。実際の速度を決めるのは4つです。プロキシサーバーまでの距離とそこからターゲットまでの距離、IPアドレスの種類(モバイルとレジデンシャル回線はデータセンターより遅い。詳細はプロキシの種類の記事を参照)、特定サーバーの負荷、そして並行して開く接続数です。このリストにプロトコルはありません。
HTTPプロキシが明らかに速い唯一のケースは、繰り返しコンテンツに対するキャッシュプロキシです。SOCKS5が明らかに速い唯一のケースは、HTTPプロキシではそもそも通らないトラフィックです。
匿名性とリーク
プロキシ経由でのアドレスリークは「プロトコルのせい」ではなく、具体的なメカニズムによるもので、それぞれ原因が異なります。
- ヘッダー。透過型HTTPプロキシは
X-Forwarded-Forに実IPを渡します。エリートプロキシを選べば解決します。SOCKS5にはこのリーク経路がありません。 - DNS。名前がローカルで解決される場合、プロバイダはあなたのアクセス先を見ています。HTTPプロキシと
socks5hはプロキシ側で解決し、socks5はそうしません。 - WebRTC。ブラウザはSTUN経由でローカルおよび外部アドレスを、あらゆるプロキシを迂回して露呈する可能性があります。これはプロキシではなくブラウザの特性であり、設定や拡張機能で塞げます。
- プロキシを迂回するトラフィック。プロキシはアプリケーション単位で設定します。設定していないもの(システム更新、別のブラウザ、メッセンジャー)は直接送信されます。デバイス全体をカバーする必要がある場合はVPNの役割です。プロキシ対VPN対Torを参照してください。
ソフトウェア互換性
- ブラウザ。ChromeとEdgeはシステム設定からプロキシを取得し、両タイプを理解します。Firefoxは独自の設定を持ち、「SOCKS5でDNSをプロキシする」を別のチェックボックスで設定できます。
- curl。HTTPは
curl -x http://user:pass@host:port、リモートDNS付きSOCKS5はcurl -x socks5h://user:pass@host:portです。 - Python。
requestsとhttpxではHTTPプロキシはすぐに動作し、SOCKS5は追加パッケージのインストール後です。socks5h://スキームも同様に解決をプロキシに切り替えます。 - Telegram、Discord、トレントクライアント、ゲーム。原則としてSOCKS5のみです。これらのトラフィックはHTTPではありません。
- アンチディテクトブラウザとパーサー。両方をサポートします。モバイルやレジデンシャルプロキシのプロバイダは、同じポートを両プロトコルで提供することがよくあります。
- SSH。
ssh -D 1080 user@serverは、アクセス権のある任意のサーバー経由でローカルSOCKS5プロキシを立ち上げます。プログラムがSOCKS5でどう動作するかを確認する便利な方法です。
どちらを選ぶべきか
| タスク | 選択 | 理由 |
|---|---|---|
| ブラウザ、Webサイト作業 | どちらでも。HTTPが多い | すべてのトラフィックがHTTP(S)、どこでもサポート |
| HTTPライブラリ経由のスクレイピング | HTTPまたはsocks5h | 重要なのはDNSをプロキシで解決し、余計なヘッダーを送らないこと |
| メッセンジャー、ゲーム、トレント、メール | SOCKS5 | 非HTTPトラフィック、時にUDP |
| アンチディテクトブラウザでの多数アカウント | どちらでも。プロトコルではなくIPを見る | アンチフロードは接続方法ではなくアドレスとフィンガープリントを評価 |
| 企業ネットワーク、制御とキャッシュ | HTTP | URLによるフィルタリングとログが必要 |
| デバイス全体のプライバシー | どちらでもない | これはVPNまたはTorの役割 |
ルール:プログラムに「HTTPプロキシ」フィールドがあり、HTTP(S)のみを使用するならHTTPを選びましょう。プログラムがWeb向けでない、または「SOCKS5」しかないなら、リモートDNS付きSOCKS5を選びましょう。速度について議論する意味はありません。
よくある間違い
- プロキシに暗号化を期待する。HTTPもSOCKS5もプロキシまでのトラフィックを保護しません。保護するのは内部のTLSだけです。
socks5h://の代わりにsocks5://を使い、その後DNSがどこから「漏れる」のかを探す。- HTTP以外を使用するプログラムにHTTPプロキシを設定し、その沈黙を「悪いプロキシ」のせいにする。
- 速度でプロトコルを選ぶ。速度を決めるのはアドレスとルートであり、1分で確認できます。プロキシの匿名性、リーク、速度を確認する方法を参照してください。
- エリートHTTPプロキシをSOCKS5より「匿名」と考える。どちらもアドレスを露呈しません。違いは、SOCKS5にはそれを追加する技術的な手段すらないという点だけです。
よくある質問
SOCKS5とHTTPプロキシ、どちらが速いですか?
同じサーバー上では、ネットワーク遅延に比べて違いは測定不能です。速度を決めるのはIPの種類、距離、サーバー負荷であり、プロトコルではありません。
SOCKS5はトラフィックを暗号化しますか?
いいえ。SOCKS5はバイトをそのまま転送し、ユーザー名とパスワードも平文で送られます。トラフィックを保護するのは接続内のTLS、例えばHTTPSです。
TelegramやトレントにHTTPプロキシを使えますか?
原則としてできません。これらのトラフィックはHTTPではなく、任意のポートへのCONNECTトンネルはほとんどのHTTPプロキシが禁止しています。そのようなプログラムにはSOCKS5が必要です。
socks5hとsocks5の違いは何ですか?
hはドメイン名をプロキシサーバーが解決することを意味します。これがないと、DNSクエリはあなたのコンピュータからプロバイダ経由で送られ、宛先アドレスがプロバイダに見えます。
どちらのプロトコルがより匿名ですか?
エリートHTTPプロキシとSOCKS5は同様にあなたのアドレスを露呈しません。透過型HTTPプロキシはヘッダー経由で露呈しますが、SOCKS5にはそのようなメカニズムがありません。その他のリーク(DNS、WebRTC、プロキシを迂回するトラフィック)はプロトコルに依存しません。