multi-servers for wordpress multisites

Part 2: Expanded Load Balancing Deployment Guide | WordPress Multisite Subdomain SaaS Scaling

Part 2: Expanded Load Balancing Deployment Guide | WordPress Multisite Subdomain SaaS Scaling

multi-servers for wordpress multisites

Preface

This part is the expanded exclusive supplement for WordPress Multisite subdomain SaaS scaling. It focuses on Layer7 load balancer deployment only, keeps the original *.domain.com wildcard DNS resolution logic unchanged, ensures zero modification for tenant custom domain CNAME binding, and provides production-grade selection rules, traffic rules, full configuration, fault fixes and security policies for multi-server WP cluster. All services adopt mainstream overseas cloud-native products, fully compatible with subdomain-mode WordPress Multisite + MU Domain Mapping / native domain mapping module.


2. Load Balancing Layer Core Deployment (Retain Original Wildcard DNS 100%)

The load balancer acts as the single global traffic gateway for the entire WordPress Multisite SaaS platform. It undertakes wildcard domain reception, tenant custom domain SNI matching, layer4/layer7 traffic scheduling, unified SSL lifecycle management, edge traffic filtering, backend node health governance, and protocol forwarding. For subdomain-based WordPress Multisite, complete original Host header transparency is the non-negotiable core rule, otherwise wp_blogs domain matching will fail and cause 404 / wrong site redirect errors.

2.1 Load Balancer Category Full Comparison (Overseas Cloud Native Options Only)

Adapted for global SaaS business, tenant cross-region access, massive custom domain hosting, long-term iteration scaling, sorted by production priority:

Load Balancer TypeRepresentative Overseas ServiceCore Advantages for WP Multisite SaaSLimitations & Applicable Scale
Global Anycast Edge Load Balancer (Top Recommended)Cloudflare Load Balancing, Cloudflare Enterprise Edge Proxy1. Native wildcard DNS linkage, built-in *.domain.com proxy; 2. Global node acceleration for overseas tenants; 3. Built-in WAF, DDoS protection, bot filtering; 4. Native On-Demand TLS for unlimited tenant custom domains; 5. Zero public IP exposure for origin WP servers; 6. Zero extra SSL deployment work; 7. Layer7 full header preservation native supportPaid enterprise plan required for unlimited custom domains; best for 500+ subsite commercial SaaS
Cloud Managed Application Load Balancer (Layer7 Official Cloud LB)AWS ALB, GCP Cloud Application Load Balancer, Azure ALB, DigitalOcean Load Balancer1. Official cloud VPC private network docking, stable low latency; 2. Native SNI multi-cert management; 3. Cloud native health check, auto node failover; 4. Integrated cloud security group access control; 5. Perfect compatible with AWS/GCP/Azure RDS + Object Storage ecosystemManual certificate import required for tenant custom domains; higher cost for massive custom domains; suitable for 50-500 subsite mid-scale SaaS
Self-Hosted Layer7 Reverse Proxy Load BalancerSelf-hosted Caddy v2, Self-hosted Nginx Plus, HAProxy 2.8+1. Full traffic rule customization, lowest long-term cost; 2. Caddy native on-demand TLS free certificate issuance; 3. Independent rule modification without cloud vendor restriction; 4. Fine-grained header rewriting for WordPress special compatibilityRequires professional DevOps daily operation; need self-build high-availability standby cluster; suitable for small-scale 2-4 WP node private deployment

2.2 Two Standard DNS Deployment Modes (Keep Original *.domain.com Logic 100%)

No matter which load balancer you choose, your original tenant access link will not change, no tenant-side operation needed, no custom domain rebinding required for existing users:

Mode A: Traditional Public IP Forward Mode (VPC Private Cluster)

  1. Modify DNS provider (Cloudflare DNS, Namecheap DNS, GoDaddy DNS) record: Edit *.domain.com wildcard A/AAAA record, point record value to load balancer static public IP
  2. Traffic path: Tenant custom domain → CNAME to xxx.domain.com → Resolve to LB public IP → LB forward to backend WP private nodes
  3. Applicable scenario: Self-hosted Nginx/HAProxy, AWS/GCP native ALB deployment

