Setting Up HTTP(S) Load Balancing

This document is the first step in setting up an HTTP(S) load balancer. Before you start, make sure that you are familiar with overall HTTP(S) Load Balancing concepts.

Google Cloud Platform (GCP) HTTP(S) Load Balancing provides global load balancing for HTTP(S) requests destined for your instances.

Global load balancing requires that you use the Premium Tier of Network Service Tiers.

You can configure URL rules that route some URLs to one set of instances and route other URLs to other instances. Requests are always routed to the instance group that is closest to the user, provided that group has enough capacity and is appropriate for the request. If the closest group does not have enough capacity, the request is sent to the closest group that does have capacity.

HTTP(S) Load Balancing supports both IPv4 and IPv6 addresses for client traffic. Client IPv6 requests are terminated at the load balancing layer, then proxied over IPv4 to your backends.

HTTP requests can be load balanced based on port 80 or port 8080. HTTPS requests can be load balanced on port 443.

The load balancer acts as an HTTP/2 to HTTP/1.1 translation layer, which means that the web servers always see and respond to HTTP/1.1 requests, but that requests from the browser can be HTTP/1.0, HTTP/1.1, or HTTP/2. HTTP/2 server push is not supported.

Before you begin

HTTP(S) Load Balancing uses instance groups to organize instances. Make sure you are familiar with instance groups before you use load balancing.

Example configuration

If you want to jump right in and build a working load balancer for testing, the following diagrams demonstrate three different scenarios using the HTTP(S) Load Balancing service. These scenarios provide a practical context for HTTP(S) Load Balancing and demonstrate how you might set up load balancing for your specific needs.

The rest of this page discusses more details about how load balancers are constructed and how they work.

Cross-region load balancing

Representation of
  cross-region load balancing

You can use a global IP address that can intelligently route users based on proximity. For example, if you set up instances in North America, Europe, and Asia, users around the world will be automatically sent to the backends closest to them, assuming those instances have enough capacity. If the closest instances do not have enough capacity, cross-region load balancing automatically forwards users to the next closest region.

Content-based load balancing

Representation of
  content-based load balancing

Content-based or content-aware load balancing uses HTTP(S) Load Balancing to distribute traffic to different instances based on the incoming HTTP(S) URL. For example, you can set up some instances to handle your video content and another set to handle everything else. You can configure your load balancer to direct traffic for to the video servers and to the default servers.

You can also use HTTP(S) Load Balancing with Google Cloud Storage buckets. After you have your load balancer set up, you can add Cloud Storage buckets to it.

Creating a combined load balancer

Representation of
  content-based and cross-regional load balancing

Content-based and cross-region load-balancing can work together by using multiple backend services and multiple regions. You can build on top of the scenarios above to configure your own load balancing configuration that meets your needs. The HTTP(S) load balancing tutorial shows you how to generate a load balancing configuration that is both content-based and cross-regional.


Your HTTP(S) Load Balancing service can be configured and updated through the following interfaces:

  • The gcloud command-line tool: a command-line tool included in the Cloud SDK. The HTTP(S) Load Balancing documentation calls on this tool frequently to accomplish tasks. For a complete overview of the tool, see the gcloud Tool Guide. You can find commands related to load balancing in the gcloud compute command group.

    You can also get detailed help for any gcloud command by using the --help flag:

    gcloud compute http-health-checks create --help
  • The Google Cloud Console: Load balancing tasks can be accomplished through the Google Cloud Console.

  • The REST API: All load balancing tasks can be accomplished using the Cloud Load Balancing API. The API reference docs describe the resources and methods available to you.

Notes and Restrictions

  • HTTP(S) Load Balancing supports the HTTP/1.1 100 Continue response.
  • If your load balanced instances are running a public operating system image supplied by Google Cloud Platform, then firewall rules in the operating system will be configured automatically to allow load balanced traffic. If you are using a custom image, you have to configure the operating system firewall manually. This is separate from the GCP firewall rule that must be created as part of configuring an HTTP(S) load balancer.
  • Load balancing does not keep instances in sync. You must set up your own mechanisms, such as using Deployment Manager, for ensuring that your instances have consistent configurations and data.


Load balanced traffic does not have the source address of the original client

