最終更新： 2026-10-18
「HTTPSプロキシ」は、SOCKS5が素通しにする通信をさらに暗号化するものではありません。どちらもHTTPSサイトの通信は同じエンドツーエンドのTLSセッションとして運ばれ、どちらもプロキシのパスワードはゲートウェイへ平文で送られます。2026年10月、私たちは5社の11本のプロキシを、同じゲートウェイと同じログインのまま、両プロトコルで並行して各50回ずつテストしました。
固定IPプロキシはすべてSOCKS5の接続確立が遅くなり、その差はゲートウェイとの往復2回分ときれいに一致しました。近いゲートウェイでは37ms、遠いゲートウェイでは574msです。いったん接続が開けば、ダウンロード速度は同じでした。選択を左右する違いは別のところにあります。DNSをどちらが解決するか、UDPが動くか、ブラウザが何を受け付けるか、そしてWebRTCがプロキシを迂回して何を送るかです。
結論だけ
- Webサイト、スクレイパー、ヘッドレスブラウザにはHTTPを使ってください。 どのツールでもIDとパスワード付きで使えて、接続も速いです。
- SOCKS5は Webクライアントではないソフト向けです。Telegram、メールクライアント、SSH、ゲームランチャー、デスクトップアプリなど。
- SOCKS5ではリモートDNSを有効にしてください（curlとPythonでは
socks5h://）。単なるsocks5://だと、11本すべてのプロキシでDNSルックアップがこちら側サーバーのリゾルバに任されました。 - UDPは当てにしないでください。 SOCKS5の仕様にはありますが、テストした11本のうちUDPパケットを通せたのは1本だけでした。
- どちらのプロトコルでも、ChromiumではWebRTCからIPを隠せません。 ブラウザのフラグ1つで直せます。下で説明します。
「HTTPSプロキシ」が本当に意味すること
プロバイダが「HTTP/HTTPS」を「SOCKS5」と並べて表示している場合、ここでいうHTTPSとはプロキシがHTTPSサイトに対応しているという意味で、プロキシまでの接続が暗号化されるという意味ではありません。クライアントはCONNECT example.com:443をゲートウェイへ平文で送り、ゲートウェイはサイトへTCP接続を開き、以後はバイト列を中継するだけになります。TLSハンドシェイクはクライアントとサイトの間で行われます。プロキシが見えるのはドメイン名と通信量で、ページ内容やパスワード、Cookieまでは見えません。
SOCKS5は同じ仕事を1層下で行います。クライアントがゲートウェイに対してホストとポートへの接続を依頼し、ゲートウェイがバイト列を中継します。HTTPSサイトでは結果は同じです。11本すべてで、両プロトコルともTLS 1.3、HTTP/2、サイト本来の証明書になり、サイトに届くリクエストヘッダーの集合も同一でした。
プロキシそのものへの接続は、どちらの場合も平文です。HTTPプロキシはProxy-Authorization: Basicヘッダーでログイン情報を受け取りますが、base64は暗号化ではありません。SOCKS5はRFC 1929の定義どおり、生のバイト列として受け取ります。信頼できないネットワークでは、通信を観測できる相手なら誰でもプロキシのパスワードを読めます。
プロキシまで暗号化された接続というものも存在します。アドレスがhttps://で始まるプロキシです。クライアントが最初にゲートウェイとTLSハンドシェイクを行い、その内側でパスワードが送られます。私たちは8社の14本で試しました。通常ポートで受け付けたゲートウェイは3つあり、そのうちThordataとProxmintの2つは検証に通る証明書を提示しました。最初の1バイトまでの時間は40から130ms増えました。
SOCKS5とHTTPプロキシの実際の違い
| HTTP(S)プロキシ | SOCKS5 | |
|---|---|---|
| 運べるもの | Webリクエスト、プロバイダが他ポートを許可する場合はCONNECT経由の他TCP接続 | あらゆるTCP接続、仕様上はUDPも |
| HTTPSサイト | CONNECTでエンドツーエンドTLS | エンドツーエンドTLSで同じ結果 |
平文のhttp://サイト | プロキシがリクエストを読み取り、変更できる | プロキシは手を加えずにバイト列を中継 |
| DNS | 常にプロキシ側で解決 | socks5hならプロキシ側、socks5なら自分のリゾルバ |
| UDP | なし | テストでは11本中1本だけ通った |
| ログイン付きの新規接続 | ゲートウェイとの往復1回 | ゲートウェイとの往復3回 |
| 接続後のダウンロード速度 | テストでは同じ | |
| ChromeとFirefoxでのIDとパスワード | 対応 | Chromeは非対応、Firefoxは拡張機能経由のみ |
| プロキシまでの暗号化 | https://のプロキシアドレスのときのみ | なし |
テスト内容: 同じプロキシを両プロトコルで
各プロキシで50回行いました。毎回、HTTPで新規接続を1本、SOCKS5（リモートDNS）で新規接続を1本開き、どちらを先にするかを交互に入れ替えながら、小さなHTTPSページの最初の1バイトまでの時間を測定しました。その後、すでに開いてある接続で追加のリクエストを10回送り、1MBファイルのダウンロードを各プロトコルで3回ずつ実行しました。成功率はすべてのプロキシとプロトコルで50回中49回または50回でした。
固定IPのプロキシは、ラウンド間で出口が変わらないため最も比較がきれいです。
| プロキシ | ゲートウェイまでの往復 | 最初の1バイト, HTTP | 最初の1バイト, SOCKS5 | SOCKS5が遅い差分 | 接続済み, HTTP / SOCKS5 |
|---|---|---|---|---|---|
| Proxy Seller, IPv6 | 19 ms | 99 ms | 136 ms | 37 ms | 28 / 26 ms |
| SpaceProxy, 共有データセンター | 26 ms | 192 ms | 252 ms | 60 ms | 92 / 53 ms |
| Proxy Seller, ISP | 70 ms | 735 ms | 874 ms | 139 ms | 148 / 148 ms |
| Proxy Seller, 専用データセンター | 290 ms | 2744 ms | 3318 ms | 574 ms | 592 / 554 ms |
追加でかかった時間は、どのプロキシでもタイプやプロバイダに関係なく、ゲートウェイへの往復2回分でした。これはプロトコル自体の差です。パスワード付きのSOCKS5では、あいさつ、ログイン、接続要求の順に送って、そのたびに応答待ちになります。HTTPプロキシなら、ログイン情報と接続先を1回のリクエストで渡せます。
つまりSOCKS5のコストは、あなたがゲートウェイからどれだけ離れているかで決まります。近ければ誤差程度で、世界の反対側なら0.5秒ほどになります。
トンネルが開いた後は、どちらのプロトコルもバイト列を中継するだけです。1MBのダウンロード速度は両方で同じでした。IPv6プロキシで74Mbit/s、ISPで19Mbit/s、専用データセンタープロキシで4.8Mbit/sです。接続済みの状態でのリクエストも概ね同等でしたが、例外が1つあります。SpaceProxyではHTTPポートが92ms、SOCKS5ポートが53msで、長いセッションならSOCKS5のほうが速く動きました。
ローテーションプロキシはリクエストごとに出口が変わるため、毎ラウンドで別の家庭回線や携帯回線に着地します。
| プロキシ | 最初の1バイト, HTTP | 最初の1バイト, SOCKS5 | SOCKS5が速かった回 |
|---|---|---|---|
| Evomi, ローテーション住宅 | 514 ms | 608 ms | 35% |
| Evomi, ローテーションモバイル | 620 ms | 769 ms | 38% |
| Evomi, ローテーションデータセンター | 815 ms | 798 ms | 49% |
| NodeMaven, ローテーション住宅 | 880 ms | 970 ms | 48% |
| NodeMaven, ローテーションモバイル | 1073 ms | 1255 ms | 43% |
| Proxmint, ローテーション住宅 | 1274 ms | 1216 ms | 51% |
| Proxy Seller, ローテーション住宅 | 686 ms | 655 ms | 50% |
ここでは、出口同士の差がプロトコル差よりはるかに大きくなります。ローテーションゲートウェイ経由のダウンロードは0.5から58Mbit/sまで幅があり、同じゲートウェイと同じプロトコルで連続して2回落としても、速度が何倍も違うことがよくありました。EvomiとNodeMavenでは、それでも中央値ではHTTPが90から180msほど速くなりました。Proxmint、Proxy Seller、Evomiのデータセンタープールでは両者は同等でした。ローテーションプロキシは単発のテストリクエストでは何も分かりません。比較するなら数十回単位で行うか、そもそも比較しないほうがよいです。
DNS: SOCKS5が増やす漏れ
HTTPプロキシでは、サイト名がリクエストに含まれるため、ゲートウェイが常に名前解決を行います。SOCKS5はクライアント側で選べます。socks5://では先に自分のマシンがアドレスを引き、プロキシにはIPだけを送ります。socks5h://では名前を送り、プロキシ側で引きます。
私たちは、各プロキシで各モードごとに一意のテストドメインを引き、どのリゾルバが問い合わせたかを確認しました。socks5://では11本すべてで、フランスのOVHデータセンターにある私たち自身のサーバーのリゾルバが問い合わせていました。その一方で、サイトが見た出口IPは別の国でした。
Webサイト自体はあなたのリゾルバを見ませんが、DNSリークテストは見ます。また、そのリゾルバの運用者は、あなたが開くドメインをすべて把握できます。socks5h://とHTTPでは、ルックアップはプロキシ側から来ました。多くのゲートウェイではGoogleとCloudflareの公開リゾルバで、一部の住宅とモバイルの出口ではローカルISPのリゾルバでした。
リモートDNSには副作用が1つあります。リゾルバが出口とは別の国にあることがよくありました。コロンビアのローテーション住宅出口が米国のGoogleで解決し、ロシアのモバイル出口がシンガポールのリゾルバで解決するといった具合です。大手CDNはリゾルバの場所で配信先サーバーを選ぶため、出口から遠いサーバーに振られて遅くなることがあります。
リモートDNSを有効にする方法
- curl:
--proxy socks5h://user:pass@host:portまたは--socks5-hostname host:port - Python requests:
pip install "requests[socks]"の後にproxies={"https": "socks5h://user:pass@host:port"} - Proxifierなど: ホスト名をプロキシ経由で解決するオプション
平文HTTPサイト: HTTPプロキシが変更できること
http://のアドレスにはTLSがないため、HTTPプロキシは本当の中継者として動きます。リクエストを読み取り、独自のコピーを送ります。NodeMavenとProxy Sellerの住宅ゲートウェイでは、そのコピーにクライアントが送っていないAccept-Encodingヘッダーが含まれていました。
SOCKS5経由とCONNECTトンネル経由では、同じリクエストがすべてのプロキシで変更されずに届きました。11本のどれも、どちらのプロトコルでもX-Forwarded-Forに私たちのサーバーIPを載せてサイトへ渡しませんでした。「SOCKS5のほうが匿名性が高い」という古い定説は、今回テストしたどのプロバイダでも当てはまりませんでした。
UDP: 仕様にはあるが、実運用ではまれ
SOCKS5にはUDPモードのUDP ASSOCIATEがあり、ゲームや音声通話、QUICでSOCKS5が選ばれる典型的な理由でもあります。私たちは各ゲートウェイに要求し、リレー経由で1.1.1.1へDNSクエリを送ってみました。
- 通った: SpaceProxy（共有データセンター）。クエリが出て、応答も戻りました。
- コマンドは受け付けたがパケットを落とした: Proxy Seller（ローテーション住宅）。エラーは出ず、応答もありません。
- 拒否: Evomi（3つのゲートウェイすべて）、Proxy Seller（IPv6、ISP、専用データセンター、応答は「command not supported」）、Proxmint（「not allowed」）。
- 接続を閉じた: NodeMaven（両ゲートウェイ）。
UDPが必要なら、ボリュームを買う前に最小プランでテストしてください。コマンドを受け付けるゲートウェイでも、パケットをすべて落とすことがあります。多くのソフトは通知なしにTCPへフォールバックします。
ブラウザ: パスワード付きSOCKS5は動かない
ChromeはSOCKS5のログインに対応しておらず、Firefoxもプロキシ設定からは受け付けず、拡張機能経由のみです。curlで通った認証情報を使ってPlaywrightでChromiumとFirefoxを起動しましたが、どちらも「Browser does not support socks5 proxy authentication」として拒否しました。同じログイン情報でもHTTPなら両方で動きました。通常ブラウザでもヘッドレスでも、選択肢は2つです。HTTPプロキシを使うか、多くのプロバイダがダッシュボードで許可しているIPアドレス認証のSOCKS5にするかです。アンチディテクトブラウザやプロキシ拡張はSOCKS5のログインを自前で渡すため、この制限はブラウザ単体に当てはまります。
WebRTCはどちらのプロトコルも迂回する
WebRTCはSTUNサーバーへUDPを送って公開アドレスを学習します。Proxy Seller、SpaceProxy、NodeMavenのプロキシ経由でページを開き、WebRTCのcandidateを集めました。3社とも結果は同じでした。
| ブラウザとプロキシ | ページに見えるIP | WebRTCの公開IP |
|---|---|---|
| Chromium, HTTPプロキシ | プロキシ | 私たちのサーバーの実IP |
| Chromium, SOCKS5 | プロキシ | 私たちのサーバーの実IP |
Chromium, いずれのプロトコルでも --force-webrtc-ip-handling-policy=disable_non_proxied_udp を付けた場合 | プロキシ | なし |
| Firefox（Playwrightビルド）, HTTPプロキシ | プロキシ | 私たちのサーバーの実IP |
| Firefox（Playwrightビルド）, SOCKS5 | プロキシ | なし |
SpaceProxyはSOCKS5でUDPを通せますが、それでもChromiumはWebRTCを迂回して送信しました。つまりUDPが使えるゲートウェイでも解決しません。Chromiumでは上のフラグ、または同じポリシーを設定するWebRTC拡張で対処できます。アンチディテクトブラウザはWebRTCのアドレスをプロキシのものに置き換えます。プロキシ接続後に、私たちのWebRTCリークテストで自分の環境を確認してください。
ポート: プロバイダがSOCKS5を置く場所
プロバイダはSOCKS5とHTTPを別商品として売っているわけではありません。1つのプランで両方が使えて、変わるのはポートかアドレスのスキームだけです。
| プロバイダ | HTTPとSOCKS5 |
|---|---|
| Evomi | ポート分離: 住宅は1000と1002、モバイルは3000と3002、データセンターは2000と2002 |
| NodeMaven | ポート分離: 8080と1080 |
| Proxmint | 1つのポートで両対応 |
| Proxy Seller | ローテーションゲートウェイも固定IPも1つのポートで両対応 |
| SpaceProxy | ポート分離で、SOCKS5は次のポート番号 |
1ポートのゲートウェイは先頭のバイト列でプロトコルを判別するため、http://をsocks5h://に変えるだけです。ポート分離の場合、間違ったほうに向けると空の応答など分かりにくいエラーで失敗します。これが「SOCKS5が動かない」の最も多い原因です。
用途別にどのプロトコルを選ぶか
| 用途 | プロトコル | 理由 |
|---|---|---|
| curl、Python、Node.jsでのWebスクレイピング | HTTP | 接続が速く、追加ライブラリ不要。SOCKS5はリモートDNSが必須 |
| Playwright、Puppeteer、Selenium | HTTP | ChromiumとFirefoxはSOCKS5のログインを受け付けない |
| アンチディテクトブラウザ、マルチアカウンティング | どちらでも | ブラウザ側がログインとWebRTCを処理する |
| Telegram、メールクライアント、SSH、デスクトップアプリ | SOCKS5 | HTTPを話さない |
| ゲーム、音声通話、ビデオ通話 | UDPが動くSOCKS5 | 先にUDPをテスト。通るゲートウェイは少ない |
| 公共Wi-Fi | プロバイダが対応しているならhttps://のプロキシアドレス | プロキシのパスワードを暗号化できる唯一の選択肢 |
どのプロトコルを選んでも、入れるサイトが決まるわけではありません。それを決めるのはIPです。種類、ネットワーク、履歴が影響します。この選び方はプロキシタイプの選び方ガイドと、毎週の結果をまとめたプロキシベンチマークを参照してください。
自分のプロキシを確認する方法
- 出口とプロトコル:
curl -x socks5h://user:pass@host:port https://www.cloudflare.com/cdn-cgi/traceを実行し、その後http://でも同じことを行います。どちらも出口の国が同じで、http=http/2と出るはずです。 - 接続コスト:
-s -o /dev/null -w "%{time_connect} %{time_appconnect}\n"を追加し、プロトコルごとに20回実行します。最初の数値がゲートウェイまでの往復です。固定IPならSOCKS5はその約2回分遅くなるはずです。 - DNS: プロキシ経由でDNSリークテストを
socks5とsocks5hで開き、リゾルバを比較します。 - プロキシが動くかどうか、タイプと場所: 私たちのプロキシチェッカー。
今回のテストに含まれるプロバイダ
5社とも、1つのプランで両プロトコルを提供しています。
Evomi
https://evomi.com/
$0.49/GB
プロキシタイプ
モバイルプロキシ, レジデンシャルプロキシ, ISP プロキシ, データセンタープロキシ
IPプール
100M+ IP
設立日
2014
本社
スイス
メリットとデメリット
- 無料トライアル
- 30日以内の返金
- 大量購入でGB単価が最大51%安い
- 1つのアカウントで5種類のプロキシ
- 月額料金なしで利用できる従量制プラン
- カード払いの場合、別途VATが課されます
NodeMaven
https://nodemaven.com/
$2.75/GB
プロキシタイプ
モバイルプロキシ, レジデンシャルプロキシ, ISP プロキシ
IPプール
30M+ IP
設立日
2023
本社
エストニア
メリットとデメリット
- $3.50の有料テスト
- 大量購入でGB単価が最大48%安い
- 月次プランでは、未使用のトラフィックは翌月に繰り越されます
- 従量課金オプションあり
- 支払い方法が限られている
Proxmint
https://proxmint.com/
$1.25/GB
プロキシタイプ
モバイルプロキシ, レジデンシャルプロキシ, データセンタープロキシ
IPプール
90M+ IP
設立日
2026
本社
インドネシア
メリットとデメリット
プロキシタイプ
モバイルプロキシ, レジデンシャルプロキシ, 専用 IPv6 プロキシ, ISP プロキシ, データセンタープロキシ
IPプール
47M+ IP
設立日
2014
本社
キプロス
メリットとデメリット
- 24時間以内の返金
- 大量購入でGB単価が最大63%安い
- 1つのアカウントで8種類のプロキシ
- SDK：PHP, Python, Node.js, Java, GoLang
- 24時間365日のサポート
SpaceProxy
https://spaceproxy.net/
$0.99/IP
プロキシタイプ
専用 IPv6 プロキシ, データセンタープロキシ
IPプール
47M+ IP
設立日
2019
本社
キプロス
メリットとデメリット
- 2日以内の返金
- 8種類の支払い方法
- IPv6プロキシあり
- 幅広い国の選択肢
- カスタマーサポートの品質に関する苦情があります。
テスト方法
テストは2026年10月18日に、ロンドンのデータセンターにある私たちのサーバーからcurl 8.5で実施しました。私たちのプロキシベンチマークのテスト用アクセスのうち、両プロトコルを提供する11本を使いました。比較はすべて同じゲートウェイと同じログインで行っています。変えたのはスキームだけで、プロバイダが要求する場合のみポートも変えました。
- 計測: プロキシごとに50回、各リクエストで新規接続、プロトコル順を交互に入れ替え、
https://www.cloudflare.com/cdn-cgi/traceを対象に実施。 - 接続済み: 1つの接続で11リクエストを3回、各回の最初のリクエストは除外。
- 速度: 私たちのサーバー上の1MBファイルを、プロトコルごとに3回、転送時間のみを計測。
- DNS: 公開DNSリークテストサービスの一意なサブドメインを使用し、モードごとに1つ。
- ヘッダー: httpbin.orgを平文HTTPとHTTPSで。
- UDP: SOCKS5の
UDP ASSOCIATE要求と、リレー経由で1.1.1.1へのDNSクエリ。 - ブラウザ: Playwright経由のChromiumとFirefox、
stun.l.google.comからのWebRTC candidate。ブラウザはSOCKS5のパスワードを受け付けないため、ブラウザ内のSOCKS5はパスワードなしのローカルリレー経由で実行。
これは週次ベンチマークとは別の、単発のテストです。
出典
- RFC 1928: SOCKS Protocol Version 5
- RFC 1929: Username/Password Authentication for SOCKS V5
- RFC 9110: HTTP Semantics, CONNECTメソッド
- Everything curl: SOCKSプロキシとsocks5h
- GitHub上の私たちのプロキシベンチマークのコード
FAQ
- SOCKS5はHTTPSプロキシより速いですか？
- いいえ。11本のプロキシで実施した当社テストでは、認証付きSOCKS5は新しい接続を開くたびにゲートウェイとの往復が2回分余計に発生し、距離によって37msから574ms遅くなりました。接続が確立した後のダウンロード速度は、どちらも同じでした。
- SOCKS5は暗号化されていますか？
- いいえ。SOCKS5はバイト列をそのまま中継し、ログイン情報も平文で送信します。ただしHTTPSサイトは、TLSがクライアントとサイトの間で動作するため、HTTPプロキシ経由の場合と同様に暗号化されたままです。
- HTTPSプロキシは通信を暗号化しますか？
- プロキシまでの接続は暗号化されません。「HTTPSプロキシ」は通常、CONNECTでHTTPSサイトを開くHTTPプロキシを指し、プロキシのパスワードはbase64で送信されます。https://で始まるプロキシアドレスだけがゲートウェイまでの経路を暗号化し、試した14本のプロキシのうち有効な証明書で対応していたのは2つだけでした。
- socks5とsocks5hの違いは何ですか？
- socks5では、サイト名の名前解決は自分のコンピューターが行い、プロキシにはIPだけを送るため、DNSリゾルバにはアクセスしたすべてのドメインが見えてしまいます。socks5hでは、名前をプロキシに渡し、プロキシ側で名前解決を行います。当社のテストでは、11本すべてのプロキシがsocks5の場合、名前解決をこちらのリゾルバに任せたままでした。
- SOCKS5はUDPをサポートしていますか？
- プロトコルとしてはサポートしていますが、多くのゲートウェイは対応していません。テストした11本のプロキシのうち、UDPパケットを実際に届けたのは1つだけで、もう1つは要求は受け付けたもののパケットを破棄し、残りは拒否しました。
- ログイン付きのSOCKS5プロキシをChromeで使えますか？
- いいえ。ChromeはSOCKS5の認証に対応しておらず、Firefoxも拡張機能経由でしか受け付けません。同じログイン情報で使えるHTTPプロキシ、IPアドレス認証のSOCKS5、またはアンチディテクトブラウザを使ってください。
- SOCKS5はWebRTCのリークを防げますか？
- いいえ。Chromiumでは、HTTPプロキシでもSOCKS5でもWebRTCが当社サーバーの実IPを表示しました。フラグの--force-webrtc-ip-handling-policy=disable_non_proxied_udp、またはWebRTC拡張で防げます。
- WebスクレイピングにはSOCKS5とHTTPのどちらが適していますか？
- HTTPです。接続が速く、追加設定なしでどのスクレイピングライブラリでも対応しており、HTTPSサイトではどちらを使ってもターゲット側に見えるリクエストは同じです。SOCKS5を使うなら、DNSもプロキシ経由になるようsocks5hを使ってください。
