프록시 네트워크 부하 분산기는 Google Cloud 가상 프라이빗 클라우드(VPC) 네트워크 또는 다른 클라우드 환경의 백엔드로 TCP 트래픽을 배포하는 레이어 4 리버스 프록시 부하 분산기입니다. 트래픽은 부하 분산 레이어에서 종료된 후 TCP를 통해 사용 가능한 가장 가까운 백엔드로 전달됩니다.
프록시 네트워크 부하 분산기는 SSL 유무에 관계없이 TCP 트래픽 전용입니다.
HTTP(S) 트래픽의 경우 대신 애플리케이션 부하 분산기를 사용하는 것이 좋습니다.
프록시 네트워크 부하 분산기는 다음 기능을 지원합니다.
외부 부하 분산기의 TLS/SSL 오프로드 전역 외부 프록시 네트워크 부하 분산기 또는 기본 프록시 네트워크 부하 분산기를 사용하여 SSL 프록시를 사용해서 부하 분산 레이어에서 TLS를 오프로드할 수 있습니다.
모든 포트 지원. 이러한 부하 분산기는 1~65,535 사이의 유효한 포트를 허용합니다. 자세한 내용은 포트 사양을 참조하세요.
포트 다시 매핑. 부하 분산기의 전달 규칙에서 사용하는 포트는 백엔드에 연결할 때 사용되는 포트와 일치하지 않아도 됩니다. 예를 들어 전달 규칙에서는 TCP 포트 80을 사용하는 반면 백엔드에 대한 연결에서는 TCP 포트 8080을 사용할 수 있습니다.
원본 소스 IP 주소 릴레이. PROXY 프로토콜을 사용하여 클라이언트의 소스 IP 주소와 포트 정보를 부하 분산기 백엔드로 릴레이할 수 있습니다.
다음 다이어그램은 샘플 프록시 네트워크 부하 분산기 아키텍처를 보여줍니다.
프록시 네트워크 부하 분산기 아키텍처
프록시 네트워크 부하 분산기는 다음 배포 모드로 사용할 수 있습니다.
외부 프록시 네트워크 부하 분산기: 인터넷의 클라이언트에서 들어오는 트래픽을 부하 분산합니다. 아키텍처 세부정보는 외부 프록시 네트워크 부하 분산기 아키텍처를 참조하세요.
배포 모드
네트워크 서비스 등급
부하 분산 스키마†
IP 주소
프런트엔드 포트
전역 외부
프리미엄 등급
EXTERNAL_MANAGED
IPv4
IPv6
1~65535 중 정확히 하나의 포트를 참조할 수 있습니다.
기본
프리미엄 등급의 경우 전역
표준 등급의 경우 리전
외부
IPv4
IPv6(프리미엄 등급 필요)
리전 외부
프리미엄 또는 표준 등급
EXTERNAL_MANAGED
IPv4
내부 프록시 네트워크 부하 분산기: VPC 네트워크 또는 VPC 네트워크에 연결된 네트워크 내에서 트래픽을 부하 분산합니다. 아키텍처 세부정보는 내부 프록시 네트워크 부하 분산기 아키텍처를 참조하세요.
배포 모드
네트워크 서비스 등급
부하 분산 스키마†
IP 주소
프런트엔드 포트
리전 내부
프리미엄 등급
INTERNAL_MANAGED
IPv4
1~65535 중 정확히 하나의 포트를 참조할 수 있습니다.
교차 리전 내부
프리미엄 등급
INTERNAL_MANAGED
IPv4
† 부하 분산 스키마는 부하 분산기의 전달 규칙 및 백엔드 서비스의 속성이며 내부 또는 외부 트래픽에 부하 분산기를 사용할 수 있는지 여부를 나타냅니다. 부하 분산 스키마에서 *_MANAGED라는 용어는 부하 분산기가 Google 프런트 엔드(GFE)에서 관리형 서비스로 구현되거나 오픈소스 Envoy 프록시에서 관리형 서비스로 구현된 것입니다. *_MANAGED인 부하 분산 스키마에서 요청이 GFE 또는 Envoy 프록시로 라우팅됩니다.
외부 프록시 네트워크 부하 분산기
외부 프록시 네트워크 부하 분산기는 인터넷에서 유입되는 트래픽을 Google Cloud VPC 네트워크, 온프레미스 또는 기타 클라우드 환경의 백엔드로 배포합니다. 이러한 부하 분산기는 전역, 리전 또는 기본 모드 중 하나로 배포할 수 있습니다.
외부 프록시 네트워크 부하 분산기는 다음 기능을 지원합니다.
IPv6 종료. 외부 부하 분산기는 클라이언트 트래픽에 IPv4 주소와 IPv6 주소를 모두 지원합니다. 클라이언트 IPv6 요청은 부하 분산 레이어에서 종료된 후 IPv4를 통해 백엔드로 프록시 처리됩니다.
TLS/SSL 오프로드. 전역 외부 프록시 네트워크 부하 분산기 또는 기본 프록시 네트워크 부하 분산기를 사용하여 SSL 프록시를 사용해서 부하 분산 레이어에서 TLS를 오프로드할 수 있습니다. 새 연결은 SSL(권장) 또는 TCP를 사용하여 가장 가까운 사용 가능한 백엔드로 전달됩니다. 배포의 다음 측면을 구성할 수 있습니다.
백엔드 사용률 향상. 사용되는 암호의 CPU 효율성이 낮다면 SSL 처리 시 CPU가 집중적으로 소비될 수 있습니다. CPU 성능을 최대화하려면 ECDSA SSL 인증서, TLS 1.2를 사용하고 부하 분산기와 백엔드 인스턴스 간에 SSL용 ECDHE-ECDSA-AES128-GCM-SHA256 암호화 스위트를 우선적으로 사용하세요.
SSL 정책.SSL 정책을 사용하면 부하 분산기에서 클라이언트와 협상하는 SSL 기능을 제어할 수 있습니다.
Cloud Armor와 통합Cloud Armor 보안 정책을 사용하여 DDoS 공격과 기타 표적 공격으로부터 인프라를 보호할 수 있습니다.
TLS가 종료되는 위치에 대한 지리적 제어. 클라이언트와 부하 분산기 간의 지연을 최소화하기 위해 부하 분산기는 전역으로 분산된 위치에서 TLS를 종료합니다. TLS가 종료되는 위치를 지리적으로 제어해야 하는 경우 표준 네트워크 등급을 사용하여 부하 분산기가 특정 리전에만 있는 백엔드에서 TLS를 종료하도록 할 수 있습니다. 자세한 내용은 표준 등급 구성을 참조하세요.
App Hub 지원. 리전 외부 프록시 네트워크 부하 분산기에서 사용하는 리소스는 App Hub 애플리케이션에서 서비스로 지정할 수 있습니다.
다음 다이어그램에서는 도시 A와 도시 B의 사용자가 보내는 SSL 트래픽이 부하 분산 레이어에서 종료되고 선택된 백엔드에 대한 별도의 연결이 설정됩니다.
내부 프록시 네트워크 부하 분산기는 동일한 VPC 네트워크 또는 VPC 네트워크에 연결된 클라이언트에서만 액세스할 수 있는 내부 IP 주소로 TCP 서비스 트래픽을 실행하고 확장할 수 있게 해주는 Envoy 프록시 기반 리전별 레이어 4 부하 분산기입니다.
부하 분산기는 TCP 트래픽을Google Cloud, 온프레미스 또는 기타 클라우드 환경에 호스팅되는 백엔드에 배포합니다. 이러한 부하 분산기는 교차 리전 또는 리전별 모드 중 하나로 배포할 수 있습니다.
내부 프록시 네트워크 부하 분산기는 다음 기능을 지원합니다.
지역 정책. 백엔드 인스턴스 그룹 또는 네트워크 엔드포인트 그룹 내에서 요청이 구성원 인스턴스 또는 엔드포인트에 배포되는 방식을 구성할 수 있습니다.
전역 액세스. 전역 액세스가 사용 설정되면 모든 리전의 클라이언트가 부하 분산기에 액세스할 수 있습니다.
연결된 네트워크에서 액세스. 클라이언트가 자체 Google CloudVPC 네트워크 이외의 네트워크에서 내부 부하 분산기에 액세스할 수 있습니다. 다른 네트워크는 VPC 네트워크 피어링, Cloud VPN 또는 Cloud Interconnect를 사용하여 부하 분산기의 VPC 네트워크에 연결되어야 합니다.
App Hub 지원. 리전 내부 프록시 네트워크 부하 분산기에서 사용하는 리소스는 App Hub 애플리케이션에서 서비스로 지정할 수 있습니다.
[[["이해하기 쉬움","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)"]]
