Recommended Free Tools
Yes. Publish one hostname and put a routing layer in front of two equivalent origin servers. The router can be an NGINX reverse proxy or load balancer, a managed edge load-balancing service, or DNS health-check failover. Visitors continue using one domain while requests are sent to either server.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The design is reliable only when both origins run the same deployable code and configuration, and when mutable data—database records, uploads, sessions, carts and generated files—is shared or replicated. Two independent servers with separate data create split-brain behavior, not high availability.
As an Amazon Associate I earn from qualifying purchases.
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 minuteWhat “one website on two servers” actually means
A browser does not normally choose between two application servers by itself. It connects to the hostname in the URL. A routing layer then decides which origin should handle each request.
- Hostname: The public name, such as
www.example.com. - Routing layer: A reverse proxy, load balancer, managed edge service or DNS failover system that knows about both origins.
- Origins: Server A and Server B, each capable of serving the same application.
- Shared services: A database, cache and file store that remain available when either web server is removed.
For active-active operation, both origins receive traffic while healthy. For active-passive operation, one origin is primary and the other waits for a failure. In either model, the public DNS name should represent the routing layer, not an uncoordinated pair of web servers.
#1 Best Overall
Choose the routing pattern that matches your failure and traffic goals
| Pattern | How requests move | Best fit | Main trade-off |
|---|---|---|---|
| Reverse proxy or load balancer | A proxy sends requests to an upstream pool. | Precise control, quick health reaction and one public entry point. | The proxy itself needs redundancy or managed hosting. |
| Managed edge load balancer | A provider monitors endpoints and steers traffic from its edge network. | Teams that want global routing and less proxy maintenance. | Recurring service cost and dependence on the provider. |
| DNS failover | Health checks cause DNS answers to change from a primary to a secondary resource. | Simple active-passive designs and provider-level failover. | Resolvers and browsers cache DNS, so the change is not instantaneous. |
| Active-active | Both healthy origins receive requests. | Higher aggregate capacity and concurrent availability. | Requires stateless request handling and shared or replicated data. |
| Active-passive | The primary serves until it is unhealthy; the secondary takes over. | Simpler write paths and controlled recovery. | Standby capacity may sit unused. |
When a reverse proxy is the right choice
Use a reverse proxy when you control a front-end host and need deterministic routing, connection draining or application-specific rules. NGINX supports round-robin routing by default, least-connected routing and IP-hash routing. Its open-source build provides passive failure detection; the commercial NGINX Plus edition adds active health checks and session persistence.
When managed edge load balancing is easier
A managed edge service removes the need to operate the public proxy yourself. You define a monitor, a pool and two endpoints, then select active-active steering or primary/secondary pools. The service checks each endpoint and directs traffic from its edge network. This is convenient for geographically distributed users, but you pay a recurring service charge and accept the provider’s monitoring and routing model.
When DNS failover is sufficient
DNS failover is a practical active-passive design. Health checks evaluate the primary endpoint; a failover record returns the secondary when the primary is unhealthy. Weighted records can distribute requests among several healthy resources, but DNS remains a cached control plane. A resolver may continue returning an old answer until its time-to-live expires, so DNS failover should not be described as instant.
Requirements before you add a second server
Make the origins equivalent
Server A and Server B should receive the same application release, web-server configuration, runtime version, TLS policy, environment variables and firewall rules. Use repeatable deployment or configuration management so a change made to one origin is either applied to the other or rejected before it creates drift.
Record the intended state of both servers, including enabled modules, scheduled jobs, certificates, outbound permissions and resource limits. A failover target that is missing a plugin, migration or environment variable can appear healthy while returning errors to users.
Keep mutable state out of the web tier
A request can land on either origin, so data written only to Server A will be invisible when the next request reaches Server B. Move mutable state to services designed to be shared or replicated:
- Database: Store authoritative application records in a replicated or managed database outside the web servers.
- Uploads and generated files: Use shared storage or an object store rather than a local directory on one origin.
- Sessions: Store them in a shared cache or database, or use appropriately signed client-side sessions.
- Carts and queues: Put them in shared durable services if a user must see the same state after a route change.
Stateless web tiers scale horizontally because any available compute resource can serve a request. This does not make the database or file store automatically redundant; those layers need their own replication and recovery plan.
Rank #2
Plan DNS, certificates and firewall rules
Decide whether the public hostname resolves to the proxy, an edge load balancer or a DNS failover record. Install a certificate that covers the hostname at the public TLS endpoint and, when traffic is encrypted between the router and origins, use certificates and trust settings appropriate for that private hop as well.
Allow origin traffic only from the routing layer or approved health-check addresses where possible. Permit administrative access separately. Both origins must expose the monitored port and path, but they should not be broadly reachable from the public internet merely because they are behind a router.
Step-by-step setup
1. Build and verify Server A and Server B
- Provision the second server with the same operating-system family, runtime and web-server versions as the first, or document any intentional difference.
- Deploy the identical application artifact to both origins.
- Apply the same virtual-host settings, TLS policy, environment variables, firewall rules and scheduled-task behavior.
- Run database migrations once through a controlled process; do not let two independent web servers race to change the schema.
- Test each origin directly over its private address or temporary administrative hostname before placing it behind the public name.
Direct testing should cover the home page, authenticated pages, form submissions, uploads, background jobs and error handling. Confirm that both origins can reach every shared dependency.
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 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute2. Externalize sessions, files and database writes
- Create or select the shared database and configure both origins with the same connection settings.
- Move user-uploaded and generated content to shared storage or an object store. Ensure both origins use the same path or storage API.
- Configure a shared session backend, or use signed client-side sessions only when the application’s security model supports them.
- Check cache behavior. A local cache can be used for disposable data, but never let it become the only copy of an authoritative record.
- Document backup, restoration and replication status for each stateful service.
For WordPress and similar applications, the database must be outside the web tier, and uploads, themes and plugins need shared storage or an equivalent deployment mechanism. Copying the web directory once is not enough if users can upload media or administrators can change content.
3. Put a routing layer in front
Option A: NGINX reverse proxy
Define an upstream containing both private origin addresses, then proxy the public virtual host to that upstream. A minimal arrangement looks like this:
upstream website_origins {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
}
server {
listen 443 ssl;
server_name www.example.com;
location / {
proxy_pass http://website_origins;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Round robin is the default. Choose least connections when request durations vary substantially, or IP hash when a temporary affinity requirement justifies it. IP hash is not a substitute for shared sessions: a client can change networks, an origin can fail, and the hash does not replicate data.
With an open-source build, passive checks remove an origin after connection or response failures observed during normal traffic. NGINX Plus can send active checks at regular intervals and supports session persistence. Its documented default active-check interval is five seconds; treat that as a product default, not a universal recovery-time guarantee.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Option B: Managed edge load balancing
- Create a monitor for the application’s health endpoint.
- Create a pool and add Server A and Server B as endpoints.
- Choose active-active steering when both can serve all requests, or configure primary and secondary pools for active-passive behavior.
- Set the monitor protocol, port, path, expected status codes, timeout, retry behavior and recovery threshold.
- Point the public hostname at the managed service and verify that the service can reach both origins.
Monitor intervals vary by service plan. Do not infer a guaranteed failover time from a monitor interval alone: detection, routing propagation, connection draining and DNS caching can all affect what users observe.
Option C: DNS health-check failover
- Create a health check for the primary origin or its public routing endpoint.
- Create a failover record marked primary and a second record marked secondary.
- Configure the health-check association so the secondary answer is returned when the primary is unhealthy.
- Set a time-to-live appropriate for the acceptable caching window, then test from multiple recursive resolvers.
- If you need distribution instead of standby, use weighted records only when each destination is independently ready to serve traffic.
Route 53 supports health checks with failover records and can route from an unhealthy web server to a healthy one. DNS caching means some users may continue reaching the old destination until their resolver refreshes its answer.
4. Publish a meaningful health endpoint
Create a lightweight endpoint such as /healthz that returns success only when the origin should receive user traffic. At minimum, verify that the web process and application can answer. For a site that cannot function without its database, cache or file store, include those critical dependencies in the check.
A check that returns “OK” while the application cannot connect to its database creates a false healthy signal. Conversely, checking every optional third-party integration can remove a usable origin for a non-critical outage. Define the dependency boundary explicitly.
Configure the monitor’s protocol, port, path, timeout, retry count and recovery threshold. Keep the endpoint fast and exclude expensive reports, full-page rendering and side effects. Never make a health check create orders, send email or mutate production data.
5. Handle sessions deliberately
The most robust design lets any origin serve any request. Store session data in shared storage and ensure both servers use the same signing keys, cookie settings and expiration policy.
Sticky sessions, including IP-hash persistence, can be a transitional measure for an application that cannot yet share sessions. They reduce routing freedom, make uneven load more likely and do not protect data stored on a failed origin. Plan to remove affinity after state is externalized.
6. Protect the database and shared storage
Keep the database outside the two web servers and select a replicated or highly available configuration appropriate to the application. A Multi-AZ database arrangement can provide automatic failover and synchronous replication, but may add latency compared with a single-zone deployment.
Apply the same principle to file storage. Replicated storage must define conflict behavior, recovery point objectives and retention. If both origins can write the same file or record concurrently, application-level rules are still needed; replication alone does not decide which business value is correct.
7. Verify TLS, headers and client identity
When TLS terminates at a proxy, pass the original host and protocol headers to the application and configure the framework to trust only the expected proxy. Otherwise, redirects may loop, secure cookies may be omitted or generated links may use the wrong scheme. Confirm that both origins produce the same canonical host and redirect behavior.
Active-active or active-passive?
| Decision factor | Active-active | Active-passive |
|---|---|---|
| Traffic | Both origins serve production requests. | One origin serves; the other waits. |
| Capacity | Uses both servers during normal operation. | Standby capacity is underused until failover. |
| Failure impact | Traffic shifts away from the failed origin while the other continues. | Traffic moves to the standby after detection and any DNS caching delay. |
| Data requirements | Strong requirement for shared sessions and consistent writes. | Still requires shared or replicated data if users and writes must continue after takeover. |
| Operational simplicity | More demanding testing and concurrency controls. | Often simpler when a controlled primary is preferred. |
Choose active-active only when either server can safely receive every class of request. Choose active-passive when write ownership, licensing or application limitations make simultaneous service unsafe. A passive server still needs current code, configuration, certificates and data; an untested standby is not a recovery plan.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What happens during a failure?
- The routing layer’s monitor or normal request handling detects failed connections or an unhealthy response.
- The failed origin is removed from the eligible pool, or the DNS service begins returning the secondary answer.
- New connections go to the remaining healthy origin. Existing connections may fail and require client retries.
- Shared sessions and data allow the user to continue without being tied to the failed machine.
- After repair, the origin is checked again and reintroduced according to the router’s recovery or ramp-up behavior.
There is no universal recovery time, uptime percentage, latency reduction or throughput multiplier for a generic two-server website. Results depend on the monitor interval, retry policy, proxy capacity, DNS time-to-live, application startup time and the health of the database and storage layers.
Failure testing before launch
Test the design while monitoring and alerting are enabled, not only during a planned maintenance window.
- Confirm normal requests alternate or distribute as designed.
- Drain or stop Server A and verify that new requests reach Server B.
- Log in, browse authenticated pages, submit a write and upload a file while A is unavailable.
- Check that sessions remain valid and that the write and upload are visible from the surviving origin.
- Verify that the alert identifies A as unhealthy and that the health endpoint did not report a false success.
- Restore A, confirm it passes health checks, and observe whether traffic returns safely rather than in an uncontrolled surge.
- Repeat the complete test with Server B stopped.
- For DNS failover, test through more than one recursive resolver and record how long cached answers persist.
Document the observed behavior, the time to detection, the time to usable service and the steps required to return to normal. These are measurements of your implementation, not promises supplied by a product default.
Troubleshooting common two-origin failures
Users see intermittent logouts
Compare session-cookie signing keys, cookie domains, secure flags and session backends on both origins. If sessions are local, move them to shared storage before relying on active-active routing. Temporary stickiness may mask the symptom but does not fix failover.
Uploads disappear after a route change
Inspect the application’s upload path on both servers. A local directory on Server A is not shared with Server B. Use shared storage or an object store, then verify permissions, encryption and cleanup jobs from each origin.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
One origin passes health checks but returns errors
The check is probably too shallow. Test the application’s critical database, cache and storage dependencies, but keep optional integrations out of the eligibility decision. Return a failure status when the origin cannot serve the traffic it is receiving.
Failover appears slow
For a proxy, inspect monitor interval, retries, timeouts, connection draining and the proxy’s own availability. For DNS, inspect record time-to-live and resolver caches. A DNS answer already cached by a client cannot be withdrawn immediately by changing the authoritative record.
Data differs between origins
Check whether writes are reaching a single authoritative database, whether replication is healthy and whether both applications use the same schema version. Do not solve database inconsistency by copying web directories; code and data are separate concerns.
The proxy becomes a single point of failure
Run redundant proxy instances behind a managed edge service, anycast or another highly available front end, or use a managed load-balancing service. Two origins do not provide end-to-end availability if one unreplicated proxy is the only public entry point.
Free tools Windows power users keep installed
One-click scans. No signup required.
Cost and operational trade-offs
Two web servers add more than a second compute bill. Budget for the routing layer, health monitoring, replicated database capacity, shared storage, backups, certificates, observability and time spent testing failover. A managed edge service has recurring charges and provider dependency; a self-managed proxy avoids that service fee but transfers patching, redundancy and monitoring responsibilities to you.
Active-active can improve resource utilization because both servers handle normal traffic, but it raises the bar for session management, concurrent writes and deployment coordination. Active-passive can simplify application behavior, yet you still pay to keep the standby current and must test that it can accept production load.
Recommended baseline architecture
For a general website, a sensible baseline is two identical stateless application origins, a redundant or managed routing layer, a shared session store, replicated database service and shared object or file storage. Expose one health endpoint that checks the dependencies required for real requests. Start with active-passive if the application has single-writer constraints; use active-active after concurrency and failover tests demonstrate that either origin can safely serve every request.
This arrangement answers the practical question: one domain can serve two servers, but only the routing, state and failure procedures make those servers behave like one dependable website.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →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.
