[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["# Proxy Network Load Balancer overview\n\nProxy Network Load Balancers are layer 4 reverse proxy load balancers that distribute\nTCP traffic to backends in your Google Cloud Virtual Private Cloud (VPC)\nnetwork or in other cloud\nenvironments. Traffic is terminated at the load balancing layer and then\nforwarded to the closest available backend by using TCP.\n\nProxy Network Load Balancers are intended for TCP traffic only, with or without SSL.\nFor HTTP(S) traffic, we recommend that you use an Application Load Balancer\ninstead.\n\nThe proxy Network Load Balancers support the following features:\n\n- **TLS/SSL offload for external load balancers.** You can use a global external proxy Network Load Balancer or a classic proxy Network Load Balancer to offload TLS at the load balancing layer by using an SSL proxy.\n- **Support for all ports.** These load balancers allow any valid port from 1-65535. For more information, see [Port\n specifications](/load-balancing/docs/forwarding-rule-concepts#port_specifications).\n- **Port remapping.** The port used by the load balancer's forwarding rule does not have to match the port used when making connections to its backends. For example, the forwarding rule could use TCP port 80, while the connection to the backends could use TCP port 8080.\n- **Relays original source IP address.** You can use the PROXY protocol to relay the client's source IP address and port information to the load balancer backends.\n\nThe following diagram shows a sample proxy Network Load Balancer architecture.\n[](/static/load-balancing/images/proxy-network-load-balancer.svg) Proxy Network Load Balancer architecture.\n\nProxy Network Load Balancers are available in the following modes of deployment:\n\n- **External proxy Network Load Balancer** : Load balances traffic that comes from clients\n on the internet. For architecture details, see [External proxy Network Load Balancer\n architecture](/load-balancing/docs/tcp#components).\n\n- **Internal proxy Network Load Balancer** : Load balances traffic within your\n VPC network or networks connected to your VPC\n network. For architecture details, see [Internal proxy Network Load Balancer\n architecture](/load-balancing/docs/tcp/internal-proxy#components).\n\n^†^ The load-balancing scheme is an attribute on the [forwarding rule](/load-balancing/docs/forwarding-rule-concepts) and the\n[backend service](/load-balancing/docs/backend-service) of a load\nbalancer and indicates whether the load balancer can be used for internal or\nexternal traffic. The term `*_MANAGED` in the load-balancing scheme\nindicates that the load balancer is implemented as a managed service on [Google Front Ends\n(GFEs)](/docs/security/infrastructure/design#google-frontend-service) or as a managed service on the open source [Envoy proxy](https://www.envoyproxy.io/). In a\nload-balancing scheme that is `*_MANAGED`, requests are routed\neither to the GFE or to the Envoy proxy.\n\nExternal proxy Network Load Balancer\n------------------------------------\n\nThe external proxy Network Load Balancer distributes traffic that comes from the internet to\nbackends in your Google Cloud VPC network, on-premises, or\nin other cloud environments. These load balancers can be deployed in one of the\nfollowing modes: [global, regional, or classic](#proxy-lb-summary).\n\nExternal proxy Network Load Balancers support the following features:\n\n- **IPv6 termination.** The external load balancers support both IPv4 and [IPv6\n addresses](/load-balancing/docs/ipv6) for client traffic. Client IPv6 requests are terminated at the load balancing layer and then proxied over IPv4 to your backends.\n- **TLS/SSL offload.** You can use a global external proxy Network Load Balancer or a\n classic proxy Network Load Balancer to offload TLS at the load balancing layer by using\n an SSL proxy. New connections are forwarded to the closest available backends\n by using either SSL (recommended) or TCP. You can configure the following\n aspects of your deployment:\n\n - **Better utilization of backends.** SSL processing can be very CPU-intensive if the ciphers used are not CPU efficient. To maximize CPU performance, use ECDSA SSL certificates and TLS 1.2, and prefer the `ECDHE-ECDSA-AES128-GCM-SHA256` cipher suite for SSL between the load balancer and your backend instances.\n - **SSL policies.** [SSL\n policies](/load-balancing/docs/ssl-policies-concepts) give you the ability to control the features of SSL that your load balancer negotiates with clients.\n- **Integration with Cloud Armor.** You can use\n [Cloud Armor security policies](/armor/docs/security-policy-overview#policy-types)\n to protect your infrastructure from distributed denial-of-service (DDoS)\n attacks and other targeted attacks.\n\n- **Geographic control over where TLS is terminated.** The load balancer\n terminates TLS in locations that are distributed globally, so as to minimize\n latency between clients and the load balancer. If you require geographic\n control over where TLS is terminated, you can use the Standard Network Tier to\n force the load balancer to terminate TLS on backends that are located in a\n specific region only. For details, see [Configuring Standard\n Tier](/network-tiers/docs/overview#standard-for-https-and-tcp-ssl).\n\n- **Support for App Hub** . Resources used by\n regional external proxy Network Load Balancers can be designated as services in\n [App Hub applications](/app-hub/docs/overview).\n\nIn the following diagram, traffic from users in City A and City B is terminated at\nthe load balancing layer, and a separate connection is established to the\nselected backend.\n[](/static/load-balancing/images/ssl-lb-overview.svg) Proxy Network Load Balancer with SSL termination.\n\nFor more details, see [External proxy Network Load Balancer overview](/load-balancing/docs/tcp).\n\nInternal proxy Network Load Balancer\n------------------------------------\n\nThe [internal proxy Network Load Balancer](/load-balancing/docs/tcp/internal-proxy) is an Envoy\nproxy-based regional Layer 4 load balancer that lets you run and scale\nyour TCP service traffic behind an internal IP address that is accessible only\nto clients in the same VPC network or clients connected to your\nVPC network.\n\nThe load balancer distributes TCP traffic to backends hosted on\nGoogle Cloud, on-premises, or in other cloud environments. These load\nbalancers can be deployed in one of the following modes: [cross-region or\nregional](#proxy-lb-summary).\n\nInternal proxy Network Load Balancers support the following features:\n\n- **Locality policies.** Within a backend instance group or network endpoint group, you can configure how requests are distributed to member instances or endpoints.\n- **Global access.** When global access is enabled, clients from any region can access the load balancer.\n- **Access from connected networks.** You can make your internal load balancer accessible to clients from networks beyond its own Google Cloud VPC network. The other networks must be connected to the load balancer's VPC network by using either VPC Network Peering, Cloud VPN, or Cloud Interconnect.\n- **Support for App Hub** . Resources used by regional internal proxy Network Load Balancers can be designated as services in [App Hub applications](/app-hub/docs/overview).\n\nFor more details, see [Internal proxy Network Load Balancer overview](/load-balancing/docs/tcp/internal-proxy).\n\n### High availability and cross-region failover\n\nYou can set up a cross-region internal proxy Network Load Balancer in multiple regions to get the\nfollowing benefits:\n\n1. If backends in a particular region are down, the\n traffic fails over to the backends in another region gracefully.\n\n The cross-region failover deployment example shows the following:\n - A cross-region internal proxy Network Load Balancer with a frontend VIP address in the Region A of your VPC network. Your clients are also located in the Region A.\n - A global backend service that references the backends in the Google Cloud Region A and Region B.\n - When the backends in the Region A are down, traffic fails over to the Region B.\n\n [](/static/load-balancing/images/cross-region-proxy-backend-failover.svg) Cross-region internal proxy Network Load Balancer with a cross-region failover deployment (click to enlarge).\n2. Cross-region internal proxy Network Load Balancers can also shield your application from\n complete regional outages by serving traffic to your client from proxies\n and backends in another region.\n\n The high availability deployment example shows the following:\n - A cross-region internal proxy Network Load Balancer with frontend VIPs in the Region A and Region B of your VPC network. Your clients are located in the Region A.\n - You can make the load balancer accessible by using frontend VIPs from two\n regions.\n\n [](/static/load-balancing/images/cross-reg-proxy-failover.svg) Cross-region internal proxy Network Load Balancer with high availability deployment (click to enlarge).\n\nFor information about how to set up a high availability deployment, see:\n\n- [Set up a cross-region internal proxy Network Load Balancer with VM instance group backends](/load-balancing/docs/l7-internal/setting-up-l7-cross-reg-internal)\n- [Set up a cross-region internal proxy Network Load Balancer with hybrid connectivity](/load-balancing/docs/l7-internal/setting-up-l7-cross-reg-hybrid)"]]
