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.
Yes. Keep one public hostname and place a routing layer in front of two equivalent origin servers. That layer can be an NGINX reverse proxy/load balancer, a managed edge service such as Cloudflare Load Balancing, or DNS health-check failover with Amazon Route 53. The design is reliable only when both origins run the same deployable application and every mutable item—database records, uploads, sessions, carts, and generated files—is shared or replicated.
Two servers alone do not create high availability. If a user’s session or the only copy of an uploaded file remains on Server A, sending the next request to Server B can still break the site. The routing method, state design, health checks, and failure testing must be planned together.
What “one website on two servers” actually means
A visitor enters one hostname, such as www.example.com. DNS resolves that hostname to a public entry point. A proxy, edge load balancer, or DNS policy then directs each request to Server A or Server B, which serve the same application.
The public URL does not change when traffic moves. TLS certificates, firewall rules, deployment files, environment variables, and application versions must be compatible on both origins. The database and other durable state normally live outside the web servers so either origin can process a request.
#1 Best Overall
- 【Five Gigabit Ports】1 Gigabit WAN Port plus 2 Gigabit WAN/LAN Ports plus 2 Gigabit LAN Port. Up to 3 WAN ports optimize bandwidth usage through one device.
- 【One USB WAN Port】Mobile broadband via 4G/3G modem is supported for WAN backup by connecting to the USB port. For complete list of compatible 4G/3G modems, please visit TP-Link website.
- 【Abundant Security Features】Advanced firewall policies, DoS defense, IP/MAC/URL filtering, speed test and more security functions protect your network and data.
- 【Highly Secure VPN】Supports up to 20× LAN-to-LAN IPsec, 16× OpenVPN, 16× L2TP, and 16× PPTP VPN connections.
- Security - SPI Firewall, VPN Pass through, FTP/H.323/PPTP/SIP/IPsec ALG, DoS Defence, Ping of Death and Local Management. Standards and Protocols IEEE 802.3, 802.3u, 802.3ab, IEEE 802.3x, IEEE 802.1q
A simple DNS record containing two addresses is possible, but it is not equivalent to a health-aware load balancer. Resolvers cache DNS answers, clients may continue using an unhealthy address, and DNS has no knowledge of whether an application is actually ready to serve traffic. Use DNS distribution only when its caching and failure behavior fit your tolerance.
Choose the traffic-routing pattern
| Pattern | How requests move | Best fit | Main trade-off |
|---|---|---|---|
| Reverse proxy or load balancer | A proxy sends requests to an upstream pool containing both origins. | Precise control, one public entry point, and rapid health-based removal. | The proxy becomes another component that needs redundancy or managed hosting. |
| Managed edge load balancer | A provider monitors endpoints from its edge network and steers requests to healthy pools. | Teams that want global routing and less proxy maintenance. | Recurring service cost and dependence on the provider’s control plane. |
| DNS failover | Health checks cause DNS answers to switch from a primary record to a secondary record. | Simple active-passive designs and provider-level failover. | Resolver and browser caching means the change is not instantaneous. |
| Active-active | Both healthy origins receive production traffic. | Higher aggregate capacity and concurrent availability. | Every request must work on either server, and shared data must remain consistent. |
| Active-passive | The primary serves traffic while the secondary waits for a failure. | Controlled writes and simpler applications. | Standby capacity is underused until a failover. |
When a reverse proxy is the right choice
Put NGINX or another proxy in front of the origins when you need central TLS termination, path-based routing, connection limits, or predictable health behavior. NGINX uses round-robin balancing by default; its upstream configuration can instead use least connections or IP-hash when a specific workload justifies it. The open-source build relies on passive checks, while NGINX Plus adds active checks and session-persistence features.
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 matchWhen managed edge balancing is simpler
Cloudflare Load Balancing represents origins as endpoints in pools. You can run an active-active design with multiple endpoints in one pool, or an active-passive design with primary and secondary pools. A monitor defines the protocol, path, expected status codes, timeout, retry behavior, and interval. This removes the need to operate your own public proxy, but the monitor interval and available controls vary by plan.
When DNS failover is sufficient
Amazon Route 53 can associate health checks with primary and secondary failover records. When the primary is unhealthy, DNS responses favor the healthy secondary. Weighted records can distribute requests among several healthy resources, but DNS caching still controls how quickly clients observe a new answer. DNS failover is therefore best for tolerant, mostly active-passive services rather than applications that require immediate connection draining.
Design the two origins before changing DNS
Make Server A and Server B equivalent
Install the same operating-system packages, application release, web-server configuration, TLS policy, environment variables, and firewall rules. A request should not succeed on one origin and fail on the other because of a missing plugin, different runtime version, or a blocked database port.
- Use repeatable deployment or configuration-management automation rather than manual edits.
- Record the exact application and schema versions deployed to each host.
- Keep secrets in a controlled secret store or synchronized configuration process.
- Open only the required public, proxy-to-origin, administration, and database paths.
- Verify that both hosts have synchronized clocks and matching logging formats.
Run a configuration-drift check after every release. A two-origin system with drift is effectively a single reliable server plus an unpredictable fallback.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteRank #2
- 【Flexible Port Configuration】1 2.5Gigabit WAN Port + 1 2.5Gigabit WAN/LAN Ports + 4 Gigabit WAN/LAN Port + 1 Gigabit SFP WAN/LAN Port + 1 USB 2.0 Port (Supports USB storage and LTE backup with LTE dongle) provide high-bandwidth aggregation connectivity.
- 【High-Performace Network Capacity】Maximum number of concurrent sessions – 500,000. Maximum number of clients – 1000+.
- 【Cloud Access】Remote Cloud access and Omada app brings centralized cloud management of the whole network from different sites—all controlled from a single interface anywhere, anytime.
- 【Highly Secure VPN】Supports up to 100× LAN-to-LAN IPsec, 66× OpenVPN, 60× L2TP, and 60× PPTP VPN connections.
- 【5 Years Warranty】Backed by our 5-years warranty and free technical support from 6am to 6pm PST Monday to Fridays
Externalize every mutable item
Do not keep the authoritative copy of user data on only one web server. Use a shared filesystem or object storage for uploads and generated assets, and use a replicated or managed database for durable records. Sessions belong in a shared cache or database, or in a correctly signed client-side format when the application supports that model.
Stateless web tiers are what make horizontal scaling possible: any available compute resource can handle the next request. If the application writes to local disk, keeps an in-memory session, or stores a shopping cart only on one host, active-active routing can expose inconsistent behavior.
WordPress and similar file-based applications
A WordPress installation needs its database outside the web tier and shared storage for uploads, themes, and plugins. Deploying identical files once is not enough if an administrator uploads media or updates a plugin on only one origin. Either place those files in shared storage or make the deployment pipeline replicate them before routing users to the second server.
Step-by-step setup with an NGINX reverse proxy
1. Prepare private origin addresses
Give each origin a stable private address reachable from the proxy. Restrict the origin firewall so application traffic is accepted from the proxy’s addresses, not from the entire internet. If the proxy and origins are in different networks, verify routing and security-group rules before putting production DNS in place.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →2. Define an upstream pool
The following example uses the default round-robin method. Replace the addresses and port with your own values:
upstream website_origins {
server 10.0.1.10:8080;
server 10.0.2.10: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-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Terminate TLS at the proxy only if the proxy-to-origin connection is protected to the level your threat model requires. Otherwise configure HTTPS to each origin as well and validate the origin certificates. Ensure the application trusts the forwarded protocol and client-IP headers; an incorrect setting can create redirect loops or misleading audit logs.
Rank #3
- 【Flexible Port Configuration】1 Gigabit SFP WAN Port + 1 Gigabit WAN Port + 2 Gigabit WAN/LAN Ports plus1 Gigabit LAN Port. Up to four WAN ports optimize bandwidth usage through one device.
- 【Increased Network Capacity】Maximum number of associated client devices – 150,000. Maximum number of clients – Up to 700.
- 【Integrated into Omada SDN】Omada’s Software Defined Networking (SDN) platform integrates network devices including gateways, access points & switches with multiple control options offered – Omada Hardware controller, Omada Software Controller or Omada cloud-based controller(Contact TP-Link for Cloud-Based Controller Plan Details). Standalone mode also applies.
- 【Cloud Access】Remote Cloud access and Omada app brings centralized cloud management of the whole network from different sites—all controlled from a single interface anywhere, anytime.
- 【SDN Compatibility】For SDN usage, make sure your devices/controllers are either equipped with or can be upgraded to SDN version. SDN controllers work only with SDN Gateways, Access Points & Switches. Non-SDN controllers work only with non-SDN APs. For devices that are compatible with SDN firmware, please visit TP-Link website.
3. Select a balancing method deliberately
- Round robin: a straightforward distribution for similar origins and stateless requests.
- Least connections: useful when requests have very different durations and the less-busy server should receive the next connection.
- IP hash: tends to send a client to the same origin, but it can overload one host, fails with changing client addresses, and does not replicate session data.
Use IP hash or commercial session persistence only as a transitional measure. It cannot protect a session when the selected server fails, and it limits your ability to drain or rebalance traffic.
4. Validate the proxy before cutover
- Check the NGINX configuration with
nginx -t. - Reload the service using your operating system’s service manager.
- Resolve the private origin names or addresses from the proxy host.
- Request the health path and a normal page through the proxy.
- Inspect access logs on both origins to confirm that traffic is distributed as expected.
Configure health checks that represent real readiness
Create a lightweight endpoint such as /healthz. It should verify that the web process is running and, when the application requires it, that critical dependencies such as the database or session store are reachable. Return a success status only when the server should receive user traffic. A process-level check that stays green while every database request fails will keep routing users to a broken origin.
For any monitor, set the protocol, port, path, timeout, retry count, and recovery threshold deliberately. A check that is too aggressive can flap during a brief network delay; one that is too slow extends the period in which users reach a failed host. NGINX Plus active checks send periodic requests and stop routing to an unhealthy upstream; its documented default active-check interval is five seconds. That value is a product default, not a guaranteed recovery time.
Use a separate deep diagnostic endpoint for administrators if checking every dependency would create load or expose sensitive details. The public health response should contain no credentials or internal topology.
Keep sessions and writes consistent
Prefer shared session storage
Store sessions in a shared database or cache so a request can move from Server A to Server B without forcing a login. Signed client-side sessions can also work when their size, key rotation, and revocation model are acceptable. If you temporarily use sticky sessions, document the failure behavior and migration plan; persistence does not copy data between servers.
Protect ordering and duplicate writes
Retries can cause a payment, form submission, or background job to be delivered more than once. Use idempotency keys and database constraints where the application handles non-repeatable operations. Keep authoritative writes in the database, not in a local file that exists on one origin.
Recommended Free Tools
Coordinate background workers
Running scheduled jobs on both servers can duplicate emails, imports, or cleanup tasks. Elect one worker, use a distributed lock, or make each job safely repeatable. The web load balancer does not coordinate background work for you.
Put the database and storage in a highly available layer
Separate compute, load balancing, database, cache, and shared storage rather than assuming two web servers protect the entire stack. A single database on Server A remains a single point of failure even if the web tier is active-active.
Choose a replicated or managed database appropriate to your write volume and recovery objectives. AWS RDS Multi-AZ, for example, provides synchronous replication and automatic failover; the additional coordination can introduce latency compared with a single-AZ deployment. Confirm how your application handles a database endpoint change and whether connections are retried safely.
For files, object storage or a shared filesystem prevents an upload from disappearing when the next request reaches the other origin. For caches, accept that a cache miss is recoverable and keep the source of truth in durable storage.
DNS, TLS, and deployment details
Point one hostname at the routing layer
With a proxy or edge balancer, publish the hostname’s address at that layer and keep origin addresses private where possible. With Route 53 failover, publish primary and secondary records with health checks. Set a DNS TTL that balances resolver load with the time you can tolerate stale answers; no TTL makes failover instantaneous because clients and intermediate resolvers may cache responses.
Keep certificates valid during a failover
The certificate presented to visitors must cover the single public hostname at every public termination point. If TLS terminates on both origins, install matching certificates and renewal automation on both. Test renewal before expiry and verify that a newly issued certificate is available on the standby before it is needed.
Deploy without creating version splits
Use a rolling or blue-green process that preserves compatibility between the application and database schema. During a migration, both versions may receive traffic, so add columns before code that reads them and remove old fields only after all origins have moved forward. Drain an origin before maintenance rather than stopping it abruptly.
Best Value
- Multi-WAN Business Continuity: Connect up to 5 ISPs with automatic failover and load balancing — if one connection drops, traffic instantly reroutes to keep your business, remote office, or home lab online
- OpenWRT-Ready Enterprise Control: Full OpenWRT support unlocks VLAN segmentation, advanced firewall rules, custom QoS policies, and community-developed packages for professional-grade network management
- Complete VPN Gateway Suite: WireGuard, OpenVPN, IPsec, PPTP, and L2TP server and client built in; create site-to-site tunnels, host remote access, or route specific VLANs through encrypted VPN connections
- Professional Security Stack: SPI firewall, DoS attack prevention, IP/MAC binding, domain filtering, and DMZ hosting protect your network perimeter while keeping critical services accessible
- Flexible Deployment & Monitoring: Web GUI or Cudy App cloud management with TR-069 support; built-in diagnostic tools (Ping, Traceroute, NSLookup, system logs) for rapid troubleshooting anytime
Active-active versus active-passive: a practical decision
| Question | Active-active answer | Active-passive answer |
|---|---|---|
| Can either server process any request? | Yes; this is a requirement. | Usually the primary handles requests until failover. |
| How are writes handled? | Both may write through shared, consistency-aware data services. | Writes can be concentrated on the primary, simplifying some applications. |
| Capacity during normal operation | Both servers contribute capacity. | The standby is mostly unused. |
| Failure behavior | Traffic is redistributed while the remaining server continues serving. | Traffic switches after health checks and DNS or proxy policy allow it. |
| Operational burden | Higher: state, locking, and deployment compatibility must be solved continuously. | Lower for some write-heavy apps, but standby readiness must be maintained. |
Choose active-active for throughput or concurrent availability when the application is genuinely stateless and the data layer supports concurrent use. Choose active-passive when a single writer or controlled failover is more important than using all capacity continuously.
Test failure before calling the design highly available
- Enable monitoring and alerting for proxy, origin, database, storage, and certificate failures.
- Drain or stop Server A while serving real or representative requests.
- Confirm new requests reach Server B, authenticated sessions remain valid, and writes appear once in the authoritative database.
- Check that the monitor marks A unhealthy and that logs identify the transition.
- Restore A, verify that it passes readiness checks, and observe its controlled re-entry rather than an abrupt traffic surge.
- Repeat the exercise by failing Server B.
- Test loss of the database, cache, shared storage, proxy, and DNS provider separately; two healthy origins cannot compensate for a failed shared dependency.
Measure the behavior you actually need—error rate, time to stop sending traffic, recovery of sessions, and operator alert time. There is no universal uptime percentage, latency reduction, throughput multiplier, or recovery time for a generic two-server website.
Troubleshoot the common failure modes
Users see intermittent 5xx errors
Check whether one origin is missing a dependency, has a different release, or cannot reach the database. Remove the failing origin from the pool while you correct configuration drift, then compare environment variables and firewall logs.
Users are logged out after a request moves
The session is local to one host or the cookie domain, encryption key, or session-store connection differs. Move sessions to shared storage and synchronize signing or encryption keys. Do not treat IP hash as a permanent fix.
Uploaded images or generated files vanish
The files are on local disk. Migrate them to shared storage, replicate them as part of deployment, or route all file reads and writes through an object-storage layer.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
DNS failover appears slow
Resolvers and clients are honoring cached answers. Confirm the record TTL, health-check state, and which resolver the affected user is using. If the service requires faster, connection-aware removal, use a proxy or managed edge balancer instead of relying solely on DNS.
The health check is green while the site is unusable
The endpoint checks only the web process. Add the critical dependency checks needed for safe routing, while keeping diagnostic detail out of the public response. Also verify that the monitor uses the same hostname, protocol, port, and authentication behavior as real traffic.
The proxy itself fails
A self-managed single proxy is a new single point of failure. Run redundant proxy instances behind a managed front end or use a managed edge load balancer. If DNS points directly to one proxy, the two origins do not protect that proxy.
Which approach should you choose?
| Your requirement | Most suitable starting point | Why |
|---|---|---|
| One site, two similar servers, central control | Redundant NGINX reverse proxies | Explicit upstream policy, TLS control, and fast removal of failed origins. |
| Global users and minimal proxy maintenance | Managed edge load balancing | Provider-operated monitoring and geographic traffic steering. |
| Primary plus warm standby, tolerant of DNS delay | Route 53 health-check failover | Simple record-based policy with provider health checks. |
| Application cannot share sessions or files yet | Active-passive only after documenting limitations | It reduces cross-server state conflicts, but it is not a substitute for replication. |
Regardless of the routing product, the non-negotiable sequence is the same: make both origins reproducible, move mutable state to shared or replicated services, define a readiness check, secure the origin path, and rehearse failure. Once those pieces work, one hostname can reliably span two servers without exposing users to which origin handled their request.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →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.
