Protocols and limits

The proxy supports HTTP forward requests, HTTP CONNECT tunnels, and authenticated SOCKS5 CONNECT tunnels over TCP. Destination hostnames are resolved by the selected exit. Connection and capacity settings depend on the environment serving your assigned endpoint.

Supported proxy operations

Operation	Behavior
HTTP forward proxy	Send an absolute-form URL such as http://example.com/path
HTTP CONNECT	Open a bidirectional TCP tunnel to a host:port destination
SOCKS5 CONNECT	Open a TCP tunnel using username/password authentication and a destination hostname
HTTPS destination	Establish an HTTP or SOCKS5 tunnel, then negotiate TLS with the destination
SOCKS4, SOCKS5 BIND	Unsupported
UDP, SOCKS5 UDP ASSOCIATE	Unsupported

Proxy transport and destination TLS

Configure the client with the endpoint assigned for its proxy transport, including the port:

Proxy URL format	Client behavior
http://HOST:PORT	HTTP proxy connection over plaintext TCP
https://HOST:PORT	HTTP proxy connection protected by TLS
socks5h://HOST:PORT	SOCKS5 connection over plaintext TCP, with destination DNS delegated to the proxy

These are URL formats, not usable endpoints. Use your assigned hostname and port. The SOCKS endpoint can use a different port from the HTTPS proxy endpoint; changing only an https:// URL’s scheme does not configure the correct SOCKS transport.

socks5h is the remote-DNS setting used by curl and Python Requests. Other libraries may provide a separate setting or an agent that always sends hostnames. SOCKS5 over TLS requires explicit client support and the assigned TLS endpoint; socks5h:// alone does not enable it. See the JavaScript guide for the agent configuration used there.

An HTTPS destination URL protects traffic between the application and destination after the tunnel opens. It does not by itself protect the client-to-proxy authentication exchange. Keep certificate verification enabled for every TLS connection.

The initial HTTP proxy request is HTTP/1.0 or HTTP/1.1. An established HTTP or SOCKS5 tunnel carries the destination protocol, including a client’s TLS-negotiated HTTP version.

HTTP forward requests

GET http://example.com/path HTTP/1.1
Host: example.com
Proxy-Authorization: Basic <encoded-credentials>

The gateway forwards one complete HTTP request per forward-proxy connection and closes the connection after its response. HTTP pipelining and subsequent requests on that same connection are not forwarded. Because each forward request opens its own connection, v1_rotate selects an exit for each one.

Request bodies require valid Content-Length or HTTP/1.1 Transfer-Encoding: chunked framing. Duplicate framing headers, simultaneous content length and transfer encoding, and unsupported transfer encodings are rejected. Expect: 100-continue is supported.

Proxy credentials are removed from the forwarded request head, and so are Upgrade headers. CONNECT is required when your application needs a persistent bidirectional tunnel rather than a single HTTP exchange, including WebSocket connections.

CONNECT tunnels

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic <encoded-credentials>

On successful setup, the proxy responds with 200 Connection Established. Subsequent bytes are passed through the selected exit. Multiple destination requests inside that tunnel use the same exit.

Tunnels can end because of origin or client disconnects, network failure, or transfer deadlines. Applications should handle disconnects without assuming an established request was replayed.

SOCKS5 tunnels

Use SOCKS5 username/password authentication: the username is a routing policy such as v1_rotate, and the password is the complete proxy key. The gateway requires this method; anonymous SOCKS5 and SOCKS4 are refused. HTTP and SOCKS5 use the same routing usernames, key verification, session bindings, and usage measurements.

The CONNECT request must carry a hostname. With curl or Requests, configure socks5h:// so the client passes that hostname to the proxy. Their socks5:// mode resolves the destination locally and sends an IP address, which the gateway rejects. An IP-literal destination is also rejected when remote DNS is enabled.

A successful SOCKS5 CONNECT reply opens a bidirectional TCP tunnel. Subsequent bytes pass through the selected exit, and requests that reuse the tunnel use the same exit. BIND and UDP ASSOCIATE are refused with command-not-supported replies. See Troubleshooting for the handshake and reply codes.

Format limits

Input	Current limit
Proxy username	1 to 255 UTF-8 bytes
Proxy password	1 to 255 UTF-8 bytes
Destination hostname	At most 253 ASCII bytes after IDN conversion; each label at most 63 bytes
Initial HTTP request head	64 KiB
Headers in the initial request	At most 64
Key display name	1 to 80 characters after trimming; no control characters
Key expiration	30 days, 90 days, 1 year, or no expiration

The full key secret is required. Truncating it to fit another integration’s field will make authentication fail.

Destinations

Supply a destination hostname, not an IPv4 or IPv6 literal, in HTTP forward URLs, HTTP CONNECT authorities, and SOCKS5 CONNECT requests. This restriction concerns the destination, not the assigned proxy’s own address.

Exits resolve the hostname and apply policy to the resulting socket addresses before connecting. By default, loopback, private networks, link-local addresses, shared address space, multicast, reserved and documentation ranges, and certain IPv6 special-purpose ranges are blocked. Port zero is rejected.

The service can apply additional destination restrictions. A hostname resolving only to disallowed addresses will fail; an application cannot bypass this policy with a username clause.

Connection and capacity settings

The gateway enforces limits on concurrent connections, connections per source IP, and new connection rate. Clients sharing a NAT can share source-IP limits. Capacity refusals can close a connection before its proxy handshake completes.

HTTP CONNECT and SOCKS5 tunnels are subject to a 10-minute inactivity deadline and a 2-hour lifetime deadline. An HTTP forward request has 10 minutes to send its request body, and the whole exchange ends after 2 hours. Your assigned environment’s surrounding infrastructure can impose shorter deadlines.

The initial HTTP request head or the full SOCKS5 negotiation, authentication, and CONNECT request must finish within the environment’s setup deadline. All SOCKS5 handshake steps share that deadline.

Key validity is checked during connection setup. Revocation, expiration, or disabling a workspace blocks new connections; an already established tunnel is not automatically closed by those changes. See key lifecycle for propagation behavior.

Confirm the effective limits for your assigned environment before sizing production workloads. This documentation does not define a plan quota or a guaranteed concurrency level. Use bounded concurrency, deliberate connection reuse, and limited retries with backoff. See Troubleshooting for failure behavior.