Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
For reliable NGINX high availability, run at least two identically configured proxy nodes, place a redundant traffic path in front of them, keep application state outside any one node, and test failure recovery. On premises, the standard NGINX Plus design is an active-passive pair using keepalived, VRRP, and a floating virtual IP (VIP). Active-active designs can use multiple VIPs, DNS, or an external Layer 3/Layer 4 balancer, but they require deliberate handling of configuration, sessions, and reduced capacity after a node failure.
What high availability means in an NGINX deployment
High availability (HA) is not a single NGINX directive. It is an architecture that removes a single proxy-node failure from the service path and provides a controlled response when a backend, network link, certificate, or operating-system component fails.
Free tools Windows power users keep installed
One-click scans. No signup required.
A production design normally has two or more NGINX nodes, identical configuration and certificates, at least two backend servers, a health endpoint, explicit timeout and retry behavior, monitoring, and a tested failover runbook. The proxy pair must be redundant, but the application tier must be redundant as well; moving a VIP to a second proxy does not help if both proxies send traffic to one unavailable application server.
F5 NGINX describes the on-premises pattern as an active-passive pair. VRRP keeps one node primary and advertises the VIP. When advertisements stop or configured service checks fail, keepalived moves the VIP to the passive node. As the documentation puts it, “VRRP ensures that there is a primary node at all times.”
#1 Best Overall
Choose active-passive or active-active first
The right topology depends on where the nodes run, how much capacity must remain after a failure, and whether the application can safely receive requests from more than one proxy at once.
| Decision area | Active-passive | Active-active |
|---|---|---|
| Failover mechanism | A floating VIP is owned by one node through keepalived and VRRP; the backup takes ownership after missed advertisements or failed checks. | Traffic is distributed through multiple VIPs, DNS, or an external Layer 3/Layer 4 balancer. |
| Normal usable capacity | One proxy carries production traffic while the other is normally standby, unless you deliberately use the standby for separate work. | Both nodes can serve traffic concurrently. |
| Capacity after a node failure | The surviving node takes the VIP, so capacity is limited to that node. | Available capacity drops when one node disappears; the remaining node or nodes must be sized for the degraded condition. |
| Configuration and runtime state | Nodes still need synchronized configuration, certificates, modules, and operating-system settings. | NGINX instances do not automatically share configuration or runtime state; synchronization is an operational responsibility. |
| Session persistence | A single active proxy can make affinity simpler, but application sessions still need a durable design. | Requests can land on either node, so use a supported sticky method or externalize session state. |
| Cloud suitability | Possible where a provider supports a movable private address or equivalent failover mechanism. | Often pairs naturally with a provider Layer 4 load-balancing service. |
| Operational complexity | Lower traffic-distribution complexity, but VRRP, split-brain protection, and takeover behavior must be tested. | Higher requirements for distribution, state synchronization, capacity planning, and observability. |
| Testability | A clear test is to stop the primary or make its health check fail and verify VIP takeover. | Tests must cover node removal from the distributor, uneven traffic, state consistency, and degraded capacity. |
Active-passive is usually the most predictable starting point for two on-premises nodes. Active-active is appropriate when you need both nodes’ normal capacity, have a suitable distributor, and can make the application safe for requests arriving at either node.
Build the common HA foundation
Duplicate the proxy layer
- Provision at least two NGINX nodes in separate failure domains where practical: different hosts, power paths, or availability zones.
- Install the same NGINX edition and modules on every node.
- Keep virtual hosts, upstream definitions, rewrite rules, security policy, and logging settings identical unless a deliberate node-specific difference is documented.
- Install matching certificates, private keys, certificate chains, and renewal procedures. A certificate that exists on only one node turns failover into an outage.
- Synchronize operating-system time, resolver behavior, firewall rules, kernel limits, and service-manager settings.
Make the application tier redundant
Define an upstream group with at least two backend servers. Provide a lightweight health endpoint that returns a known successful response without performing an expensive transaction. Decide which failures should remove a server, which errors are safe to retry, and how long a client may wait.
Define the network path
For an on-premises VIP, reserve an unused address on the correct Layer 2 segment and permit VRRP advertisements between the peers. If multicast VRRP is not allowed, use the keepalived communication mode supported by your network design. Permit client traffic to the VIP and proxy-to-backend traffic through every node’s firewall.
Rank #2
Plan observability before cutover
- Monitor NGINX process health, listener availability, error rates, latency, active connections, and worker saturation.
- Monitor backend response codes and timeouts separately from proxy-node health.
- Alert on VIP ownership, repeated keepalived transitions, and configuration drift.
- Record which node is primary, when takeover occurred, and whether the old primary returned safely.
Configure an on-premises active-passive pair with keepalived
Install and initialize the HA components
The supported NGINX Plus on-premises pattern uses the nginx-ha-keepalived package. Install it on both nodes, then run nginx-ha-setup on each node. Supply the peer addresses and an unused VIP when the setup process requests them. Keep the node roles, interface selection, and authentication settings consistent with your network plan.
Validate the health-check command
Keepalived should demote a node when NGINX is not serving correctly, not merely when a process with the right name exists. Validate the supplied health-check script against the local listener and the intended health endpoint. Test failures such as a stopped NGINX service, a closed listener, a bad certificate configuration, and an unresponsive upstream. The check must recover cleanly when service is restored.
Confirm VRRP ownership and takeover
- Record the VIP owner and verify that clients can reach the service through that address.
- Stop NGINX on the primary, or force the configured health check to fail, in a staging environment.
- Verify that keepalived removes the VIP from the primary and assigns it to the backup.
- Send new requests through the VIP and confirm they reach the backup without changing DNS.
- Restore the original node and verify the planned preemption behavior; do not assume it should immediately reclaim the VIP.
- Repeat the test with a node power loss and with a network partition, then inspect logs for duplicate VIP ownership.
VRRP takeover is not a universal fixed latency. The documented behavior is that the backup takes over after it misses advertisements for longer than three times the configured advertisement interval. The interval is deployment-configured, so measure the resulting behavior in your own network rather than advertising a generic failover time.
Protect against split brain. Two nodes must never believe they own the VIP simultaneously. Check Layer 2 reachability, authentication, interface bindings, and fencing or out-of-band shutdown procedures before production use.
Use an upstream configuration that fails safely
This illustrative configuration combines passive backend failure detection with explicit retry behavior:
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;
}
}Here, the first two servers are tried normally; the server marked backup is selected when the primary servers are unavailable. max_fails=3 and fail_timeout=10s are example values from the pattern, not universal tuning recommendations. Adapt them to request duration, backend recovery time, and the application’s error budget.
Be especially careful with proxy_next_upstream. Retrying a failed GET is often safer than retrying a payment, order submission, or other non-idempotent operation. Define location-specific policies when the application cannot tolerate duplicate work. Set connect, send, read, and client timeouts explicitly so a dead backend does not consume all worker capacity.
Understand passive and active upstream health checks
Open Source NGINX: passive checks
Open Source NGINX detects an upstream failure while handling a real request. The failure counters and fail_timeout behavior can temporarily avoid a server that is timing out or returning configured errors. This costs no separate probe traffic, but a server with no live requests is not continuously verified, and the first user request after a failure may discover the problem.
NGINX Plus: active checks
NGINX Plus can send periodic health-check requests and verify the response before routing normal traffic. The official form is:
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
}
server {
location / {
proxy_pass http://backend;
health_check;
}
}The shared zone enables the upstream group to maintain runtime information, while health_check enables active probing for this location. NGINX Plus can also slowly reintroduce a recovered server, reducing the risk of sending a full load to a server that has only just returned. Active checks require NGINX Plus; passive checks are available in Open Source NGINX.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteChoose a health endpoint that tests the dependency level you actually need. A process-only check catches a crashed worker. A deeper check can catch a broken database connection, but it can also create load and mark the entire service unhealthy when one dependency is intentionally degraded. Document the expected status code, response body, interval, and failure threshold.
Design active-active NGINX correctly
Active-active does not mean that NGINX nodes share state automatically. As the NGINX documentation states, “NGINX instances in a load-balanced cluster do not share configuration or state.” Use configuration management, image-based deployment, or another controlled release process to keep nodes aligned. Never rely on an operator editing one node and remembering to repeat the change later.
Ways to distribute traffic
- Multiple VIPs: Advertise different addresses from different nodes and distribute clients or an upstream device across them. This can waste capacity if clients remain unevenly distributed.
- DNS: Publish more than one address and use health-aware DNS where available. DNS caching means a failed address can remain in clients’ caches longer than the DNS TTL.
- External Layer 3/Layer 4 balancer: Put a provider or network load-balancing service in front of the NGINX nodes. This is usually the cleanest cloud pattern because the service can remove an unhealthy node without making NGINX own the public failover address.
Size the cluster for the loss of at least one node. If two nodes each run at 60% utilization during normal traffic, losing one does not leave a safe 60% workload; the surviving node receives the displaced traffic. Include TLS handshakes, logging, compression, WebSocket connections, and peak bursts in the degraded-capacity calculation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Handle sessions and runtime state explicitly
If an application stores sessions only in one NGINX process or one node’s memory, a failover can log users out or lose in-progress state. Use a supported sticky-session method when affinity is required, or move session data to a shared application store that both proxy paths can reach.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not assume that sticky-learn state is shared between active nodes. In an active-active pair, a cookie or routing decision learned by one node may not exist on the other. Test a client that changes nodes during normal distribution, node failure, and node recovery. Confirm that authentication, carts, uploads, WebSocket connections, and long-running requests behave as the application owners expect.
Cloud deployment patterns
For cloud active-active deployments, NGINX recommends using the provider’s Layer 4 load-balancing service in front of the NGINX instances. The managed service owns the external address and health-based node selection, while NGINX remains responsible for HTTP routing, TLS, headers, and application policy.
AWS documentation also describes patterns using an Elastic IP and Route 53. These approaches can be useful when a stable address or DNS-based failover is required, but DNS caching and health-check intervals affect how quickly clients stop using a failed destination. Treat the cloud load balancer, route policy, security groups, and NGINX nodes as one failure chain; testing only the NGINX process does not prove that the public path fails over.
Test a complete failover runbook
Run these tests in staging before production and repeat them after major network, certificate, or NGINX changes:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- Primary proxy failure: Stop NGINX and verify health-check demotion, VIP movement, successful new requests, and alert delivery.
- Power or host failure: Remove the primary node entirely. Confirm the backup becomes reachable without manual DNS changes.
- Backend failure: Stop one application server. Confirm passive or active checks remove it and that traffic reaches a healthy peer.
- Slow backend: Introduce latency and confirm connect, read, and retry timeouts prevent connection exhaustion.
- Certificate mismatch: Deploy an intentionally invalid certificate only in staging. Verify validation catches drift before a node becomes primary.
- Split-brain simulation: Partition peer communication and confirm your fencing and alerting procedure prevents two VIP owners.
- Session continuity: Move traffic between nodes while authenticated and during a backend failure; verify the application’s documented session behavior.
- Recovery: Return the failed node, confirm configuration and certificates are current, and observe whether traffic re-enters gradually or immediately.
Record timestamps, VIP ownership, client-visible errors, backend status, and recovery actions. The result should be an operational runbook with an owner for each step, not an informal expectation that failover “should work.”
Quick Recap
Troubleshoot common HA failures
- The VIP never moves: Check that keepalived is running, the health script returns the expected status, peer advertisements reach the correct interface, and firewall rules permit the VRRP method in use.
- Both nodes claim the VIP: Treat this as split brain. Inspect peer connectivity, authentication, interface names, and duplicate static address configuration; remove one owner before serving traffic.
- Clients still see the old node: Verify ARP or neighbor-cache updates on the local network and check whether a DNS-based design is being mistaken for a VIP design.
- Failover succeeds but requests fail: Compare certificates, virtual-host files, resolver settings, upstream reachability, and environment-specific secrets on both nodes.
- Backends flap in and out: Review health endpoint depth, timeout values, thresholds, and whether the endpoint depends on a deliberately degraded service.
- Users lose sessions: Determine whether state was local to a proxy or application instance. Add external session storage or a supported affinity design, then test node changes.
- Retries duplicate work: Remove unsafe retry statuses for non-idempotent methods and make the application accept an idempotency key where appropriate.
When NGINX Plus is justified
Open Source NGINX can provide a highly available proxy pair with passive upstream failure detection, provided that external mechanisms handle VIP or traffic distribution and configuration synchronization. NGINX Plus is justified when you need supported keepalived HA packaging, active upstream health probes, gradual recovery of servers, dynamic upstream management, or commercial support for sticky-session and HA requirements. Product pricing and availability vary by agreement and region, so obtain current terms directly before budgeting.
Production readiness checklist
- Two or more nodes are deployed across independent failure domains.
- Configuration, modules, certificates, keys, secrets, and operating-system settings are synchronized and version-controlled.
- The VIP or external balancer has a documented ownership and health-check model.
- At least two backend servers exist, with explicit timeout, failure, and retry policies.
- Health endpoints, dashboards, alerts, and log retention are in place.
- Session state is externalized or a supported affinity method is tested.
- Capacity remains acceptable after losing one proxy node.
- Staging tests cover proxy failure, backend failure, slow responses, split brain, certificate drift, and recovery.
- A runbook identifies the responder, rollback action, and verification criteria for each failure.
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.
