HTTPプロキシとSOCKS5プロキシ:どちらを使うべきか、その使い分け

HTTPプロキシとSOCKS5プロキシは、それぞれ異なる問題を解決します。それぞれの仕組み、どちらが有利になるか、そして自分のワークロードに合ったものを選ぶ方法についての実践的なガイドです。

「HTTPとSOCKS5のどちらを使うべきか」というのは、新規のお客様から最もよく寄せられる質問のひとつです。正直なところ、答えは「何に接続するか」によります。ほとんどの場合、日常的なウェブスクレイピングでは両者は入れ替え可能です。違いが問題になるのは端のケースだけであり、まさにそこで人々は間違った方を選び、実はコードとは無関係だった問題のデバッグに1日を費やすことになります。

これはその違いについての実践的なガイドです。HTTPプロキシが実際に何をするのか、SOCKS5プロキシが何を異なる方法で行うのか、それぞれがどこで優位に立つのか、そして選び方のシンプルなルールを解説します。プロトコルの歴史の講釈はなしで、あなたが取るべき行動を左右する部分だけを扱います。

ひとつだけ覚えるなら、これです。HTTPプロキシはウェブリクエストを理解し、それに基づいて動作できます。SOCKS5プロキシはバイトを転送するだけで、中身には関知しません。前者はより賢く、後者はより汎用的です。

一文で説明する違い

HTTPプロキシはアプリケーション層で動作します。HTTPを解釈するため、リクエストラインを読み取り、対象のURLを把握し、ヘッダーを検査・変更し、見えているものに基づいて判断を下せます。ウェブトラフィックをプロキシしていることを認識しています。

SOCKS5プロキシはそれより下、トランスポート層に近いところで動作します。クライアントと宛先の間にトンネルを開き、生のバイトを双方向に転送します。そこを流れるものを解析しません。HTTPにも使えますが、TCPやUDP上の他の何にでも同じように機能します。

このアーキテクチャ上の一つの違いが、以下で説明する実務上のあらゆる区別を生み出しています。

HTTPプロキシがリクエストを処理する仕組み

クライアントがHTTPプロキシ経由でリクエストを送信すると、プロキシはリクエスト全体を見ます。プレーンなhttp://リクエストの場合、プロキシは完全なURLを読み取り、ヘッダーを書き換え、レスポンスをキャッシュし、フィールドを挿入または削除でき、理解できるリクエストを転送します。https://リクエストの場合、クライアントはまずプロキシにCONNECTを送信し、プロキシは宛先へのトンネルを開き、そこから先は暗号化されたトラフィックがプロキシに読み取られることなく通過します。つまりHTTPプロキシでもHTTPSの場合は結局トンネリングを行うことになりますが、それでもCONNECTから宛先のホストとポートを把握しており、HTTP層で認証とルーティングも処理します。

結論として、HTTPプロキシはウェブを認識しています。プロキシにリクエストに対して何かをしてほしいときには有用であり、単に邪魔にならず通過させたいだけのときには無関係な特性です。

SOCKS5プロキシが接続を処理する仕組み

SOCKS5プロキシは短いハンドシェイクを行い(任意のユーザー名/パスワード認証、その後宛先のホストとポートを指定する接続リクエスト)、その後は単純なパイプとして機能します。あなたのバイトが出ていき、宛先からのバイトが返ってくるだけで、プロキシはその内容を一切解釈しません。HTTPという概念自体を持たないため、HTTPヘッダーという概念も持ちません。

これは制限ではなく特徴です。プロトコルを解析しないため、SOCKS5は何でも運びます。HTTP、HTTPS、WebSocket、生のTCP、データベース接続、SSH、独自プロトコル、そして(特にSOCKS5では)UDPです。このプロキシは設計上プロトコルに依存しません。

HTTPプロキシが優位な場面

ウェブスクレイピングとほとんどのブラウザ自動化。 「このURLを取得する」という圧倒的多数のワークロードにとって、HTTPプロキシは自然な選択肢であり、あらゆるHTTPクライアントやライブラリでよくサポートされており、驚くようなことは何も起きません。仕事がウェブサイトへのリクエストであれば、HTTPがデフォルトなのには理由があります。

ヘッダーレベルの制御や可視性が欲しい場合。 HTTPプロキシはリクエストを理解するため、その周辺のツールはリクエストレベルでログを取り、ルーティングし、変換できます。プレーンなHTTPではこれは直接的に行えます。HTTPSの場合でも、プロキシはCONNECTから宛先を把握しています。

最大限のツール互換性。 あらゆるスクレイピングフレームワーク、あらゆるブラウザ、あらゆるHTTPライブラリがHTTPプロキシを第一級のものとしてサポートしています。SOCKS5のサポートが不格好だったり部分的だったりするものもあります。最も摩擦の少ない道を望むなら、HTTPがあなたを困らせることはほとんどありません。

SOCKS5プロキシが優位な場面

