HTTP and SOCKS5

HTTP and SOCKS5 share the same port, 58971. The gateway detects the protocol from the first TCP byte, so there is no port to choose.

Protocol detection

The gateway peeks at the connection's first byte:

• 0x05 → SOCKS5 handshake
• anything else → parsed as HTTP (CONNECT or ordinary forward)

# HTTP
curl -x 'http://USERNAME-country-US:PASSWORD@GATEWAY_HOST:58971' https://example.com

# SOCKS5, same port
curl -x 'socks5h://USERNAME-country-US:PASSWORD@GATEWAY_HOST:58971' https://example.com

How HTTPS sites are handled

Via an HTTP CONNECT transparent TCP tunnel:

1. The client sends CONNECT example.com:443
2. The gateway authenticates, routes, and opens the exit connection
3. The gateway replies HTTP/1.1 200 Connection Established
4. From there it is pure bidirectional TCP relay — the gateway neither parses nor rewrites anything inside the tunnel

So TLS is end-to-end between you and the target site, with certificate chain, SNI and ALPN untouched.

Ordinary HTTP forward mode

For http:// sites the client can skip CONNECT and put the absolute URL in the request line. In that case the gateway parses and rebuilds the request.

It accepts only http:// URLs:

# Works
curl -x 'http://USERNAME:PASSWORD@GATEWAY_HOST:58971' http://example.com

# Doesn't: an https absolute URL without CONNECT returns 400

Userinfo in the request line (http://user:pass@example.com/) is also rejected with 400.

Header handling in forward mode

In this mode the gateway rebuilds the request headers. Removed:

• Proxy-Authorization
• Proxy-Connection
• Every hop-by-hop extension header listed in Connection
• Connection, Keep-Alive, Proxy-Authenticate, TE, Trailer, Transfer-Encoding

Other behaviour:

• Non-Upgrade requests are forced to Connection: close
• Host and Content-Length are rebuilt when necessary
• Chunked bodies, trailers and Upgrade go through controlled reconstruction

Once a CONNECT tunnel or SOCKS5 connection is established, the gateway does not parse anything inside it and none of the above applies.

The limits of the SOCKS5 implementation

Supported

• CONNECT (CMD = 0x01)
• All three address types: IPv4, IPv6, domain name
• RFC 1929 username/password authentication (method 0x02)

Not supported

• UDP ASSOCIATE — returns 0x07 command not supported
• BIND — likewise 0x07
• Anonymous access (other than the passwordless ports described below)

About socks5h and DNS

The difference between socks5h:// and socks5:// is who resolves the hostname:

• socks5:// — the client resolves locally and sends an IP to the proxy
• socks5h:// — the client sends the hostname and the proxy resolves it

Using socks5h:// keeps your local DNS from revealing which domains you visit.

How SOCKS5 reports errors

SOCKS5 has no HTTP status codes; it uses negotiation responses and reply codes:

Unsupported address types return 0x08. Authentication can only report success or failure; temporarily use HTTP CONNECT to obtain a specific status and X-NextProxy-Error. See the error reference.

IPv6

IPv6 targets: supported. Both HTTP and SOCKS5 can parse IPv6 destinations.

curl -x 'http://USERNAME:PASSWORD@GATEWAY_HOST:58971' 'http://[2001:db8::1]/'

IPv6 client access: depends on the IPv6 configuration of the gateway node and load balancer; not guaranteed on every node.

Passwordless-port source binding accepts IPv4 only — see IP whitelist and passwordless ports.

Choosing between the two