Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsFor reliable NGINX service, run at least two identically configured proxy nodes, put a tested failover mechanism in front of them, and design the upstream application pool and session state for node loss. On premises, the documented NGINX Plus pattern is an active-passive pair using keepalived and VRRP with a floating virtual IP (VIP). In cloud environments, a provider Layer 4 load balancer is usually the cleaner active-active front end.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What high availability means for an NGINX deployment
High availability (HA) has two separate failure domains. The first is the proxy tier: an NGINX process or an entire proxy node must be removable without changing the public address that clients use. The second is the upstream tier: application servers must be detected, avoided, and recovered without sending users into a failed backend. A design that handles only one of these domains still has a single point of failure.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Every production design should account for the following:
- Two or more NGINX nodes with equivalent configuration, modules, certificates, and operating-system limits.
- An upstream group containing at least two backend servers.
- A dedicated health endpoint whose response represents application readiness, not merely whether a web process is listening.
- Explicit connection, read, send, and retry timeouts chosen for the application.
- Monitoring for node state, VIP ownership, backend health, certificate expiry, and configuration drift.
- A written and rehearsed failover runbook.
NGINX instances in a load-balanced cluster do not share configuration or runtime state. HA therefore requires an external process or deployment system to distribute configuration and certificates; adding a second node does not synchronize it automatically.
#1 Best Overall
Choose active-passive or active-active
The right topology depends on where the VIP is managed, how much capacity must remain after a failure, and whether the application requires affinity between a client and a particular proxy.
| Decision area | Active-passive | Active-active |
|---|---|---|
| Failover mechanism | A floating VIP is owned by one node through VRRP and keepalived. The backup assumes ownership when advertisements stop or health checks fail. | Traffic is distributed through multiple VIPs, DNS answers, or an external Layer 3/Layer 4 distributor. |
| Capacity after one node fails | The surviving node must be sized for the full workload; normal operation leaves standby capacity unused. | Both nodes serve traffic normally, but available capacity drops when one fails. Remaining capacity must be calculated, not assumed. |
| Configuration and state | Nodes still need separately managed, identical files, certificates, modules, and policies. | Nodes do not automatically share configuration, connection state, or learned routing state; drift can affect only some clients and be harder to notice. |
| Session persistence | A single active proxy can make affinity simpler, but application sessions still need a supported method or externalized state. | Persistence must work across all active nodes. NGINX sticky-learn state is not shared between active nodes. |
| Cloud compatibility | Possible when the platform supports a movable private address, but provider networking often makes an external load balancer simpler. | Well suited to a managed Layer 4 load-balancing service. AWS also documents Elastic IP and Route 53 patterns. |
| Operational complexity | Fewer traffic paths, but VRRP, split-brain prevention, and takeover behavior must be tested. | Better resource utilization, with more complex distribution, draining, persistence, and capacity planning. |
| Testability | Clear exercise: stop the active node or fail its health check and verify VIP takeover. | Test node removal, partial capacity, DNS or distributor behavior, and persistence while traffic is spread across nodes. |
Build an active-passive pair with keepalived and VRRP
Prerequisites
Use two NGINX nodes on the same Layer 2 segment, or on infrastructure that explicitly supports the required VRRP behavior. Give each node a unique stable address and reserve an unused VIP in the same reachable network. Install the same NGINX edition, modules, operating-system packages, configuration, certificate chain, private keys, and firewall rules on both nodes. The application must accept traffic through the VIP regardless of which node owns it.
The official NGINX Plus on-premises pattern uses the nginx-ha-keepalived package and the nginx-ha-setup utility. VRRP ensures that there is a primary node at all times. Keepalived monitors the configured service checks; if the primary fails the configured number of checks, it reassigns the VIP to the passive node.
Installation and initial setup
- Install the
nginx-ha-keepalivedpackage on both nodes using the operating system’s supported package method. - Run
nginx-ha-setupon each node. Provide the peer address for the other NGINX node and the free VIP that clients will use. - Set the intended priority so the preferred node normally owns the VIP, while the peer remains ready to take over.
- Define the NGINX service check and any application-level check required to mark a node healthy. A process check alone can leave a node serving errors if its configuration, certificate, or upstream connectivity is broken.
- Start the keepalived and NGINX services, then verify that exactly one node reports ownership of the VIP and that the VIP answers requests.
- Confirm that gratuitous ARP or the platform’s equivalent updates neighboring devices when ownership changes.
VRRP takeover is not a universal fixed latency. The backup takes over after it misses advertisements for longer than three times the configured advertisement interval, subject to health-check processing and network convergence. Choose the interval deliberately, then measure the result in your own network rather than promising a generic failover time.
Rank #2
Validate the health script and prevent split brain
Run the configured health script manually as the service account and confirm its exit status, permissions, timeout, and logging. It should fail when NGINX cannot accept useful traffic, not merely when a cosmetic endpoint is unavailable. Test simultaneous loss of the primary’s process, listener, network interface, certificate, and upstream reachability.
Split brain occurs when both nodes believe they should own the VIP. Check Layer 2 support, VRRP authentication and interface selection, firewall rules for VRRP advertisements, and priority settings. During a controlled test, inspect the neighbor ARP table and send requests repeatedly while stopping the active node. Restore the original owner only after the peer has relinquished the VIP and logs show a single master.
Designing active-active NGINX
Active-active requires a front door that can reach more than one proxy. You can advertise multiple VIPs, publish multiple DNS addresses, or place an external Layer 3 or Layer 4 distributor in front of the NGINX nodes. The distributor must remove an unhealthy node and stop sending new connections to it; DNS-only approaches also depend on resolver caching, so clients may continue using a failed address until their cached record expires.
Plan for reduced capacity immediately after a failure. If two nodes each run at 50 percent utilization, losing one leaves no safety margin. Keep enough headroom for the surviving node’s peak workload, TLS handshakes, cache misses, and connection bursts. Because cluster members do not share configuration or state, deploy files and certificates through version-controlled automation and verify checksums before admitting a node to service.
For cloud active-active deployments, NGINX recommends a provider-managed Layer 4 load-balancing service. Such a service owns the provider-side address, performs node health checks, and avoids trying to emulate local Ethernet VIP movement across cloud networks. AWS separately documents designs using Elastic IP and Route 53; select the pattern that matches the required failover behavior, DNS caching tolerance, and regional scope.
Configure backend failover and retry behavior
An upstream group should contain more than one application server and should state how NGINX reacts to connection errors, timeouts, and selected HTTP failures. This illustrative pattern uses three backends, with the third reserved as a backup:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →upstream app_backend {
server app1.example.com max_fails=3 fail_timeout=10s;
server app2.example.com max_fails=3 fail_timeout=10s;
server app3.example.com backup;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://app_backend;
proxy_next_upstream error timeout http_502 http_503 http_504;
}
}max_fails=3 and fail_timeout=10s are example starting values, not universal tuning guidance. The retry list must match the application. Retrying a timed-out payment or other non-idempotent request can create duplicate work; for such operations, limit retries or use an application-level idempotency key. Conversely, safe GET requests may tolerate a retry to another backend. Test each status code and timeout path under load.
A backup server receives traffic only when the ordinary servers are unavailable. If you need all healthy servers to share traffic, omit that role and use the default load-balancing behavior, while ensuring the remaining nodes can carry the load during failure.
Use the right kind of upstream health check
Open Source NGINX: passive detection
Open Source NGINX detects upstream failure passively during real client requests. Connection errors, timeouts, and configured failure responses temporarily reduce a server’s eligibility according to the upstream parameters. This creates no synthetic probe traffic, but an idle backend can remain untested until a user request reaches it.
NGINX Plus: active probes
NGINX Plus can periodically send special health-check requests to each upstream server and verify the expected response before client traffic is routed there. The documented configuration requires an upstream shared memory zone and the health_check directive:
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
}
server {
location / {
proxy_pass http://backend;
health_check;
}
}Active checks are available in NGINX Plus; passive checks are available in Open Source NGINX. Configure the probe URI, interval, failure threshold, and success criteria to reflect application readiness. NGINX Plus can slowly reintroduce a recovered server, reducing the risk that a recently restarted application is flooded before caches and dependencies are ready.
Handle sessions and shared application state
If a user session lives only in one proxy or backend process, distributing requests can produce logouts, cart loss, or inconsistent authorization. Prefer external session storage or stateless, signed tokens so any healthy node can process a request. When the application cannot externalize state, use a supported sticky-session method and document the failure behavior when the selected node disappears.
Sticky-learn information is local to an NGINX instance; it is not shared between active nodes. An active-active pair can therefore make different affinity decisions unless the persistence mechanism itself is shared or the external distributor owns persistence. Test a client that is mid-session while removing its preferred proxy and backend, and verify whether the application intentionally recreates or rejects the session.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Keep configuration, certificates, and releases identical
Synchronize configuration through a controlled deployment pipeline rather than ad-hoc copying. Render the same upstream definitions, proxy headers, timeout policy, MIME settings, security rules, and logging format on every node. Distribute the complete certificate chain and private key with restrictive permissions, reload NGINX only after syntax validation, and retain the previous known-good release for rollback.
Recommended Free Tools
- Run
nginx -ton each node before a reload. - Compare enabled modules and NGINX versions; a directive accepted on one node may fail on another build.
- Check that DNS names used in upstream blocks resolve identically or are intentionally different.
- Verify clock synchronization so certificate validity, logs, and health-check intervals are meaningful.
- Drain a node before planned maintenance, then return it only after a successful health check and a controlled traffic ramp.
Monitoring and a practical failure-test plan
Alert on VIP ownership changes, keepalived state transitions, NGINX reload failures, worker-process exits, upstream failure counters, active-check status, TLS expiry, and configuration drift. Correlate proxy errors with backend logs so a 502 or 504 is not misdiagnosed as a VIP problem.
Run these tests in staging and repeat them after significant network, certificate, or application changes:
- Stop NGINX on the active node and confirm the passive node owns the VIP and serves successful requests.
- Break the active node’s health endpoint while leaving the process running; verify that keepalived withdraws the VIP.
- Take one backend out of service and confirm requests reach the remaining backend without unsafe duplicate retries.
- Restore a backend and observe whether it returns gradually or immediately, according to the chosen edition and policy.
- Introduce a certificate mismatch or invalid configuration on one node and ensure deployment validation blocks it from service.
- Simulate a network partition to check for split brain, duplicate VIP ownership, and the recovery procedure.
- Exercise a logged-in session while removing a proxy and then a backend, documenting the user-visible result.
Troubleshoot common HA failures
The VIP never moves
Check that the backup receives VRRP advertisements, that the interface name is correct, and that firewalls permit VRRP. Confirm the health script returns failure when expected and that keepalived is running with the intended priority. Inspect neighbor ARP or equivalent records after takeover.
Both nodes claim the VIP
Treat this as a split-brain incident. Remove one node from the network or stop keepalived, verify which node should be authoritative, then correct VRRP filtering, authentication, interface, and priority settings before reconnecting it.
Clients receive 502 or 504 responses after failover
Verify that the new owner has the same certificates, firewall rules, resolver configuration, and upstream routes. Check whether the application rejects a new source address or whether retrying a non-idempotent request caused a backend-side conflict. Review timeout values against the application’s actual response time.
Traffic returns to a backend too quickly
With passive checks, a server can appear eligible again after the failure window. Increase the failure window or use NGINX Plus active checks with a recovery strategy that ramps traffic gradually. Ensure the health endpoint tests dependency readiness rather than only TCP acceptability.
Quick Recap
Operational recommendation
For a conventional on-premises installation where one stable address is essential, start with the NGINX Plus active-passive keepalived/VRRP pattern, identical node builds, at least two upstream servers, and a tested runbook. Choose active-active when the available capacity and operational maturity justify distributed traffic management, and place a managed Layer 4 service in front of cloud nodes rather than assuming a local VIP can move across provider networks. Open Source NGINX remains suitable for passive upstream failure handling, while NGINX Plus is the relevant edition when active probes, gradual recovery, dynamic upstream controls, sticky-session features, or the supported keepalived HA tooling are requirements.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