Mode B: Cloudflare Proxy Mode (Most Stable for Global SaaS)

  1. Set *.domain.com DNS record to Cloudflare proxied orange-cloud status
  2. Origin WP servers only allow Cloudflare IP range access, close global public access
  3. Traffic path: All tenant domain traffic pass Cloudflare edge first, then dispatch to origin multi-WP servers
  4. Core benefit: Hide origin server IP, resist DDoS, reduce WP server bandwidth consumption

2.3 Mandatory Layer7 Header Passthrough Rules (WP Multisite Critical Rules, Must Not Modified)

WordPress Multisite subsite matching only depends on original browser Host header. Any header modification will cause cross-site access failure, custom domain binding failure, backend login cookie failure. All load balancers must configure the following full forwarding rules, no header override allowed:

  • Host Header Forced Passthrough: Reserve original visitor domain Host, do not replace with backend node domain
  • Real Visitor IP Chain Forward: Complete X-Forwarded-For chain for WP security log, limit login IP function
  • Original Protocol Forward: Mark visitor actual HTTP/HTTPS access protocol to solve backend redirect loop
  • Forwarded Host Integrity Lock: Disable LB default host rewrite function

2.4 Unified SSL Termination Strategy (3 Modes for SaaS Tenant Domain)

Unified SSL termination means all HTTPS handshake completed on load balancer, backend WP nodes run HTTP internal communication, reduce PHP/Web server SSL computing overhead, classified 3 deployment modes for different tenant domain quantities:

Mode 1: Fixed Wildcard SSL (Only for Official Subdomain *.domain.com)

Apply paid wildcard SSL certificate from Sectigo, DigiCert, GlobalSign, deploy on LB, cover all auto-generated tenant subdomains like user1.domain.com, shop.domain.com. Suitable for tenants who do not need custom domain binding.

Mode 2: SNI Multi-Certificate Hosting (Managed LB Manual Upload)

For tenants who bind independent brand domains, upload each tenant SSL certificate to AWS ALB/GCP ALB SNI certificate pool. LB automatically match Host header to return corresponding certificate. Defect: Manual certificate renewal, not suitable for more than 100 custom domains.

Mode 3: On-Demand TLS Auto SSL (SaaS Unlimited Custom Domain Best Mode)

Supported by Cloudflare Enterprise + Self-hosted Caddy v2 only: Automatically verify domain ownership via ACME protocol, issue free Let’s Encrypt / ZeroSSL certificate for any new tenant custom domain within 10s, auto-renew certificates permanently, zero manual operation. Fully adapted to WordPress Multisite custom domain mass binding scenario.

2.5 Load Balancer Traffic Scheduling Algorithm Selection (WP SaaS Dedicated)

Disable default random scheduling, select algorithm based on WP session and resource features:

  • Recommended: Least Connections Algorithm (Production Default): Distribute new visitor request to the backend WP node with the smallest current active PHP connections. Balance server CPU/PHP-FPM load perfectly, avoid single node overload caused by large resource-consuming WP themes/plugins.
  • Optional: Weighted Round Robin: Set weight value for new/old servers. For example, old server weight=2, new server weight=3, divert more traffic to newly added high-performance server, realize gradual traffic migration.
  • Forbidden Algorithm: IP Hash Session Persistence: Fixed one visitor to one fixed WP node. Will cause extreme load imbalance, fail auto-failover, conflict with global dynamic residential IP tenants, strictly forbidden for WP Multisite SaaS cluster.

2.6 Backend Node Health Check & Automatic Failover Configuration

Configure active health check on load balancer to eliminate faulty nodes automatically, avoid partial tenant access outage:

  1. Health Check Protocol: Layer7 HTTP GET Check (more accurate than port check)
  2. Check Path: /wp-includes/images/blank.gif (default static file, no PHP database query, zero server overhead)
  3. Check Rule: 200 OK status code = healthy; 3 consecutive timeout/5xx code = mark node unhealthy, automatically remove from scheduling pool
  4. Recovery Rule: Auto rejoin cluster after 3 consecutive healthy detection

2.7 Self-Hosted Production-Grade HAProxy Load Balancer Full Config (High-Availability, Better Than Nginx for WP Cluster)

HAProxy 2.9+ recommended for multi-tenant header stability, superior connection scheduling capability for WordPress PHP persistent connection:

# Global SaaS Tuning Parameter
global
    maxconn 100000
    tune.ssl.default-dh-param 2048
    log /dev/log local0

