ALPN (Application-Layer Protocol Negotiation) (ALPN)

Protocol

A TLS extension that allows the client and server to negotiate which application protocol (HTTP/1.1, h2, h3) to use during the TLS handshake without extra round trips.

Updated Mar 17, 2026

Full Explanation

ALPN is a TLS extension (RFC 7301) that lets client and server agree on an application protocol during the TLS handshake itself. Without ALPN, you'd need an extra round trip after the TLS connection is established to figure out whether both sides support HTTP/2 or should fall back to HTTP/1.1.

During the ClientHello, the client sends a list of protocols it supports in order of preference. Common values are h2 (HTTP/2), http/1.1 (HTTP/1.1), and h3 (HTTP/3, though this is negotiated differently via Alt-Svc). The server picks the best match from its own supported list and includes the chosen protocol in the ServerHello.

For CDNs, ALPN is how HTTP/2 adoption actually works in practice. When a browser connects to a CDN edge, the TLS handshake includes ALPN negotiation. If both sides support h2, great, they use HTTP/2 with multiplexing and header compression. If the edge or client doesn't support h2, they fall back to http/1.1 gracefully. No broken connections, no extra latency.

ALPN replaced an older mechanism called NPN (Next Protocol Negotiation) that was a Google-specific extension used during the SPDY era. The key difference is that with NPN, the client made the final protocol selection, while with ALPN, the server makes the choice. This is better because the server knows its own capabilities and load characteristics.

One important CDN use case: ALPN is also used for the ACME TLS-ALPN-01 challenge. The ACME protocol defines a special ALPN value (acme-tls/1) that certificate authorities use to validate domain ownership through the TLS handshake. This lets CDNs complete certificate issuance without needing port 80 or DNS access.

When troubleshooting HTTP/2 issues, checking ALPN is one of the first things to do. If a CDN edge is supposed to serve h2 but clients are getting http/1.1, the ALPN negotiation is where it breaks down. Maybe the TLS termination proxy doesn't advertise h2, or maybe an intermediate load balancer strips ALPN. The openssl s_client command shows you exactly what was negotiated.

Examples 

# Check ALPN negotiation with openssl
openssl s_client -alpn h2,http/1.1 -connect example.com:443 \
  -servername example.com 2>/dev/null | grep -i alpn
# ALPN protocol: h2

# Check with curl (verbose shows protocol)
curl -vso /dev/null https://example.com 2>&1 | grep ALPN
# * ALPN: offers h2,http/1.1
# * ALPN: server accepted h2

# Nginx configuration for ALPN/HTTP2
server {
    listen 443 ssl;
    http2 on;
    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    # Nginx automatically advertises h2 and http/1.1 via ALPN
}

# Check negotiated protocol with curl
curl -w '%{http_version}\n' -so /dev/null https://example.com
# 2  (means HTTP/2)

Frequently Asked Questions

A TLS extension that allows the client and server to negotiate which application protocol (HTTP/1.1, h2, h3) to use during the TLS handshake without extra round trips.

# Check ALPN negotiation with openssl
openssl s_client -alpn h2,http/1.1 -connect example.com:443 \
  -servername example.com 2>/dev/null | grep -i alpn
# ALPN protocol: h2

# Check with curl (verbose shows protocol)
curl -vso /dev/null https://example.com 2>&1 | grep ALPN
# * ALPN: offers h2,http/1.1
# * ALPN: server accepted h2

# Nginx configuration for ALPN/HTTP2
server {
    listen 443 ssl;
    http2 on;
    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    # Nginx automatically advertises h2 and http/1.1 via ALPN
}

# Check negotiated protocol with curl
curl -w '%{http_version}\n' -so /dev/null https://example.com
# 2  (means HTTP/2)

Related CDN concepts include:

Previous Term Age Header
Next Term Anycast
Back to Glossary