「プロキシ」とラベル付けされた4つのプロトコルは、名前以外に共通点はほとんどありません。HTTPプロキシはレイヤ7を解析してヘッダーを書き換えますが、SOCKSプロキシはトラフィックを一切読み取りません。この違いによって、ブラウジング、スクレイピング、生のトンネリングにどのプロキシが適しているかが決まります。
HTTPプロキシ
HTTPプロキシはHTTPセマンティクスを前提とします。リクエストを開き、URLを読み取り、ViaやX-Forwarded-Forのようなヘッダーを付加でき、有効なHTTPリクエストでないものは拒否します。ブラウザ、curl、そしてほとんどのスクレイピングライブラリは、設定がほぼ無料であるため（単一の環境変数を設定するかフラグを渡すだけ）、デフォルトでHTTPプロキシを使用します。
その単純さの代償は可視性です。プロキシはパスやクエリ文字列を含む完全なURLを参照し、平文HTTPではボディも参照します。キャッシュプロキシはレスポンスを書き換えることができ、透過プロキシはクッキーを削除できます。HTTPプロキシは完全に特権を持つ中間者として扱い、平文で認証情報を送信してはいけません。
HTTPSプロキシとCONNECTメソッド
「HTTPSプロキシ」というラベルはやや誤解を招きます。これは、CONNECTメソッドを追加で実装したHTTPプロキシを指します。CONNECTはプロキシに対して、ターゲットホストへの生のTCPトンネルを開き、双方向でバイトを転送するよう指示します。その後、クライアントと宛先はプロキシが存在しないかのようにTLSをネゴシエーションします。プロキシは宛先ホストとポート、およびバイト量を参照しますが、ペイロードは参照しません。
したがって、「HTTPS対応」プロキシとは、TLSトンネリングをサポートするプロキシであり、それ自体がTLS上で動作するプロキシではありません。マシンからプロキシへのリンクは、独立して平文または暗号化できます。そのリンクが保護されることを重視する場合は、SOCKS5-over-TLS実装か、TLSエンドポイントを公開している有料商用プロキシを使用してください。
SOCKS4
SOCKS4は1994年の最小限のプロトコルです。TCPのみ、IPv4のみ、UDPなし、IPv6なし、認証なし、プロキシでのホスト名解決なし。ハンドシェイクは6バイトと1バイトのレスポンスコードです。プロトコルが非常に小さいため、TCP対応のツールならほぼ正しく実装できることから、今でも使われています。リストにSOCKS4と記載されている場合、IPv4アドレスへの生のTCP転送のみを期待してください。それ以外はありません。
SOCKS5
RFC 1928 (1996) で定義されたSOCKS5は、最新のツールが使用するバージョンです。UDP転送、IPv6アドレス、GSSAPI認証、およびクライアントではなくプロキシでホスト名を解決するオプションが追加されています。SOCKS5は上位のアプリケーション層について何も仮定しないため、SSH、IRC、BitTorrent、カスタムRPCなどの非HTTPワークロードに最も柔軟な選択肢です。
パフォーマンスとオーバーヘッド
SOCKSプロキシは何も解析しないため、リクエストあたりのオーバーヘッドが低くなります。HTTPおよびHTTPSプロキシは、接続ごとに完全なリクエスト解析のコストがかかります。CONNECT内の単一の長期間TLSセッションでは、その差は無視できます。プロキシが毎回新しい接続を開く数千の短いリクエストの場合、SOCKS5が明確に勝ります。通常、解析パスでリクエストあたり2～5ミリ秒の差です。
匿名性の実際
ヘッダーを削除しないHTTPプロキシは、Via、X-Forwarded-For、またはForwardedを介してクライアントIPを漏洩する可能性があります。SOCKSプロキシにはヘッダーの概念がないため、そのようなヘッダーはありません。これは匿名性機能というよりも、漏洩面が存在しないということです。CONNECTでトンネリングされたHTTPS内では、宛先はTLSハンドシェイクしか見ないため、プロキシでのHTTPレベルの漏洩は意味がありません。
ポートの慣例
このディレクトリでは、HTTP用に80、8080、3128、8888、CONNECTを明示的にサポートするエンドポイント用に443、SOCKS用に1080が表示されます。多くのプロバイダーは、カジュアルなポートスキャンを回避するために、非標準のハイポート（10,000以上）を公開しています。ポート番号は品質について何も示しません。オペレーターが公開することを選択したシグナルにすぎません。