Protocols

What is 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.

Google shipped an experimental version in Chrome in 2013, and the IETF published the standardised protocol as RFC 9000 in 2021, with the TLS binding in a companion document. The design goal was to move the parts of TCP that are hard to change out of operating-system kernels and into user space, where a browser or a server library can update them on its own release schedule. Almost everything below the HTTP layer is encrypted, including packet numbers, so a middlebox on the path sees a version field, a connection ID and ciphertext.

A QUIC connection carries many independent streams. Loss on one stream stalls only that stream, unlike HTTP/2 over TCP, where a single missing segment holds up every multiplexed request queued behind it. Because connections are named by a connection ID, a phone that moves from Wi-Fi to LTE keeps its session instead of renegotiating from scratch. Session resumption can attach application data to the first flight, which saves a round trip but exposes that early data to replay, so servers restrict what they will accept in it.

Proxy support is where this becomes practical work. An HTTP proxy tunnels a TCP stream through CONNECT and has no way to carry UDP datagrams, and although SOCKS5 defines a UDP ASSOCIATE command, few commercial endpoints implement it. Browsers cope by falling back. When UDP port 443 fails or a proxy is configured, Chrome and Firefox retry the request over HTTP/2 on TCP. The IETF's MASQUE work defines a CONNECT-UDP method for proxying datagrams over HTTP, which is the standards-track way for a proxy to carry QUIC end to end once both sides support it.

QUIC's Initial packets carry a TLS ClientHello, so the fingerprinting that applies to TLS over TCP applies here with extra material attached. Transport parameters, packet layout and frame ordering differ between the QUIC stacks in Chrome, Firefox, curl and Go, and the JA4 fingerprint family marks a QUIC connection separately from a TCP one. A client that advertises a Chrome user agent while speaking a Go QUIC stack is easy to separate from a real browser.

Where you meet it

You usually meet QUIC as a discrepancy. Your browser loads a site over HTTP/3 and behaves one way; the same request from your scraping stack goes out over TCP and gets a different response or a different challenge. Teams working through proxies often pin traffic to TCP on purpose, disabling HTTP/3 in the browser or the client library, so every request follows the same path and exits from the address they are paying for.

Common questions

Does QUIC run over TCP or UDP?

UDP. A QUIC connection is a series of UDP datagrams, normally on port 443, with reliability, ordering and congestion control implemented inside the protocol rather than borrowed from TCP. Networks that block or rate-limit UDP push clients back to TCP, which is why HTTP/3 disappears without warning on some corporate and hotel links.

Why does HTTP/3 stop working when I turn on a proxy?

Standard HTTP and SOCKS proxies are built around TCP. CONNECT tunnels a TCP stream, and most SOCKS5 endpoints never enable the UDP ASSOCIATE command, so QUIC datagrams have no route through them. The browser detects the failure and retries over HTTP/2 on TCP, which does traverse the proxy.

Is QUIC more anonymous than HTTPS over TCP?

No. QUIC encrypts more of the transport header, so a passive observer on the path learns less about packet numbering and connection state. The destination still records your exit address, and the ClientHello inside the first packets fingerprints your client. Anonymity comes from the proxy path, not from the transport.

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.
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.
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.

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