SOCKS5 と HTTP プロキシは何が違う？フィンガープリントブラウザに設定する前に知っておきたいこと

プロキシを選ぶとき、多くの人は地域・帯域・価格だけを見て、種類の欄で手を止めません——HTTP か SOCKS5 か。しかしこの欄が三つのことを決めます。DNS リクエストがどちら側から出るか、UDP トラフィックが通るか、プロキシがリクエストヘッダーを書き換えるか。普段のブラウジングではほとんど意識しませんが、MakoBrowser のようなフィンガープリントブラウザ環境にプロキシを設定した瞬間、環境の品質に直接影響します。以下では、まず両者の違いを整理し、そのうえで選び方の判断基準と、設定・検証の手順をまとめます。

根本的な違い：一方はウェブの言語を理解し、もう一方は運ぶだけ

HTTP プロキシはアプリケーション層で動作し、通過する HTTP リクエストを読めるため書き換える能力も持っています。SOCKS5 は汎用の中継路にすぎず、中身に関心を持ちません。

http ページにアクセスするとき、HTTP プロキシはリクエスト先とリクエストヘッダーを見られます。https のときは、ブラウザが先に CONNECT リクエストを送ってトンネルを作り、トンネルが確立すると内容はプロキシから見えなくなります。この点は CONNECT メソッドに関する MDN の説明に明確に書かれています。つまり HTTP プロキシも HTTPS をトンネルで処理しており、その能力は常に HTTP プロトコルを中心にしたものです。

SOCKS5 の位置づけは異なります。RFC 1928 はこれをアプリケーション層とトランスポート層の間の緩衝層と表現し、CONNECT、BIND、UDP ASSOCIATE の三つのコマンドを定義しています。かみ砕くと、トラフィックの中身を解析せず、データをそのまま宛先へ届けるだけで、しかも運ぶのは TCP だけではありません。

実際の利用では、違いは主に次の点に表れます。

• どのトラフィックが通るか：HTTP プロキシは HTTP と HTTPS を扱います。SOCKS5 は任意の TCP トラフィックを中継でき、UDP もネイティブにサポートします。
• リクエストに手を加えるか：HTTP プロキシは HTTP 層でリクエスト内容が見え、実装によっては Via や X-Forwarded-For などのヘッダーを追加します。SOCKS5 はアプリケーション層の内容を変更しません。
• 認証方式：HTTP プロキシは Basic 認証が一般的で、資格情報は base64 エンコードにすぎず、安全性は HTTPS に依存します。SOCKS5 には独自の認証ネゴシエーションがあり、RFC 1929 がユーザー名とパスワードの方式を定義しています。
• ポートの慣例：SOCKS サービスは伝統的に 1080 番ポートで動きますが、プロバイダーが指定したポートをそのまま入れます。

フィンガープリントブラウザに設定すると、本当に問題になるのは DNS と UDP

プロキシ種別を間違えると、最初に出る問題はつながらないことではなく、DNS リクエストがこっそりローカル回線を通ることです。

DNS をどちら側で解決するかが、漏れるかどうかを決める

ドメイン名をどちら側で解決するかは、プロキシ種別の名前ではなくクライアントの設定で決まります。SOCKS5 はドメインをそのままプロキシ側に渡せます。RFC 1928 にはドメイン型のアドレスが定義されています。ただしクライアントの既定がそうとは限りません。Firefox を例にすると、SOCKS v5 使用時にプロキシ DNS を使用する、にチェックを入れて初めて解決がプロキシ経由になります。チェックがない場合、クライアントは先にローカルでドメインを IP に解決してからプロキシに渡すため、DNS リクエストはローカルの回線事業者に渡ります。これがプロキシにおける DNS リークの最も一般的な原因です。

HTTP プロキシは通常、ホスト名をプロキシ側に渡して解決させますが、同じく当然とは言えません。WebRTC の直結、ブラウザの先読み解決、プロキシを通らないトラフィックが、解決リクエストをローカルに戻す可能性があります。

検証は難しくありません。環境を起動したら任意の DNS リーク検査ページにアクセスし、解決サーバーがどの地域に属するかを見ます。ローカルの回線事業者が表示されれば、解決がプロキシに追従していないということです。

UDP サポートはいつ重要になるか

ブラウザは HTTP/3 対応サイトにアクセスするとき QUIC を試み、QUIC は UDP 上で動きます。プロキシが TCP しかサポートしない場合、トラフィックは自動的に TCP にフォールバックし、ページは普段どおり開き、日常では違いを感じません。本当に SOCKS5 が必要になるのは、環境内で UDP に依存するツールも動かしている場合です。

ウェブ運用だけなら UDP は決定要因ではありません。環境内に追加ツールがあるなら、それが決定要因になります。

どんな場面で SOCKS5 を使い、どんな場面で HTTP で足りるか

選定はどちらが上級かではなく、トラフィックの構成とプロバイダーが提供する種別だけで決まります。

そのまま照合できる判断基準を挙げます。

1. プロバイダーが HTTP 種別しか提供せず、用途がブラウザのウェブトラフィックだけ：HTTP プロキシをそのまま使えば十分です。
2. 環境内にブラウザ以外の UDP 依存ツールがある、または DNS の露出面を減らしたい：SOCKS5 を優先します。
3. プロキシにキャッシュ、コンテンツフィルタ、アクセス監査を担わせたい：HTTP プロキシが適しています。リクエスト内容を理解できる点にこそ価値があります。
4. 複数アカウントを開いて SNS や店舗運用をするだけ：どちらの種別でも満たせます。本当の差はプロトコルにはありません。