HTTP以外のトラフィック。 あなたの自動化がウェブリクエスト以外の何かを行う瞬間、SOCKS5が答えになります。メールサーバー、データベース、IRCやチャットプロトコル、ゲームサーバー、独自のTCPサービスなど、HTTPではない何かに接続する場合、HTTPプロキシは役に立たず、SOCKS5なら対応できます。

UDPベースのプロトコル。 SOCKS5はUDPをサポートしていますが、HTTPプロキシは根本的にこれができません。UDPに乗る何かを扱っている場合、SOCKS5は好ましいだけでなく、機能する唯一のプロキシの選択肢です。

プロキシ側での低オーバーヘッド。 HTTPを解析して判断を下す必要がないため、SOCKS5プロキシは接続ごとの処理が少なくて済みます。非常に高い接続量では、これがわずかに低いレイテンシーとリクエストあたりのオーバーヘッド減少につながることがあります。この効果は典型的なスクレイピングでは控えめですが、大規模になれば実際に現れるため、高スループットの自動化パイプラインはしばしばSOCKS5に頼っています。

SOCKSエンドポイントを想定するツール。 一部のソフトウェア(特定のトレントクライアント、SSHの-D動的フォワーディング、一部のプライバシーツール)はSOCKSをネイティブに話します。あなたのツールがSOCKS5プロキシを求めているなら、HTTP層で包むのではなく、そのまま与えてください。

両者の間で異ならないこと

ここには多くの誤解が存在するため、はっきりさせておく価値があります。

匿名性とブロック率は同じです。 プロキシに到達するために使うプロトコルは、宛先が見るIPも、そのIPの評判も、アンチボットシステムがどうスコアリングするかも変えません。レジデンシャルIPは、HTTP経由でもSOCKS5経由でも全く同じだけ信頼できます。誰かがSOCKS5の方が「より匿名性が高い」とか「検出されにくい」と言うなら、それは神話を売りつけているだけです。宛先が見るのはあなたの出口IPとトラフィックのフィンガープリントであり、プロキシのプロトコルではありません。

通常のワークロードでは速度もほぼ同じです。 SOCKS5のオーバーヘッド面での優位性は実在しますがわずかです。数千件のリクエストを行うスクレイパーであれば、意味のある差は測定できないでしょう。出口IPまでのネットワーク距離、ターゲットサーバーの速度、そして並行処理の設定の方が、HTTPかSOCKS5かよりもはるかに支配的です。

ジオターゲティングとセッション制御も同じです。 Shifterゲートウェイでは、国、州、市、ASN、そしてスティッキーセッションのターゲティングは、どちらのプロトコルで接続しても全く同じように機能します。ターゲティングはユーザー名の中にあり、プロトコルの中にはありません。

つまり、プロトコルの選択は何に接続するか、そしてツールが何を期待しているかの問題であり、ブロックされにくくなったり、より上手く隠れられたりする話ではありません。

Shifterゲートウェイでの見え方

Shifterのレジデンシャルゲートウェイは、HTTP、HTTPS、SOCKS5、SOCKS5hのすべてを、同一のエンドポイント、同一のホスト、同一のポート、同一の認証情報で話します。プロトコルはクライアント側で選択し、サーバー側では何も変わりません。

curlでのHTTP/HTTPS:

curl -x http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://api.ipify.org

全く同じリクエストをSOCKS5h経由で行う場合(hはDNSがプロキシ側で解決されることを意味し、ローカルのリゾルバが対象のホスト名を決して見ないようにしたいときには、ほぼ常にこれが望ましい選択です):

curl -x socks5h://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://api.ipify.org

唯一の変更点はスキームだけであることに注意してください。http://がsocks5h://になっています。ユーザー名(すべてのターゲティングフラグを含む)、パスワード、ホスト、ポートは同一です。それだけが切り替えのすべてです。

Pythonのrequestsでも、同じ考え方のパターンです:

import requests

# HTTP/HTTPS
proxies = {
    "http": "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
    "https": "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
}

# SOCKS5 (requires: pip install requests[socks])
proxies_socks = {
    "http": "socks5h://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
    "https": "socks5h://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443",
}

r = requests.get("https://api.ipify.org", proxies=proxies)
print(r.text)

知っておく価値のあることが一つあります。requestsでは、SOCKSのサポートに追加のrequests[socks]インストールが必要です(PySocksを取り込みます)。HTTPには追加のものは何も必要ありません。このパッケージング上の摩擦は、小さいながらも実際に、HTTPがちょっとしたスクリプトのデフォルトであり続ける理由の一つです。

SOCKS5とSOCKS5h: DNSをどこで解決するか

人々を混乱させる注記があります。プレーンなsocks5://は宛先のホスト名をあなたのマシン上で解決し、その結果のIPをプロキシに送信します。socks5h://はホスト名をプロキシに送信し、プロキシに解決させます。プロキシ利用の場合、ほぼ常にsocks5hが望ましいです。理由は次の通りです。

