Application-Layer Protocol Negotiation (ALPN) lets a client and server agree on the application protocol while establishing a secure connection. It operates within a Transport Layer Security (TLS) handshake: the client offers supported protocol identifiers, and the server selects a compatible one. For HTTPS, the selected identifier might be h2 for HTTP/2 or h3 for HTTP/3.

HTTP/2 over HTTPS uses Transmission Control Protocol (TCP), while HTTP/3 uses QUIC over the User Datagram Protocol (UDP). ALPN negotiates within the connection being established. It does not discover an HTTP/3 endpoint or turn an existing TCP connection into a UDP connection.

The Client Offers Protocols, and the Server Selects One

A client lists its supported application protocols in the ClientHello's ALPN extension, in preference order. The server examines that offer together with its own capabilities and policy, then returns one selected identifier.

The response is a single choice, not the server's entire capability list. Both endpoints must use the selected protocol when they exchange application data. A server cannot agree to HTTP/2 and then send an ordinary HTTP/1.1 response on that same negotiated connection.

The client's first choice does not compel the server to select it. The server can apply its own protocol preference, but it must select a protocol the client offered. For example, a client can offer h2 and http/1.1 while a server configured to serve only HTTP/1.1 selects http/1.1.

Offering a protocol also does not implement it. A client that advertises h2 needs to understand HTTP/2 framing, and a server selecting h2 needs an HTTP/2 handler for the connection. The selected identifier tells both implementations which protocol to use.

Read the Identifiers as Protocol Names

The common HTTPS identifiers are short tokens with specific meanings. They are distinct from the longer names shown in product descriptions or browser settings:

  • http/1.1 identifies HTTP/1.1.
  • h2 identifies HTTP/2 over TLS.
  • h3 identifies HTTP/3, which uses QUIC.

A negotiated token describes the application protocol, rather than the TLS version or cipher suite. Seeing h2 does not tell you whether the connection negotiated TLS 1.2 or TLS 1.3. Those security properties are recorded separately.

The same separation applies to HTTP/3 and QUIC versions. HTTP/3 is an application mapping over QUIC, while the QUIC version describes the transport. The server must choose an application protocol compatible with the QUIC version in use, but an h3 result is not itself a QUIC version number.

ALPN is also used outside web browsing. Other secure applications have their own identifiers, so an ALPN extension is not automatically evidence of an HTTP connection.

HTTP/2 Negotiates within TLS over TCP

For an HTTPS HTTP/2 connection, the client establishes TCP and negotiates TLS with an ALPN offer that includes h2. If the server supports HTTP/2 for that connection and selects h2, the endpoints proceed with HTTP/2 after the TLS negotiation.

After ALPN selects h2, each endpoint sends an HTTP/2 connection preface that includes a SETTINGS frame. These opening messages confirm HTTP/2 and communicate the initial connection settings.

This choice does not depend on an HTTP response header announcing that the current response is HTTP/2. By the time an encrypted HTTP request is sent, the endpoints already need to agree on how its bytes will be framed. Otherwise, an HTTP/1.1 parser and an HTTP/2 parser would interpret the stream differently.

A server can support HTTP/1.1 and HTTP/2 on the same TCP port because the handshake distinguishes their use. Port 443 alone cannot tell an observer which one was selected.

HTTP/3 Negotiates inside a QUIC Handshake

An HTTP/3 attempt starts with a QUIC connection over UDP. QUIC uses the TLS 1.3 handshake for security and includes application protocol negotiation in that exchange. Selecting h3 establishes that the endpoints will use the HTTP/3 mapping on the QUIC connection.

TLS and QUIC cooperate differently from TLS over TCP. QUIC carries TLS handshake data in its own CRYPTO frames and protects its packets using keys derived from that handshake. It does not place the ordinary TLS record layer on top of a UDP socket.

By the time the server selects h3, the client is already attempting a QUIC connection. The ALPN response confirms HTTP/3 on that connection; it does not switch a TCP connection to QUIC.

A QUIC connection may support application protocols besides HTTP/3, provided the endpoints implement compatible mappings. Successful QUIC negotiation without an h3 selection would therefore not, by itself, establish an HTTP/3 connection. The transport and application results must be interpreted together.

