Introduction to High-Availability Infrastructure

In modern enterprise architecture, the reverse proxy is a critical gateway. It handles SSL/TLS termination, manages traffic distribution, and shields internal microservices from direct exposure. However, if your reverse proxy goes down, your entire digital ecosystem goes dark. Relying on a single reverse proxy instance introduces a catastrophic Single Point of Failure (SPOF).

To mitigate this risk, infrastructure engineers must design a multi-layered, self-healing routing tier. This technical guide provides a comprehensive blueprint for building a private, ultra-resilient reverse proxy cluster. By combining the modern, automated features of Caddy Server, the reliable virtual mac routing of Keepalived, and the advanced network topology of IP Anycast, you can achieve unprecedented levels of fault tolerance and low-latency performance.

The Architecture Blueprint: Roles and Responsibilities

To understand how these technologies intertwine, we must examine the specific layer each component occupies within the Open Systems Interconnection (OSI) model and network topology:

Caddy Server (Layer 7): Acts as the application-level gateway, managing HTTP/HTTPS requests, load balancing upstream servers, and automating SSL certificate provisioning.
Keepalived (Layer 4): Utilizes the Virtual Router Redundancy Protocol (VRRP) to provide active-passive failover between local proxy nodes using a shared Virtual IP (VIP).
IP Anycast (Layer 3): Advertises a single IP address from multiple geographical or physical locations using routing protocols like BGP (Border Gateway Protocol) or OSPF (Open Shortest Path First), distributing traffic to the nearest healthy cluster.

Step 1: Setting Up the Caddy Server Nodes

Caddy has quickly surpassed traditional web servers due to its native performance and zero-configuration TLS management. For our cluster, we will deploy at least two identical Caddy nodes within a local area network segment.

Installing Caddy

Begin by installing Caddy on your Linux distributions (e.g., Ubuntu/Debian):

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf '[https://dl.cloudsmith.io/public/caddy/stable/gpg.key](https://dl.cloudsmith.io/public/caddy/stable/gpg.key)' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf '[https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt](https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt)' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Configuring a Shared Storage for TLS Certificates

Because multiple Caddy instances will sit behind a shared IP configuration, they must share a TLS storage backend to avoid hitting Let's Encrypt rate limits. This can be achieved using a shared network filesystem (NFS) or a database plugin like Redis.

Enterprise Note: Using a centralized storage backend ensures that whichever Caddy node answers the initial ACME challenge, all other nodes have immediate access to the validated certificates.

An example of the Caddyfile configuration utilizing a shared storage mount:

{
    storage file_system /mnt/shared_caddy_certs
}

api.internal.enterprise.com {
    reverse_proxy 10.0.10.50:8080 10.0.10.51:8080 {
        lb_policy round_robin
        health_uri /healthz
        health_interval 10s
    }
}

Step 2: Implementing Layer 4 High Availability with Keepalived

With Caddy operational on multiple nodes (e.g., Node A: 10.0.1.11 and Node B: 10.0.1.12), we introduce Keepalived to bind them to a single Virtual IP (VIP), such as 10.0.1.10.

Configuring the Master Node (Node A)

Edit the /etc/keepalived/keepalived.conf file on the primary node:

vrrp_script check_caddy {
    script "pidof caddy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass Secr3tPass!
    }
    virtual_ipaddress {
        10.0.1.10/24
    }
    track_script {
        check_caddy
    }
}

Configuring the Backup Node (Node B)

On the secondary node, use an identical setup but lower the priority and shift the state to BACKUP:

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    ...
}

If Node A suffers a hardware failure or the Caddy daemon stops executing, Keepalived dynamically migrates the MAC address association of the VIP (10.0.1.10) to Node B within milliseconds, maintaining continuous uptime without manual intervention.

Step 3: Scaling Globally with IP Anycast (Layer 3)

While Keepalived provides exceptional local redundancy, it cannot scale across routed network boundaries or multiple data centers. This is where IP Anycast becomes imperative.

In an Anycast topology, multiple distinct Keepalived/Caddy clusters across different physical locations advertise the exact same IP prefix to your corporate network core routers or upstream Internet Service Providers via OSPF or BGP.

The Routing Mechanism

Routers use the Equal-Cost Multi-Path (ECMP) routing metric or shortest path algorithms to send requests to the nearest available cluster. If a localized data center undergoes a complete network blackout, the upstream core routers immediately detect the loss of the BGP/OSPF advertisement from that specific site. Traffic is seamlessly rerouted to the next closest data center hosting the identical Anycast IP address.

To implement this, network engineers deploy a routing daemon such as FRRouting (FRR) alongside Keepalived on the proxy edge nodes, allowing the servers to communicate health status directly with enterprise switches.

Architectural Benefits and Considerations

Integrating these three technologies offers distinct competitive advantages for enterprise systems:

Ultimate Multi-Region Redundancy: Fault isolation spans from local application crashes (handled by Keepalived) up to entire data center disasters (handled by Anycast).
Seamless Operations: Caddy's native performance lowers compute overhead compared to traditional proxies, while automatic cert renewals remove manual maintenance burdens.
Minimized Latency: Users are automatically directed to the physically closest proxy node, optimizing TCP handshake and TLS negotiation times.

Conclusion

Constructing a private reverse proxy cluster using Caddy, Keepalived, and IP Anycast creates an infrastructure tier that is both resilient to failure and optimized for scale. By strategically addressing vulnerabilities at the network, transport, and application layers, you transition your business infrastructure from a state of fragile reactivity to true, self-healing continuous availability.

Building an Ultra-Resilient Private Reverse Proxy Cluster: Combining Caddy Server, Keepalived, and IP Anycast