Protocols

What is HTTP/2?

HTTP/2 is a binary version of HTTP that carries many concurrent requests as multiplexed streams over a single TCP connection and compresses headers with HPACK. It keeps HTTP's methods, status codes and header semantics unchanged, so only the wire format differs. Browsers negotiate it during the TLS handshake through ALPN, advertising the identifier h2.

Every message becomes a sequence of frames, among them HEADERS, DATA, SETTINGS and WINDOW_UPDATE, each tagged with a stream ID so streams can interleave on one connection. That ends the HTTP/1.1 habit of opening six or more sockets per origin and removes request-level head-of-line blocking. Packet loss still stalls everything, because TCP delivers in order and one missing segment holds up every stream riding above it. HPACK (RFC 7541) keeps a shared table of header names and values, so a repeated cookie or user-agent string costs a handful of bytes after the first request.

Browsers use HTTP/2 only over TLS and select it through ALPN during the handshake. Cleartext h2c is specified, but no browser ships it, so a server without a certificate is serving HTTP/1.1 whatever it claims. Server push was specified and shipped, then Chrome removed it once measurement showed it rarely helped, and the 103 Early Hints status took over that job. The original priority scheme proved complicated enough that most servers ignored it. RFC 9113 deprecated it in favour of a simpler header-based approach.

A proxy that only tunnels, whether SOCKS5 or HTTP CONNECT, never sees the frames, so HTTP/2 passes through untouched. A proxy that terminates requests has to speak HTTP/2 on both sides or downgrade the client to HTTP/1.1, and the downgrade is visible from the origin, since header casing normalises and the access log records h1 arriving from a client whose User-Agent claims a current Chrome. Anti-bot systems compare the protocol version against the browser the User-Agent claims to be.

The SETTINGS frame sent at the start of a connection carries values for header table size, maximum concurrent streams and initial window size, and implementations differ both in those numbers and in the order they emit pseudo-headers such as :method and :path. Together those differences form an HTTP/2 fingerprint that sits next to the TLS one. A scraping stack built on a library that speaks only HTTP/1.1 fails that check before anything looks at your headers or your IP address.

Where you meet it

HTTP/2 comes up when a request works in a browser and returns a 403 from your own code with the same headers through the same proxy. Check the negotiated protocol before anything else, because many HTTP clients still default to HTTP/1.1 unless you enable h2 explicitly. curl --http2 -v prints the ALPN result. Python's requests cannot speak HTTP/2 at all, which is why people move to httpx or curl_cffi for this work.

Common questions

Do proxies support HTTP/2?

Tunnelling proxies do by definition, since a CONNECT tunnel or a SOCKS5 relay passes encrypted bytes without parsing them, and ALPN happens inside that stream. Proxies that terminate and re-issue requests support it only if they were built for it; otherwise they quietly downgrade you to HTTP/1.1, which some sites treat as a signal.

Is HTTP/2 always faster than HTTP/1.1?

Usually, on pages with many small resources, because one connection carries everything and headers compress well. On a lossy link the single TCP connection can be slower, since one dropped segment blocks all streams while six separate HTTP/1.1 connections would only block one. HTTP/3 exists mainly to fix that case.

How does a site detect my HTTP/2 client?

It reads the SETTINGS values you send, the window sizes, the pseudo-header order and the way your client frames requests, then compares that profile with what your User-Agent claims to be. A Go or Python default stack looks nothing like Chrome. Combined with the TLS fingerprint, the pair identifies most automation.

Related terms

HTTP/3
HTTP/3 is HTTP carried over QUIC, which runs on UDP and builds the TLS 1.3 handshake into the transport itself. It keeps HTTP semantics and HTTP/2-style multiplexing while removing TCP's head-of-line blocking, so a lost packet stalls only its own stream. Clients discover it from an Alt-Svc header or an HTTPS DNS record and negotiate it as h3.
QUIC
QUIC is an encrypted transport protocol that runs over UDP instead of TCP and carries HTTP/3 traffic, normally on UDP port 443. It combines the transport and TLS 1.3 handshakes into one exchange and multiplexes independent streams without head-of-line blocking. The protocol identifies a connection by an ID rather than by an address and port pair.
HTTP Proxy
An HTTP proxy is a server that forwards HTTP requests on a client's behalf, parsing the protocol rather than blindly relaying bytes. The client sends the full target URL in the request line, or issues a CONNECT to tunnel an HTTPS session. Proxies conventionally listen on ports such as 8080 or 3128; port 80 belongs to the origin web server.
HTTPS Proxy
An HTTPS proxy carries encrypted TLS traffic between a client and a destination site, usually by opening a tunnel with the HTTP CONNECT method to port 443. The proxy relays raw bytes without reading the request path, headers or body. The term also describes a proxy whose own listening port accepts a TLS-encrypted client connection.
SOCKS5
SOCKS5 is a session-layer proxy protocol, defined in RFC 1928, that relays TCP connections and can relay UDP datagrams for any application rather than only web traffic. It negotiates an authentication method first, then takes a target given as an IPv4 address, an IPv6 address or a domain name and forwards bytes without interpreting them.
SOCKS4
SOCKS4 is the earlier version of the SOCKS proxy protocol. It relays TCP connections only and addresses targets by raw IPv4 address, with no authentication beyond a user ID string the proxy may ignore. The SOCKS4a extension adds hostname support. SOCKS5 superseded it, and current clients keep SOCKS4 only for legacy endpoints.
SSL/TLS
SSL and TLS are the protocols that encrypt and authenticate traffic between a client and a server. SSL is the deprecated original; TLS is what runs today, with TLS 1.2 and TLS 1.3 the only versions current software should negotiate. The handshake proves the server's identity with a certificate, then agrees the keys used for the session.

Real 4G/5G mobile and residential IPs

PROXIES.SX runs carrier IPs in 100+ countries with HTTP and SOCKS5 on every endpoint. $4/GB down to $2.40/GB at volume, free endpoints and rotation, and your GB never expire.

View pricing Browse the glossary