Listener protocols and client identity
Choose TLS termination, HTTP forwarding headers, or TCP proxy metadata for backend services.
Listener protocol determines which connection information a load balancer can inspect and how a backend receives the original client identity. Frontend and backend protocol choices must be compatible with the application.
HTTP and HTTPS termination
Open Networking → Load balancers → Load balancer → Listeners, then create or edit a listener. Protocol, backend transport, forwarding headers, and PROXY settings appear in the listener's Advanced options.
An HTTP listener reads HTTP requests. An HTTPS listener first terminates TLS with its configured certificate, then applies HTTP routing and health behavior. An HTTPS backend is a separate TLS connection with its own trust and server-name configuration.
The managed HTTP path supplies X-Forwarded-For for client address and
X-Forwarded-Proto for the original protocol. Incoming client values for those managed headers are replaced at the
trusted edge rather than accepted as authoritative identity. The application
must trust those headers only from the load-balancer path.
A direct public path to the backend can bypass that trust boundary. Restrict backend firewall admission to the balancer and explicit administrative sources. Host-header preservation is configured separately from which certificate the backend TLS connection expects.
TCP pass-through
A TCP listener forwards a byte stream without interpreting application HTTP or terminating guest-owned TLS. It cannot add an HTTP forwarding header to an opaque stream. The application sees the transport path's source unless a supported metadata mechanism is enabled.
Choose pass-through when the backend must own TLS or the protocol is not HTTP. Health checks still use their explicitly configured protocol and do not become a validation of every transaction in the stream.
PROXY protocol
For supported TCP backends, PROXY protocol v2 can prepend original connection metadata. Both listener and backend application must be configured for it. Sending PROXY metadata to an ordinary TLS or database listener can break the protocol before authentication starts.
PROXY protocol is disabled by default. Changing it is a listener revision and can require a coordinated application rollout. Do not enable it as a diagnostic experiment on a shared production listener without testing backend support.
Long-lived requests
Streaming HTTP, upgraded connections, and database sessions can outlive an ordinary health interval. Probe success does not indicate that those sessions finished. Use explicit draining with an acceptable timeout, and design clients to reconnect when a flow is interrupted.
A listener protocol change does not preserve an established connection under a new parser. Add a new listener or use a reviewed cutover when protocol compatibility changes.
The Load balancer API exposes forwarding and PROXY options. Use TLS listeners for certificate activation and firewall rollouts for backend trust-path changes.