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 matchHigh availability for NGINX starts with removing the proxy node as a single point of failure. On premises, the supported NGINX Plus pattern is an active-passive pair managed by keepalived and VRRP: one node owns a floating virtual IP (VIP), and the standby takes that address when advertisements stop or health checks report a failure. Active-active designs can use multiple VIPs, DNS, or an external Layer 3/Layer 4 distributor, but they require deliberate capacity, configuration, and session-state planning.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
This guide explains both architectures, upstream failure handling, NGINX Plus active checks versus Open Source passive checks, session persistence, cloud designs, a practical build sequence, and a failure-test runbook.
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.
What high availability means for an NGINX deployment
An NGINX reverse proxy is highly available when a failed proxy process, host, network interface, or maintenance event does not make the application unreachable. That requires redundancy at two levels: multiple NGINX nodes and multiple upstream application servers. A second proxy alone is not enough if both nodes point to one backend, share an untested certificate, or cannot take over the client-facing address.
A practical baseline contains two or more NGINX nodes with identical configuration and certificates, an upstream group with at least two application servers, a health endpoint, explicit timeout and retry rules, monitoring, and a tested procedure for failover and recovery. Keep configuration in version control or an automation system; NGINX instances in a load-balanced cluster do not share configuration or runtime state automatically.
#1 Best Overall
Choose active-passive or active-active
Active-passive with a floating VIP
In an on-premises NGINX Plus deployment, the usual design is one active node and one passive node. keepalived implements VRRP, which ensures that there is a primary node at all times. The primary owns the floating VIP used by clients. The backup listens for VRRP advertisements and takes ownership when the primary stops advertising or fails the configured service checks.
If the primary service fails the configured number of checks, keepalived reassigns the VIP to the backup. A takeover occurs after the backup misses advertisements for longer than three times the configured advertisement interval. The interval is chosen by the deployment, so this rule does not provide a universal failover time.
Active-active distribution
Active-active keeps multiple NGINX nodes serving traffic at the same time. Traffic can be divided with multiple VIPs, DNS responses, or an external Layer 3/Layer 4 load balancer. It can use the available hardware more efficiently during normal operation, but a node failure removes that node’s capacity immediately; the remaining nodes must be sized to absorb the load.
Active nodes do not automatically share configuration, connection state, or learned session data. You must distribute identical releases and certificates and decide where state lives before enabling more than one node for the same users.
Rank #2
| Decision area | Active-passive | Active-active |
|---|---|---|
| Client-facing mechanism | One floating VIP controlled by VRRP and keepalived |
Multiple VIPs, DNS distribution, or an external Layer 3/Layer 4 balancer |
| Normal capacity | Primarily the active node; standby capacity is reserved | All participating nodes serve requests |
| Capacity after one node fails | Traffic moves to the standby; capacity depends on standby sizing | Remaining nodes serve traffic with reduced aggregate capacity |
| Configuration and state | Must be synchronized between the pair | Must be synchronized across every active node; runtime state is not shared automatically |
| Session persistence | Can remain on one node until takeover, but sessions need a recovery plan | Requires a supported sticky method or externally stored session state |
| Cloud fit | Depends on whether the provider supports the required VIP or network semantics | Works naturally with a provider Layer 4 load-balancing service |
| Operations | Simple traffic ownership, but standby failover must be tested | More moving parts and more synchronization to operate |
| Testing | Clear takeover and restoration scenarios | Must test distribution, node loss, state consistency, and capacity headroom |
Build the common NGINX layer first
1. Duplicate the node prerequisites
Install the same NGINX edition on every proxy node. Apply the same virtual-host files, upstream definitions, TLS certificates and private keys, protocol settings, access-control rules, and logging policy. The nodes should resolve backend names consistently and have synchronized clocks so monitoring and incident timelines are useful.
Keep the configuration artifact identical rather than editing each node by hand. Validate a candidate file on a non-serving node before distributing it, and make certificate renewal part of the same controlled rollout.
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Define at least two upstream servers
Use an upstream group with more than one application endpoint. The following pattern marks a third server as a reserve and allows NGINX to stop sending traffic to an endpoint after repeated request failures:
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 and fail_timeout in this example are starting values, not universal recommendations. Tune them to the application’s response time and failure behavior. The proxy_next_upstream list must match request semantics: retrying a timed-out or 5xx request is safer for an idempotent read than for a payment or other operation that may already have committed.
3. Publish a health endpoint
Expose a lightweight endpoint that verifies the application is able to serve traffic. It should return a predictable success response without performing an expensive transaction. Keep a separate readiness signal if an application can accept connections but is still warming caches or waiting for a database.
4. Set explicit timeouts and observe them
Define connect, send, and read timeouts that reflect backend behavior rather than relying on implicit defaults. Alert on rising 502, 503, and 504 responses, upstream connection failures, and repeated health-check transitions. Logs from both proxy nodes and the VIP owner are needed to distinguish an application outage from a proxy takeover.
Configure on-premises active-passive HA with keepalived
NGINX Plus provides an official package and setup flow for this pattern. Install the nginx-ha-keepalived package on both nodes, run nginx-ha-setup on each node, provide the peer addresses, and assign a free VIP on the client-facing network. The setup must identify which node starts as primary and which starts as backup, and both nodes must be able to exchange VRRP advertisements.
- Prepare the network. Reserve a VIP that is on the same reachable network as the client-facing interfaces. Confirm that the network permits VRRP advertisements and that no other device is using the address.
- Install the HA components. Install the NGINX Plus HA keepalived package on both proxies and verify that the NGINX service and the keepalived service use the intended configuration files.
- Run the setup utility. Execute
nginx-ha-setupon both nodes, entering each peer’s address and the reserved VIP. Review the generated role and interface settings before enabling the services. - Attach service health to ownership. Configure the health-check script to fail when NGINX is stopped, the listener is unavailable, or a required local dependency is unhealthy. A host that is powered on but cannot proxy requests must not retain the VIP.
- Start one owner. Bring up the intended primary and confirm that it advertises the VIP. From a client on the production path, verify the address, certificate, response headers, and application response.
- Validate the backup. Confirm that the passive node has the same configuration and certificates but is not accepting client traffic through the VIP while the primary is healthy.
- Test takeover and return. Stop NGINX or trigger the configured health-check failure on the primary. Confirm that the backup acquires the VIP, serves new requests, and records the transition. Restore the primary and verify the planned preemption or manual-return behavior.
VRRP controls which node owns the address; it does not copy NGINX configuration, open connections, cache contents, or application sessions. Synchronize those separately and document which node should regain ownership after recovery.
Understand upstream health checks
Open Source NGINX: passive detection
Open Source NGINX detects an upstream failure while handling real client requests. Failure counters such as max_fails and the associated timeout window temporarily remove an endpoint after enough unsuccessful attempts. This avoids probe traffic, but an idle backend can remain untested until the next real request.
NGINX Plus: active probes
NGINX Plus can periodically send special health-check requests to each upstream server and verify the response before routing normal traffic. Its configuration requires an upstream shared memory zone and a health_check directive:
Recommended Free Tools
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
}
server {
location / {
proxy_pass http://backend;
health_check;
}
}Active checks can detect a failed or recovering server before a user request reaches it, and NGINX Plus can slowly reintroduce a recovered server. Select the probe URI, expected status, interval, and failure threshold to match the application’s readiness contract. Active checks do not replace end-to-end monitoring: a green HTTP response can still hide a broken dependency or incorrect business state.
Handle sessions and runtime state deliberately
If users can move between proxy nodes, application sessions must remain valid after distribution or failover. Prefer an application design that stores session data in a shared, durable service. When that is not possible, use a supported sticky-session method and document what happens when the selected node fails.
NGINX Plus sticky-learn state is not shared between active nodes. An active-active pair can therefore send a returning user to a node that has not learned the previous mapping. Treat stickiness as a routing convenience, not as a substitute for durable session storage. Test login, checkout, uploads, WebSocket reconnects, and long-running requests during node loss.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Cloud active-active patterns
For cloud deployments, NGINX recommends placing a provider Layer 4 load-balancing service in front of multiple NGINX instances. The managed service owns the external address and distributes TCP connections, while each NGINX node applies HTTP routing and upstream policy. This avoids depending on a broadcast-style VIP mechanism that the cloud network may not support.
AWS documents alternatives using an Elastic IP and Route 53. These approaches can move or resolve traffic toward a healthy instance, but DNS caching and address reassociation behavior affect convergence. Define health checks, TTL expectations, and the recovery procedure for the specific AWS design rather than promising an exact switchover time.
Failure modes and fixes
The VIP never moves
- Confirm both nodes are on the same intended Layer 2 or provider-supported VRRP segment.
- Check that advertisements are not blocked by a firewall or security group.
- Verify the health script returns failure when NGINX cannot listen or proxy.
- Make sure the VIP is free and attached to the correct interface.
The VIP moves but requests still fail
- Check that the backup has the same listener, server-name, certificate, and upstream configuration.
- Test backend DNS resolution and connectivity from the backup itself.
- Inspect file permissions for private keys and include files.
- Compare logs before and after takeover to separate proxy errors from backend errors.
Users are logged out after failover
- Determine whether sessions are stored only in process memory on the failed node.
- Move session state to a shared durable store or use an explicitly supported persistence method.
- Test a forced takeover while authenticated users perform normal operations.
Backends flap between healthy and failed
- Use a readiness endpoint that reflects dependency health, not merely process liveness.
- Increase probe tolerance only after measuring real response times; excessive thresholds delay removal of a bad server.
- Review retry rules so one slow request does not create duplicate side effects.
Test plan before production
- Run configuration validation on each node and verify that both produce the expected virtual host and upstream map.
- Disconnect the primary’s client-facing interface and observe VIP acquisition by the backup.
- Stop NGINX while leaving the host online to verify service-level health detection.
- Make one backend fail and confirm passive or active upstream handling removes it without taking down the proxy pair.
- Introduce a certificate mismatch on the standby in a staging environment and prove that deployment checks catch it before failover.
- Simulate a split-brain condition by interrupting peer communication, then verify monitoring detects competing ownership rather than allowing both nodes to serve the VIP.
- Exercise authenticated sessions, idempotent and non-idempotent requests, uploads, streaming responses, and WebSockets during takeover.
- Restore the failed node and verify the documented return-to-primary behavior, alert clearing, and configuration parity.
Record the observed sequence, timestamps, client impact, and operator actions in a runbook. Because no universal failover-latency figure applies, your measured result in the target network is the number that should guide capacity and incident expectations.
Operational checklist
- Two or more NGINX nodes have identical tested configuration and certificates.
- The VIP, VRRP path, interfaces, and firewall rules are documented.
- At least two upstream application servers and a meaningful health endpoint exist.
- Timeouts, retry status codes, and idempotency assumptions are explicit.
- Monitoring covers VIP ownership, NGINX process health, upstream health, 5xx rates, and certificate expiry.
- Session state remains usable when a node disappears.
- Backups, upgrades, and certificate renewals are tested on the standby before the active node.
- Node failure, backend failure, split-brain, certificate mismatch, and recovery drills have owners and rollback steps.
Which design should you use?
Use active-passive VRRP when you need one stable on-premises address, can reserve a standby node, and value straightforward ownership during an incident. Use active-active when you need normal-operation capacity from every node and can operate an external distributor or multiple address paths while keeping configuration and application state consistent. In either case, upstream redundancy and tested session handling matter as much as the proxy failover mechanism.
Quick Recap
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.
