All Products
Search

This Product

    Server Load Balancer:NLB health checks

    Document Center

    Server Load Balancer:NLB health checks

    Last Updated:Jun 02, 2026

    NLB uses health checks to determine backend server availability. When a server fails health checks, NLB stops forwarding new requests to it and redistributes traffic to healthy servers. When the server recovers, NLB automatically resumes forwarding. Health checks improve service availability and prevent single points of failure (SPOFs).

    Health check process

    NLB instances run in clusters. Cluster nodes forward traffic and perform health checks.

    Cluster nodes operate independently, forwarding traffic and running health checks in parallel.

    • If NLB detects an unhealthy backend server with connection draining disabled, existing sessions complete before connections close. New requests stop being forwarded to the server.

    • If NLB detects an unhealthy backend server with connection draining enabled, existing sessions continue until the draining timeout expires. New requests stop being forwarded to the server.

    Note

    • NLB uses its local IP address for health checks. Make sure this IP address is not blocked by backend servers. No ECS security group rule is needed, but if other security policies are in place (such as iptables), allow the IP address.

    • When all backend servers fail health checks, NLB enters best-effort mode and forwards requests to all servers to maintain availability.

    How it works

    TCP health checks

    NLB sends customized TCP probes to test backend server availability.

    image

    TCP health check process:

    1. NLB sends TCP SYN packets to the internal IP address and health check port of each backend server.

    2. If the port is listening, the backend server returns a SYN-ACK packet.

    3. If no SYN-ACK is received before the response timeout, the server is declared unhealthy. NLB sends an RST packet to close the connection.

    4. If a SYN-ACK is received before the timeout, the server passes the health check. NLB sends an ACK followed immediately by an RST to close the connection.

    Note

    During health checks, NLB completes the three-way handshake and immediately sends an RST to close the connection. This may cause false TCP connection errors on backend servers, which may log Connection reset by peer errors in software logs such as Java connection pool logs.

    Solutions:

    • Configure HTTP health checks for TCP listeners.

    • Enable client IP preservation on backend servers and ignore connection reset errors from NLB CIDR blocks.

    UDP health checks

    UDP health checks support two methods:

    Method 1: Health checks on ports

    The following figure shows how health checks are performed.

    image

    UDP port health check process:

    1. NLB sends an ICMP request to the internal IP address of the backend server.

    2. NLB sends a UDP probe packet to the internal IP address and health check port of the backend server.

    3. If the backend server returns an ICMP response before the timeout and does not return a Port XX Unreachable message, the server passes. Otherwise, it fails.

    Method 2: Custom health checks

    The following figure shows how health checks are performed.

    image

    Custom UDP health check process:

    1. NLB sends a UDP probe packet with specified content to the internal IP address and health check port of the backend server.

    2. If NLB receives the expected response before the timeout, the server passes. Otherwise, it fails.

    HTTP health checks

    For Layer 4 (TCP or UDP) listeners, you can configure HTTP health checks that send HEAD or GET requests to verify backend server availability.

    image

    HTTP health check process:

    1. NLB sends an HTTP HEAD or GET request with the specified domain name to the internal IP address and health check path of the backend server.

    2. The backend server returns an HTTP status code based on its status.

    3. If no response is received before the timeout, the server fails the health check.

    4. If a response is received before the timeout, NLB compares the returned HTTP status code against the codes specified in the health check settings. A matching code means the server is healthy; otherwise, it is unhealthy.

    Use cases

    TCP health checks

    • FTP services: Verify that FTP servers can accept and respond to connection requests.

    • Email services: Verify that email servers can send and receive messages.

    • Financial transactions: Detect transaction server failures promptly to prevent interruptions.

    • Remote logon: Monitor the availability and performance of remote logon services.

    UDP health checks

    Traditional industries

    • DNS services: Verify that DNS servers respond to queries correctly.

    • VoIP services: Monitor latency, packet loss, and jitter for VoIP applications such as Skype and IP phone systems.

    • Online games: Monitor response time and availability of game servers.

    • Streaming media: Assess availability and stream quality for video conferencing and real-time video services.

    • Instant messaging: Monitor connection stability and latency for real-time message delivery.

    Emerging industries

    • QUIC: Verify QUIC connection status for efficient, real-time data transmission.

    • IoT: Check sensor device status with low latency, suitable for power-sensitive or cost-sensitive devices.

    • V2X: Ensure real-time data exchange and communication reliability between vehicles and infrastructure.

    • VR and AR: Ensure fast transmission of visual and interaction data.

    • Cloud gaming: Monitor latency to maintain smooth gameplay.

    HTTP health checks

    • Web services: Send HTTP GET or HEAD requests to a specified path (such as /health) to verify that the server can process HTTP requests.

    • Custom application health checks: Use custom logic to check database connection pools, cache status, or other application-specific metrics.

    • Microservices: Detect application-layer errors in microservice instances. Health check responses provide detailed diagnostic information.

    • API gateways and reverse proxies: Monitor the health of API gateways or reverse proxies such as NGINX and HAProxy through their HTTP interfaces.

    Domain names for HTTP health checks

    You can optionally specify a domain name for HTTP health checks. Some application servers verify the Host header before accepting requests. If you specify a domain name in health check settings, NLB adds it to the Host header. Otherwise, NLB omits the Host header, which may cause health check failures if the backend server requires it.

    If your application server verifies the Host header, configure a domain name for health checks.

    References