> ## Documentation Index > Fetch the complete documentation index at: https://ngrok.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Global Load Balancer > Learn about ngrok's Global Load Balancer for distributing traffic to the nearest healthy point of presence for improved performance. ## Overview ngrok's Global Load Balancer improves the performance and resiliency of your applications by distributing traffic to the nearest healthy point of presence, measured by latency, from the perspective of the connecting client. Every application you deliver with ngrok is automatically accelerated with the always-on, zero-configuration global load balancer. Global lobal balancing is sometimes called 'Global Server Load Balancing' or GSLB. Conceptually, a GSLB is simple. A GSLB accelerates traffic by adjusting DNS resolution so that when clients connect to your endpoints on the internet, they connect to the nearest point of presence (PoP). A GSLB adds resiliency by adjusting that same DNS resolution process to steer traffic away from failing PoPs. ## ngrok versus traditional GSLBs ngrok operates differently from a traditional GSLB to give you some important benefits. 1. In a traditional GSLB deployment, you are responsible for running geographically redundant copies of your application and configuring networking technologies to distribute and failover traffic among these deployments. By contrast, ngrok runs a [global delivery network of PoPs](/gateway/points-of-presence/) for you. This means that even if you only deploy your upstream service to a single geography, your apps still get faster from [Connection Acceleration](#connection-acceleration) and [Module Acceleration](#module-acceleration). 2. Unlike a traditional GSLB deployment, when you deploy your application services to a new geographic location, ngrok automatically routes nearby traffic to those services without any configuration. Traditional GSLB deployments require many network configuration updates to bring these new locations online like IP provisioning and DNS record changes. With ngrok, there is zero configuration, just start your new application services with their ngrok agents and you're done. 3. Unlike a traditional reverse proxy, ngrok forwards traffic to your upstream services over secure connections established by the [ngrok agent](/agent/), [Agent SDKs](/agent-sdks) or [Kubernetes Controller](/k8s/). So which PoPs do those agents connect to? ngrok also applies GSLB principles to those connections as well to ensure that your agents connect to the geographically closest PoPs. ## Endpoints ngrok's GSLB improves the performance and resiliency of connections to your ngrok endpoints (for example, `https://your-app.ngrok.app`). ### Connection acceleration When a client (like a web browser) connects to your ngrok endpoint it is routed to the closest point of presence. DNS resolution of your endpoint's address returns the IP addresses of ngrok's closest point of presence. The closest point of presence is determined by the shortest latency from the resolving DNS server to the points of presence. This ensures that clients are routed to the fastest point of presence even as internet routing conditions change. Connecting to the closest point of presence accelerates your traffic by reducing the initialization time for TCP and TLS connections. TCP and TLS connection set up requires network round-trips. ngrok accelerates connections by reducing the latency of these round-trip times (RTTs) between the client and your endpoint by routing them to the closest point of presence. ### Module acceleration In addition to accelerating connection initialization, ngrok also accelerates the execution of [Modules](/traffic-policy/actions/) that you configure on your endpoints. Modules execute where the request is first received by the ngrok edge, at the geographically closest point of presence. This means that any behaviors you define in your modules are automatically globally accelerated for all customers. ### Geo-aware load balancing When you use [endpoint pooling](/gateway/endpoint-pooling), ngrok will automatically distribute traffic to the closest upstream if you run geographically distributed copies of your upstream application or service. First, consider a case *without* geo-aware load-balancing. For example, you have instances of your application running in Japan. When someone in Belgium makes a request to your app's endpoint, that request will first be routed to the closest ngrok point of presence in Europe, like Frankfurt. From Frankfurt, it will then be routed through ngrok's internal network and finally to your upstream services in Japan. Then, for example, you start additional copies of your application service in France. With zero changes in configuration, those same requests from Belgium will still be routed to ngrok's point of presence in Frankfurt, but instead of routing to your upstream services in Japan, they will instead be routed to your new upstreams in France. That's Geo-Aware Load Balancing. ### Losing an upstream Consider the example in [Geo-Aware Load Balancing](#geo-aware-load-balancing) where you are running upstream application services in both Japan and France. If all of your upstream services in Japan fail, requests that were being routed to your Japanese upstream services will instead be routed to your remaining upstream services in France. Requests that were already being routed to your upstreams in France will be unaffected. ### Losing a point of presence In [losing an upstream](#losing-an-upstream), a case was considered where your upstream services fail. But what if an ngrok point of presence fails? If an ngrok point of presence fails, health checks automatically detect that failure and update DNS resolution such that clients will attempt to connect to your endpoints via the next-closest healthy point of presence. ### Disabling GSLB for an endpoint There is no way to disable GSLB for HTTPS and TLS endpoints. All endpoints you create in ngrok are available on ngrok's worldwide global delivery network and inbound requests and connections are routed to the geographically closest point of presence. ### TCP endpoints TCP Endpoints do not support GSLB. Unlike domains, TCP addresses are provisioned for a specific point of presence. When you create a TCP Address, you must select the point of presence where it will accept traffic. Unlike ngrok's globally routed domains, traffic to TCP addresses always enters ngrok's network from that point of presence. ## Agents ngrok's GSLB automatically improves the performance and resiliency of your ngrok agents, agent SDKs and the Kubernetes Controller. Agents automatically connect to ngrok's geographically closest healthy point of presence. ### Acceleration Similar to endpoints, when an ngrok agent connects, DNS resolution returns the IPs of the closest ngrok point of presence. Connecting to the closest ngrok point of presence reduces agent initialization time and also reduces the latency of connections that are routed to that agent. ### Losing a point of presence If an ngrok point of presence fails, health checks automatically detect that failure and update DNS resolution such that agents will attempt to connect to the next-closest healthy point of presence. The ngrok agent connects to a single region at a time. If you want the ngrok agent to simultaneously connect to multiple regions, you must instead run multiple ngrok agents and [explicitly disable agent GSLB](#agents-disabling-gslb). ### Disabling GSLB in the Agent You should always prefer to allow the ngrok agent to use GSLB and connect to the closest point of presence. However, the ngrok agent does support disabling GSLB and explicitly choosing which point of presence to connect to. If you wish to configure the agent to use a specific point of presence you may do so with the following configuration: ### Legacy Agent behavior Beginning with the [ngrok v3 agent](/agent/changelog#ngrok-agent-300---2022-03-28), the agent uses GSLB to connect to the lowest-latency point point of presence. Prior to that, v2 ngrok agents would always connect to the U.S. region by default.