DNS Load Balancing

WordPress DNS Load Balancing

A custom WordPress domain with several A records normally relies on DNS Round-Robin, which can still return an IP address for an unavailable endpoint. DNS load balancing adds health checks and smarter routing so visitors can be directed only to healthy WordPress entry points.
Health Checks Continuously verify whether each WordPress load-balancer endpoint is reachable.
Smart Routing Route users according to endpoint health, latency, or geographic location.
Higher Availability Reduce the chance of sending visitors to a failed endpoint, especially in multi-region deployments.
On this page

Why Use DNS Load Balancing

When a WordPress custom domain has several A records, standard DNS Round-Robin can return every registered IP address, including one that is temporarily unavailable. A DNS load-balancing service can actively check endpoint health and exclude failed destinations from DNS responses.

  • Perform health checks for each WordPress endpoint.
  • Route users according to geographic location when supported.
  • Compare endpoint latency and direct traffic to faster locations.
  • Provide automatic failover when an origin becomes unhealthy.
This is particularly useful for WordPress clusters with multiple load balancers and for multi-region installations hosted in separate data centers.

The workflow below uses Cloudflare DNS Load Balancing as an example. The same overall approach can be implemented with another DNS provider that supports origin pools, health checks, and DNS traffic steering.

Create the DNS Load Balancer

1Open Load Balancing

In the Cloudflare dashboard, navigate to Traffic > Load Balancing and click Create Load Balancer.

2Enter the WordPress custom domain

Specify the custom domain that already has A records pointing to the WordPress load-balancer endpoints.

DNS-only configuration: Disable Cloudflare traffic proxying for this setup. The goal is to balance DNS resolution rather than send website traffic through the Cloudflare reverse proxy.
Create DNS load balancer
Create a load balancer for the WordPress custom domain and keep proxying disabled.

Create Origin Pools

Create one origin pool for each WordPress entry point that should participate in DNS balancing. In the example architecture, the WordPress cluster contains two load balancers, so two origin pools are created.

1Create the first pool

Enter a pool name and origin name, then use the public IP address of one WordPress load balancer as the Origin Address.

2Set origin weight

If both WordPress load balancers are intended to be treated equally, use the same weight for each origin. The source example assigns a weight of 1.

3Add notification email

Specify an email address if you want to receive health-check and origin-status notifications.

Create DNS origin pool
Create an origin pool using the public IP address of a WordPress load balancer.

Save the pool and repeat the same procedure for every additional WordPress load-balancer endpoint.

Configure Health Monitoring

1Create a monitor

For the first origin pool, click Attach monitor > Create a Monitor.

Create monitor button
Create a health monitor for the WordPress origin pool.

Configure the monitor parameters according to the WordPress endpoint. A typical HTTPS health check can use the root path and expect a successful HTTP response.

Protocol Use HTTPS when the WordPress custom domain is secured with SSL.
Path Check / or another reliable application-health path.
Expected Status Treat a successful 2xx response as healthy.
Configure DNS load balancer health monitor
Example HTTPS health-check configuration for the WordPress custom domain.
Subscription-dependent features: Some monitor options, regions, intervals, and traffic-steering capabilities may depend on the DNS provider’s service plan and can involve additional cost.

2Attach the monitor

Save the monitor and attach it to the first origin pool. Add a notification address if required.

Attach monitor to origin pool
Attach the created health monitor to the first origin pool.

3Monitor every origin

Attach the same monitor to the remaining origin pools and verify that all configured origins report a healthy state before continuing.

Attach monitor to second origin
Use the same health monitor for all equivalent WordPress origins.

Select Traffic Steering

Traffic Steering controls how DNS responses choose among the available healthy origin pools.

  • Off / Standard Failover — use the next healthy pool when the preferred pool becomes unavailable.
  • Random — select a healthy pool randomly.
  • Dynamic Steering — favor the fastest healthy pool using measured latency.
  • Geo Steering — route clients to pools according to region or point of presence, with failover ordering where supported.
DNS traffic steering options
Select the routing strategy that matches the WordPress architecture.
For two equivalent load balancers in the same region, standard failover is usually sufficient. Multi-region WordPress installations can benefit more from latency-aware or geographic steering.

Review and Deploy

1Review the configuration

Verify the hostname, origin pools, attached monitors, failover order, and selected Traffic Steering mode.

Review DNS load balancer
Review the DNS load-balancer settings before deployment.

2Deploy the load balancer

Click Save and Deploy. The WordPress custom domain will now be resolved through the configured DNS load-balancing policy.

Test DNS Failover

After deployment, simulate a load-balancer failure to confirm that DNS resolution removes the unhealthy origin and keeps the WordPress website reachable.

1Check current DNS resolution

Connect to a WordPress load-balancer node through Web SSH and verify that the domain initially resolves to all healthy endpoints.

dig wordpress-enterprise.jele.website +short

2Simulate an endpoint failure

Stop the load-balancer service on one node.

sudo jem service stop

3Wait for the health check

Wait approximately one health-check interval. In the source example this is 60 seconds.

  • Open the WordPress website and confirm it is still available.
  • Resolve the custom domain again and verify that only the healthy endpoint is returned.
  • Check the DNS-provider dashboard and confirm that the failed pool is marked unhealthy or degraded.
  • If notifications are enabled, verify that the failure alert was received.
DNS failover returns healthy IP
After the simulated failure, DNS resolution returns the healthy WordPress endpoint.
Failed origin in DNS load balancer
The DNS load-balancer dashboard identifies the failed origin while keeping the healthy pool active.
DNS load balancer failure notification
Example email notification generated when an origin health check fails.

4Restore the endpoint

Start the load-balancer service again after the failover test.

sudo jem service start

Wait for the next health-check cycle and verify that the restored origin returns to a healthy state and becomes available for DNS routing again.

All DNS origins healthy
Both origin pools are healthy again after the failed service is restored.

Adjust Load Balancer Features

After testing, review the available DNS load-balancing features and tune them according to the application architecture, required recovery time, and service plan.

  • Origin Servers — increase or reduce the number of backend endpoints.
  • Faster Checks — modify how frequently health checks are performed.
  • Check From — select how many regions perform health checks.
  • Traffic Steering — change the routing algorithm as the WordPress deployment evolves.
Adjust DNS load balancer features
Review additional DNS load-balancer capacity and routing options after testing.
Result: DNS load balancing improves WordPress resilience by removing failed endpoints from DNS routing and, where supported, directing visitors according to health, latency, or location.

What’s next?