DNSルックアップをローカルネットワークの外に置くことができ、これはプライバシーの面でも、出口地域から地理的に正しいDNS応答を得る面でも重要です。
ローカルのリゾルバがターゲットの想定するプロキシの地域からとは異なるIPを返すという、微妙なバグの一群を回避できます。

SOCKS5経由でジオに一貫性のない結果が出ている場合は、socks5hではなくsocks5を使っていないか確認してください。これは1文字の修正であり、「ジオターゲティングが機能していない」という驚くほど多くのチケットを解決します。

シンプルな判断ルール

フローチャートは必要ありません。3つの質問を順番に確認してください。

トラフィックはHTTP/HTTPS(ウェブリクエスト)ですか? そうであり、特別な理由がなければ、HTTPを使ってください。これがデフォルトであり、普遍的にサポートされており、追加のパッケージも不要です。これはほとんどのスクレイピング、価格モニタリング、SERP収集、ブラウザ自動化をカバーします。
トラフィックはHTTP以外の何か、あるいはUDPを使っていますか? SOCKS5を使ってください。メール、データベース、独自のTCP/UDPサービス、SOCKSをネイティブに話すツールなど、ウェブ以外の何かです。この二つのうちSOCKS5だけがそれを運べます。
非常に高スループットのパイプラインを運用していて、接続あたりのオーバーヘッドを削りたいですか? SOCKS5がわずかな優位性を与えてくれます。差が重要だと決めつける前に、実際のワークロードでテストしてください。ほとんどのチームにとっては重要ではありません。

判断はこれで全てです。迷ったらHTTP。ウェブリクエストでないならSOCKS5です。

FAQ

ウェブスクレイピングにおいてSOCKS5はHTTPより速いですか? 良くてもわずかであり、通常は測定できるほどではありません。SOCKS5はプロトコルの解析を少なく行うため、接続あたりのオーバーヘッドはわずかに低くなりますが、典型的なスクレイピングではレイテンシーはネットワーク距離とターゲットサーバーの応答時間に支配され、プロキシのプロトコルには支配されません。ウェブトラフィックの高速化を期待してSOCKS5に切り替えるべきではありません。

SOCKS5はHTTPよりも匿名性が高い、あるいは検出されにくいですか? いいえ。宛先が見るのはあなたの出口IPとトラフィックのフィンガープリントであり、プロキシへの到達方法ではありません。検出率とブロック率はIPの品質(レジデンシャルかデータセンターか)、リクエストのパターン、そしてフィンガープリントに依存し、HTTPかSOCKS5かには決して依存しません。これはプロキシプロトコルに関する最も一般的な誤解です。

ヘッドレスブラウザでSOCKS5を使えますか? はい、ほとんどのヘッドレスブラウザと自動化フレームワークはSOCKS5をサポートしていますが、設定方法は異なり、一部はよりすっきりしたHTTPサポートを持っています。単純なウェブ自動化では、HTTPの方が通常は扱いやすいです。特にSOCKS5が必要な場合にブラウザで使ってください。

ShifterはHTTPとSOCKS5で料金が異なりますか? いいえ。両方のプロトコルは同一のレジデンシャルゲートウェイ上で、同一のGB単位の料金で動作します。プロトコルの選択は純粋に技術的なものであり、課金にも、ターゲティングにも、プールへのアクセスにも影響しません。

socks5とsocks5hの違いは何ですか? socks5hはプロキシ側でDNSを解決します。プレーンなsocks5はまずあなたのマシン上で解決します。プロキシ利用の場合、DNSが出口地域で行われ、ローカルのリゾルバが対象のホスト名を決して見ないようにするため、ほぼ常にsocks5hが望ましいです。

HTTPプロキシは私のHTTPSトラフィックを見ますか? いいえ。HTTPSの場合、HTTPプロキシはCONNECTを介してトンネルを開き、暗号化されたトラフィックは読み取られることなく通過します。プロキシは(CONNECTから)宛先のホストとポートを把握していますが、ペイロードは把握していません。あなたのHTTPSはいずれにせよエンドツーエンドで暗号化されています。

結論

あなたがウェブ上で行うほぼ全てのことにおいて、HTTPとSOCKS5はどちらも機能し、HTTPはより摩擦の少ないデフォルトです。SOCKS5は、ウェブリクエストの範囲を超えたとき、UDPが必要なとき、あるいはツールがSOCKSをネイティブに話すときに、その存在価値を発揮します。どちらが「優れている」わけでもなく、それぞれが異なる仕事のために作られています。

そして重要なことに、どちらもブロックされる頻度を変えません。それはIPの品質と挙動によって決まるのであり、プロトコルによってではありません。ブロックが問題であるなら、答えはhttp://をsocks5h://に変えるスキームの切り替えではなく、より良いレジデンシャルネットワークとより賢いリクエストパターンです。

Shifterでは、両方のプロトコルが同一のゲートウェイ上に、同一のターゲティングと同一の価格で存在しているため、それぞれの仕事に合う方を使い、接続文字列の中の一語を変えるだけで切り替えられます。レジデンシャルプランから始めて、あなたのスタックが好む方法で接続してください。