HTTP と SOCKS5：どのプロキシ IP を選ぶべきか

まずアプリケーションのプロキシ設定を開きます。使える一覧項目は、アプリケーションの対応プロトコルで決まります。立派なラベルや見慣れたポート番号があっても、クライアントの対応機能は増えません。

ウェブや API のリクエストには、HTTP プロキシで足りることがよくあります。HTTP を転送し、許可されていれば CONNECT で HTTPS を運びます。通常の HTTP ページに接続できてもトンネル対応の証明にはなりません。サービスはトンネル認証を求めたり、宛先やポートを制限したりできます。

SOCKS は HTTP リクエスト層より下で動作します。対応アプリケーションは HTTP リクエストの解釈を伴わずに接続を確立するよう依頼できるため、ほかの対応通信にも使えます。SOCKS5 は IPv4、IPv6、ドメイン名のアドレス、認証、UDP アソシエーションを定義します。特定のアプリケーションや無料接続先は、一部しか実装していない場合があります。ブラウザーの TCP SOCKS 経路が、別のアプリケーションや UDP サービスも自動でカバーするわけではありません。

宛先名はどこで解決されるか

curl ではSOCKS5 URL の表記で宛先 DNS の処理場所が決まります。socks5:// は宛先をローカルで解決し、socks5h:// はプロキシに解決を依頼します。DNS の見え方が違うため、一方が動いて他方が失敗することがあります。ほかのクライアントはチェックボックスや独立したオプションを使う場合があります。SOCKS5 を選んだだけでは、すべての DNS 検索がそこを通るとは確認できません。

SOCKS4 の機能は少なく、SOCKS4a はホスト名処理を追加します。クライアントとサービスがともに SOCKS5 に対応し、古いプロトコルを使う理由がなければ、適切な SOCKS5 項目から試すのが妥当です。クライアントを SOCKS5 モードにしたまま SOCKS4 接続先を入れると、プロトコルが一致しません。

プロトコルが合ったら実際の宛先を試し、最初の失敗を特定します。HTTP も SOCKS5 も匿名性の指標ではありません。運営者への信頼、宛先の TLS、アプリケーションの実際の経路が、得られる保護を引き続き左右します。