How One Proxy Port Can Accept Both HTTP and SOCKS

A mixed proxy listener can accept HTTP and SOCKS on one TCP port because the server inspects the initial protocol bytes. The port number does not perform that detection.

An HTTP proxy request starts with an HTTP method, such as GET or CONNECT. A SOCKS greeting starts with binary protocol fields. Software designed for these inputs can dispatch the connection to the appropriate handler.

This is an explicit implementation feature. A normal Squid HTTP listener does not become mixed because its port is changed to 1080, and a SOCKS-only listener does not learn HTTP from a browser's setting.

TLS adds another boundary: an encrypted proxy connection begins with TLS, not a visible HTTP method. Supporting it on the same endpoint requires additional deliberate handling; recognizing plaintext HTTP and SOCKS does not establish that capability.

Use the client protocol documented for the endpoint. If both work, that is evidence about that server's mixed listener, not a reason to leave the protocol unspecified in every client.

Glider’s mixed listener provides a concrete example: it peeks at one byte without consuming it, dispatches 0x05 to its SOCKS5 handler, and otherwise invokes its HTTP parser. That parser still validates the incoming request; the dispatch choice does not make arbitrary input valid HTTP.

Sharing the TCP listener does not itself supply SOCKS5 UDP association. Glider starts its UDP listener separately. TCP protocol selection and the later datagram relay are separate capabilities.