How Does the Client Find an HTTP/3 Endpoint?

The client can learn about an HTTP/3 endpoint through information outside the connection's ALPN exchange, such as an Alt-Svc advertisement or a supported HTTPS DNS record. That information guides where and how to attempt a connection. ALPN then confirms the application protocol within the resulting handshake.

An Alt-Svc response can advertise an alternative host or port associated with h3. The client can establish a separate QUIC connection to that destination while continuing to use an existing connection. The alternative endpoint serves the same origin even if its host or port differs.

An HTTPS DNS record can advertise h2 or h3 and provide connection details for the endpoint. The record's alpn parameter helps a compatible client identify possible transports before connecting. That DNS parameter is discovery information; it is not the server's negotiated ALPN response.

The handshake still selects from the client's offer for the chosen transport. A DNS advertisement does not force that selection, and merely publishing h3 in an advertisement does not make a nonfunctional UDP endpoint work. The client must be able to reach an endpoint that actually serves the advertised protocol.

This explains a common source of confusion: h3 can appear in an HTTP header or DNS response even when the current request used HTTP/2. The advertisement describes an available alternative. The request's actual protocol describes the connection that carried it.

Protocol Selection, Authentication, and Connection Failures

ALPN answers which application protocol the endpoints agree to use. Server Name Indication, or SNI, conveys the intended server name during the handshake. Certificate validation checks whether the server's certificate is valid for the requested origin and trusted by the client.

Those mechanisms can influence the same connection without serving the same purpose. A hosting endpoint might use the indicated hostname to choose a configuration with its own application protocol policy. Selecting h2 or h3 does not remove the requirement to authenticate the destination correctly.

An ALPN-aware server that has no compatible protocol in the client's offer reports a no_application_protocol failure. This differs from a server selecting http/1.1 when the client offered it and the server supports it. The latter is a successful protocol agreement, even if the client preferred HTTP/2.

QUIC can also fail before application protocol negotiation reaches a useful result. If UDP traffic cannot reach the endpoint, no ALPN choice can repair that transport path. A client may attempt HTTPS over TCP instead, where a separate TLS handshake negotiates HTTP/2 or HTTP/1.1.

That separate attempt should be described as a different connection. It does not mean that h3 changed into h2 within one handshake, and it does not prove that TLS authentication or encryption was downgraded. The established connection's own security properties determine that question.

Look at the Actual Request and Handshake

In Chrome DevTools, the Network panel's Protocol column identifies the protocol used for each request. It can show values such as h2 and h3. The column can be added from the request table's header menu, rather than inferred from an advertisement in the response.

Inspect the relevant request, not just the page's main document. A page can fetch resources from several origins with different connections and capabilities. An image served over HTTP/3 does not establish that the HTML document also used HTTP/3.

For handshake-level evidence, distinguish the client's offered identifiers from the server's selected identifier. A trace showing h2 in a ClientHello proves only that HTTP/2 was offered. The selected protocol and the subsequent application exchange establish what the endpoints actually used.

An independent diagnostic client can also make a different offer from the browser. Its build, transport support, and protocol options affect the attempt. A result obtained from that client should not be treated as a browser result without checking those conditions.

Each Connection Leg Has Its Own Result

A reverse proxy or content delivery network (CDN) can terminate the browser's secure connection and open a separate connection to an origin server. Those endpoints negotiate independently. The browser-facing result may be h3 even when the upstream service uses another HTTP version.

For example, Cloudflare's HTTP/3 setting applies to the connection between the client and its edge. It does not enable an HTTP/3 connection to the origin. Reading the edge and origin results as one continuous ALPN negotiation would misdescribe that deployment.

The same distinction helps interpret application logs. A record generated at the origin may describe the proxy's request, not the browser's transport. Identifying which component terminated the connection is necessary before using that record to explain a browser's protocol choice.

Browser performance entries can expose the resource's nextHopProtocol value as an ALPN-style identifier. Cross-origin access restrictions can leave that value empty unless the response permits the timing information to be shared. An empty value alone does not establish whether ALPN was used.