HTTP/3 is already enabled on Google Cloud Load Balancers by default, and you don’t need to do anything to "turn it on."
Let’s see it in action. Imagine you have a simple backend service running on Compute Engine, and you’ve fronted it with a Global External HTTP(S) Load Balancer.
# First, create a simple backend instance
gcloud compute instances create http3-test-vm \
--zone=us-central1-a \
--machine-type=e2-medium \
--image-family=debian-11 \
--image-project=debian-cloud \
--tags=http-server
# Install a simple web server (nginx) and configure it to serve a placeholder page
gcloud compute ssh http3-test-vm --zone=us-central1-a --command="sudo apt update && sudo apt install -y nginx"
gcloud compute ssh http3-test-vm --zone=us-central1-a --command="echo '<h1>HTTP/3 Test Page</h1>' | sudo tee /var/www/html/index.html"
gcloud compute ssh http3-test-vm --zone=us-central1-a --command="sudo systemctl enable nginx && sudo systemctl start nginx"
# Create a firewall rule to allow HTTP traffic
gcloud compute firewall-rules create allow-http \
--allow tcp:80 \
--source-ranges=0.0.0.0/0 \
--target-tags=http-server \
--description="Allow HTTP traffic"
# Create a backend service
gcloud compute backend-services create http3-backend-service \
--protocol=HTTP \
--port-name=http \
--health-checks-region=us-central1 \
--global
# Add the instance to the backend service
gcloud compute backend-services add-backend http3-backend-service \
--instance-group=http3-test-vm-ig \
--instance-group-zone=us-central1-a \
--global
# Create a URL map
gcloud compute url-maps create http3-url-map \
--default-service=http3-backend-service
# Create an SSL certificate (self-signed for this example, use a proper one in production)
gcloud compute ssl-certificates create http3-self-signed-cert \
--domains=localhost \
--global
# Create a target HTTPS proxy
gcloud compute target-https-proxies create http3-https-proxy \
--ssl-certificates=http3-self-signed-cert \
--url-map=http3-url-map \
--global
# Create a global forwarding rule for HTTPS (port 443)
gcloud compute forwarding-rules create http3-https-forwarding-rule \
--address=ANY_GLOBAL_ADDRESS \
--ports=443 \
--target-https-proxy=http3-https-proxy \
--global
# Create a global forwarding rule for HTTP (port 80) - this will also serve HTTP/3
gcloud compute forwarding-rules create http3-http-forwarding-rule \
--address=ANY_GLOBAL_ADDRESS \
--ports=80 \
--target-http-proxy=http3-url-map \
--global
# Get the IP address of the load balancer
LOAD_BALANCER_IP=$(gcloud compute addresses describe ANY_GLOBAL_ADDRESS --global --format='value(address)')
echo "Load Balancer IP: $LOAD_BALANCER_IP"
Now, if you try to access https://LOAD_BALANCER_IP (you’ll need to configure your /etc/hosts or DNS for this to work with localhost) or http://LOAD_BALANCER_IP from a browser that supports HTTP/3 (like Chrome or Firefox), you’ll likely be served over HTTP/3. You can verify this in your browser’s developer tools under the "Network" tab, looking at the "Protocol" column.
The magic behind HTTP/3 on Google Cloud Load Balancers isn’t a switch you flip. It’s the underlying infrastructure and the way Google Cloud’s Global External HTTP(S) Load Balancers are designed. These load balancers are built on Google’s global network, which has been evolving to support QUIC (the transport protocol for HTTP/3) for years. When a client initiates a connection to your load balancer, the load balancer negotiates the protocol. If the client supports HTTP/3 and QUIC, and the load balancer’s infrastructure is configured to handle it (which it is, by default, for these services), it will use QUIC to establish the connection and then serve HTTP/3. The load balancer intelligently handles the protocol negotiation and routing without you needing to explicitly configure HTTP/3 itself.
The key insight here is that Google Cloud’s managed load balancers abstract away the complexities of transport protocols. They are designed to offer the latest and most efficient protocols to clients automatically. Your role is to configure the load balancer to route traffic to your backends, and the load balancer itself handles the protocol negotiation with the end-user.
What most people don’t realize is that the target-http-proxy and target-https-proxy resources in Google Cloud are actually capable of serving HTTP/3 traffic when exposed via a Global External HTTP(S) Load Balancer. You don’t create a separate target-http3-proxy. The existing proxy resources, when configured with a Global External HTTP(S) Load Balancer, will automatically negotiate and serve HTTP/3 if the client supports it. The load balancer’s edge network is equipped to handle QUIC connections, which are the foundation of HTTP/3.
The next thing you’ll likely want to explore is how to monitor QUIC and HTTP/3 traffic statistics for your load balancer.