Traffic from the load balancer to your instances has an IP address in the ranges of and When viewing logs on your load balanced instances, you will not see the source address of the original client. Instead, you will see source addresses from this range.

Getting a permission error when trying to view an object in my Cloud Storage bucket

In order to serve objects through load balancing, the Cloud Storage objects must be publicly accessible. Make sure to update the permissions of the objects being served so they are publicly readable.

URL doesn’t serve expected Cloud Storage object

The Cloud Storage object to serve is determined based on your URL map and the URL that you request. If the request path maps to a backend bucket in your URL map, the Cloud Storage object is determined by appending the full request path onto the Cloud Storage bucket that the URL map specifies.

For example, if you map /static/* to gs://[EXAMPLE_BUCKET], the request to https://<GCLB IP or Host>/static/path/to/content.jpg will try to serve gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. If that object doesn’t exist, you will get the following error message instead of the object:

The specified key does not exist.

Compression isn't working

HTTP(S) Load Balancing does not compress or decompress responses itself, but it can serve responses generated by your backend service that are compressed by using tools such as gzip or DEFLATE.

If responses served by HTTP(S) Load Balancing are not compressed but should be, check to be sure that the web server software running on your instances is configured to compress responses. By default, some web server software automatically disables compression for requests that include a Via header, which indicates that the request was forwarded by a proxy. Because it is a proxy, HTTP(S) Load Balancing adds a Via header to each request as required by the HTTP specification. To enable compression, you may have to override your web server's default configuration to tell it to compress responses even if the request had a Via header.

If you are using the nginx web server software, modify the nginx.conf configuration file to enable compression. The location of this file depends on where nginx is installed. In many Linux distributions, the file is stored at /etc/nginx/nginx.conf. To allow nginx compression to work with HTTP(S) Load Balancing, add the following two lines to the http section of nginx.conf:

gzip_proxied any;
gzip_vary on;

The first line enables compression even for requests forwarded by a proxy like HTTP(S) Load Balancing. The second line adds a Vary: Accept-Encoding header to responses. Vary: Accept-Encoding notifies caching proxies such as Cloud CDN that they should maintain separate cache entries for compressed and non-compressed variants of compressible resources.

After modifying nginx.conf, you need to restart nginx before it will use the new configuration. In many Linux distributions, nginx can be restarted by running sudo service nginx restart or /etc/init.d/nginx restart.

Troubleshooting issues with HTTP/2 to the backends

Invalid value for field resource.loadBalancingScheme: 'EXTERNAL'

Backend-service-based Network Load Balancing is not yet supported.

This could happen if you create a backend service without selecting the global option. When you issue a gcloud command as follows, you are prompted to designate a region or designate the load balancer as global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test1 \

For the following backend service:

- [service-test] choose a region or global:
[1] global
[2] region: [REGION_A_NAME]
[3] region: [REGION_B_NAME]
Please enter your numeric choice:

For the HTTP(S) load balancer, the backend services must be global, so you must choose option 1 or issue the gcloud command with the --global option:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test \
    --protocol=http2 \

Unexplained 502 errors

Make sure that your backend instance is healthy and supports HTTP/2 protocol. You can verify this by testing connectivity to the backend instance using HTTP/2. Ensure that the VM uses HTTP/2 spec-compliant cipher suites. For example, certain TLS 1.2 cipher suites are disallowed by HTTP/2. Refer to the TLS 1.2 Cipher Suite Black List.

After you verify that the VM uses the HTTP/2 protocol, make sure your firewall setup allows the health checker and load balancer to pass through.

If there are no problems with the firewall setup, ensure that the load balancer is configured to talk to the correct port on the VM.

HTTP/2 limitations

  • HTTP/2 between the load balancer and the instance can require significantly more TCP connections to the instance than HTTP(S). Connection pooling, an optimization that reduces the number of these connections with HTTP(S), is not currently available with HTTP/2.
  • HTTP/2 between the load balancer and the backend does not support:
    • Server push
    • WebSockets

Restriction on using Google Cloud Armor and Cloud CDN together

You cannot enable Google Cloud Armor and Cloud CDN with the same backend service. If you try to do so, the configuration process fails.

What's next