広く流布している二つの誤解は切り分けておく価値があります。一つは、SOCKS5 のほうが必ず速いというものです。速度はプロキシサーバーの帯域、負荷、経路の距離に依存し、プロトコル種別とは直接関係しません。もう一つは、SOCKS5 のほうが匿名性が高いというものです。SOCKS5 はトラフィックの内容を変えないだけで、あなたが誰かを隠すものではありません。ログを保持するかはプロキシ事業者によります。

もう一点補足します。プロキシ種別は選定における一つのパラメーターにすぎません。プロキシが専有か、地域が安定しているか、IP を頻繁に変えないか。これらは環境の分離への影響が、プロトコル種別より大きいことが多いのです。種別で長く悩みながら、IP が次々変わる共有プロキシを使っているなら、順序が逆です。

フィンガープリントブラウザでプロキシを設定する：種別の入力から有効性の検証まで

設定自体は数ステップですが、順序を間違えると何度もやり直しになります。まず環境の外で疎通を確認し、次に環境内で設定し、最後にブラウザ内で再確認します。

1. まずプロキシ自体が使えるか確認します。ホスト、ポート、種別、認証情報を入手したら、環境の外で一度疎通を試します。こうすると、プロキシが使えないのか、環境の設定に問題があるのかを切り分けられます。

2. 環境のプロキシ設定を開き、種別を選びます。種別はプロバイダーが示したものと一致させる必要があります。SOCKS5 プロキシを HTTP として入力すると接続できず、しかもエラーはたいてい曖昧で、環境の不具合と誤判定しやすくなります。

   

3. ホスト、ポート、認証情報を入力します。ユーザー名とパスワードがあれば入力し、余分な空白を一緒に貼り付けないよう注意します。これはよくある初歩的なミスです。

   

4. 保存後に環境内のプロキシ検出を一度実行し、出口 IP、国と地域が想定どおりか確認します。

5. 環境を起動したら、ブラウザ内でもう一度確認します。出口 IP、DNS 解決位置、WebRTC の三点に注目します。

6. 固定します。一つのアカウントに一つの固定出口を対応させ、より安全に見えるために頻繁にノードを変えないこと。頻繁な切り替え自体が異常シグナルです。

ステップ 4 とステップ 5 は別のことを確認します。環境内の検出はプロキシ経路が通るかを、ブラウザ内の再確認はトラフィックが別の場所から漏れていないかを確かめます。前者だけでは、DNS と WebRTC を見落としやすくなります。

設定後に必ず行う三つの検証

プロキシを設定しただけでは有効になりません。出口 IP、DNS 解決位置、WebRTC の三点をそれぞれ確認する必要があります。

• 出口 IP と地域：任意の IP 照会ページにアクセスし、表示されるのがプロキシの IP であって端末の IP でないこと、地域がプロバイダーの説明と一致することを確認します。
• DNS 解決位置：DNS リーク検査ページで解決サーバーの所在地を見ます。SOCKS5 の場合もここは重点です。解決位置はクライアント設定に依存し、当然視できないからです。
• WebRTC：ブラウザが WebRTC 経由で実 IP を露出していないか確認します。プロキシだけ変えて環境分離をしていない一般のブラウザではよくある問題です。

もう一つ見落としやすい点があります。タイムゾーン、言語、システム地域を出口の地域に合わせることです。米国プロキシを設定したのにタイムゾーンが東八区のままだと、この矛盾はプロトコル種別の選び間違いよりも目に付きやすくなります。

十数個、時には数十個の環境を設定する場合、種別・出口・地域を使い回せる設定として固定するほうが、毎回手入力するより手間が省けます。MakoBrowser がプロキシを環境と一緒に管理しているのはそのためです。環境、アカウント、ネットワーク出口を同じ場所で保ち、担当が変わっても、このアカウントはどのノードかと聞き直す必要がありません。まず一つの環境を通したい場合は、ダウンロードページからクライアントをインストールするところから始められます。

よくある質問

SOCKS5 と HTTP プロキシはどちらが速いか

決まった答えはありません。速度はプロキシサーバーの帯域、負荷、経路の距離、対象サイトに依存し、プロトコル種別との関係は大きくありません。種別で悩むより、まずプロキシ自体の回線品質を見るべきです。

フィンガープリントブラウザでは必ず SOCKS5 を使うべきか

必須ではありません。ウェブトラフィックだけで、プロバイダーが HTTP 種別のみを提供する場合、HTTP プロキシでも問題なく使えます。SOCKS5 の利点は UDP サポートと制御可能な遠隔 DNS 解決に集中しており、環境内に UDP 依存のツールがあるときに優先すれば十分です。

プロキシを設定したのに実 IP が表示されるのはなぜか

よくある原因は三つです。種別を間違えてプロキシが実際には有効でない、ブラウザが WebRTC で直結している、DNS が依然としてローカルで解決されている。前節の順序で項目ごとに確認すれば、どの段階かをほぼ特定できます。

HTTP プロキシで HTTPS サイトにアクセスできるか

できます。ブラウザはまず CONNECT メソッドでプロキシ上にトンネルを張り、トンネル内のトラフィックは暗号化されるため、プロキシは具体的なページ内容を見られません。これが HTTP プロキシが HTTPS を扱う標準的な方法です。

プロキシ種別はアカウントの安全性に影響するか

プロキシ種別そのものがアカウントの結果を決めるわけではありません。実際に効くのは、出口が安定しているか、地域がアカウントと一致しているか、頻繁に切り替えていないかです。どのツールもプラットフォームの確認を完全に防げるわけではありません。環境をきれいに保ち、異常な変動を避けることが、あなたが制御できる部分です。