# Backend WP Cluster Pool With Least Connections Scheduling
backend wp_multisite_pool
    mode http
    balance leastconn # Core: least connection load balance
    option http-keep-alive
    option forwardfor
    # Backend private WP nodes
    server wp-node1 10.0.2.10:80 check inter 2000 rise 3 fall 3 weight 2
    server wp-node2 10.0.2.11:80 check inter 2000 rise 3 fall 3 weight 3

# Frontend HTTP Redirect Listener
frontend http_in
    bind 0.0.0.0:80
    mode http
    acl wildcard_domain hdr_end(host) -i .domain.com
    redirect scheme https code 301 if wildcard_domain

# Frontend HTTPS Main Listener
frontend https_in
    bind 0.0.0.0:443 ssl http2 alpn h2,http/1.1
    mode http
    # Load wildcard SSL cert
    sslcrt /etc/haproxy/ssl/wildcard.domain.com.pem
    # Core mandatory header forwarding rules for WP Multisite
    http-request set-header Host %[req.hdr(Host)]
    http-request set-header X-Forwarded-For %[src]
    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Forwarded-Host %[req.hdr(Host)]
    # Dispatch to backend pool
    default_backend wp_multisite_pool

2.8 Self-Hosted Nginx Load Balancer Optimized Full Config (Updated Multisite Header Lock)

# Define backend WordPress server pool
upstream wp_saas_cluster {
    server 10.0.2.10:80 weight=2 max_fails=2 fail_timeout=30s; # Original Old WP Server
    server 10.0.2.11:80 weight=3 max_fails=2 fail_timeout=30s; # New Added WP Server
    balance least_conn; # Use least connection algorithm instead of default round robin
    keepalive 64; # Persist PHP connection to reduce handshake overhead
}

# HTTP to HTTPS redirect
server {
    listen 80;
    server_name *.domain.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block
server {
    listen 443 ssl http2;
    server_name *.domain.com;
    
    # Wildcard SSL certificate
    ssl_certificate /path/to/wildcard_domain_com.pem;
    ssl_certificate_key /path/to/wildcard_domain_com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    
    location / {
        proxy_pass http://wp_saas_cluster;
        # Critical locked header rules, DO NOT EDIT
        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;
        proxy_set_header X-Forwarded-Host $host;
        # WordPress timeout tuning for backend wp-admin operation
        proxy_connect_timeout 30s;
        proxy_send_timeout 90s;
        proxy_read_timeout 90s;
        proxy_http_version 1.1;
        proxy_set_connection_header keep-alive;
    }
}

2.9 Fix SSL Termination Infinite Redirect Loop (Universal WP Config for All LB)

When SSL terminated on load balancer, backend WP nodes receive plain HTTP requests, triggering WordPress built-in HTTPS forced redirect loop. Add fixed code to every server wp-config.php, compatible with Cloudflare/AWS ALB/Nginx/HAProxy all LB types:

// Universal HTTPS recognition for all load balancer proxy
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
    $_SERVER['SERVER_PORT'] = '443';
}
// Cloudflare dedicated supplement rule (add if using Cloudflare LB)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $cf_visitor = json_decode($_SERVER['HTTP_CF_VISITOR'],true);
    if($cf_visitor['scheme'] === 'https'){
        $_SERVER['HTTPS'] = 'on';
    }
}

2.10 Load Balancer Security Reinforcement for WP SaaS

  1. Enable LB built-in WAF rule: Block WordPress common attack paths (/wp-admin brute force, xmlrpc.php abuse)
  2. Limit request rate: Single IP maximum 120 requests per minute, mitigate plugin scanning flood
  3. Disable unnecessary HTTP method: Only allow GET/POST/HEAD, block PUT/DELETE
  4. Add custom response header: X-Frame-Options, X-Content-Type-Options to prevent subsite hijacking

Part 2 Summary Rules

  • Keep *.domain.com wildcard DNS unchanged, no tenant domain modification needed
  • Forbid modifying original Host header, core prerequisite for WP Multisite subsite matching
  • Least Connections algorithm is exclusive recommended scheduling rule for WP SaaS cluster
  • Unified LB-layer SSL termination + universal wp-config HTTPS fix is mandatory for all nodes

Leave a Reply

Your email address will not be published. Required fields are marked *