1つのプロキシポートがHTTPとSOCKSの両方を受け付けられる仕組み

混在プロキシリスナーが1つのTCPポートでHTTPとSOCKSを受け付けられるのは、サーバーが先頭のプロトコルバイトを検査するからです。ポート番号がその判定を行っているわけではありません。

HTTPプロキシのリクエストは、GETやCONNECTといったHTTPメソッドで始まります。SOCKSの挨拶はバイナリのプロトコルフィールドで始まります。これらの入力向けに設計されたソフトウェアは、接続を適切なハンドラーに振り分けられます。

これは明示的な実装上の機能です。通常のSquidのHTTPリスナーは、ポートを1080に変えても混在にはなりません。SOCKS専用のリスナーも、ブラウザーの設定からHTTPを学ぶことはありません。

TLSはもう一つの境界を加えます。暗号化されたプロキシ接続はTLSで始まり、目に見えるHTTPメソッドでは始まりません。同じエンドポイントでこれを支えるには、追加の意図的な処理が必要です。平文のHTTPとSOCKSを認識できても、その能力が証明されるわけではありません。

エンドポイントに文書化されているクライアントプロトコルを使用してください。両方が機能するなら、それはそのサーバーの混在リスナーに関する証拠であり、すべてのクライアントでプロトコルを未指定のままにする理由にはなりません。

Gliderの混在リスナーは具体的な例です。1バイトを消費せずに覗き、0x05をSOCKS5ハンドラーへ送り、それ以外の場合はHTTPパーサーを呼び出します。そのパーサーは受信リクエストを依然として検証します。振り分けの選択が、任意の入力を有効なHTTPにするわけではありません。

TCPリスナーを共有すること自体は、SOCKS5のUDPアソシエーションを提供しません。GliderはUDPリスナーを別に起動します。TCPのプロトコル選択と、その後のデータグラムの中継は別々の機能です。