RTFM · Networking

HAProxy for webDragon

HAProxy can be the public HTTP/HTTPS edge while webDragon stays on a private server network. This is useful when several services share one firewall boundary or when you want one place to make TLS and client-address decisions.

Decide whether HAProxy or webDragon owns HTTPS

Choose one TLS owner before writing configuration. HAProxy termination means HAProxy holds the certificate and sends HTTP to webDragon. TCP pass-through means webDragon holds the certificate and HAProxy forwards encrypted bytes. Termination is often convenient for one central edge; pass-through is useful when webDragon's existing certificate lifecycle must remain the TLS authority.

Two valid web designs
Design	HAProxy mode	webDragon receives
HAProxy terminates TLS	HTTP	Plain HTTP plus trusted forwarding headers.
webDragon terminates TLS	TCP	The original encrypted TLS connection.

Never configure HTTP directives such as option forwardfor in a TCP pass-through frontend and expect them to work. HAProxy cannot read HTTP headers inside encrypted traffic it has not terminated.

HTTPS termination example

This example puts a combined certificate and private key at the HAProxy edge and sends HTTP to webDragon at a private address. The webDragon backend must trust only the HAProxy address when it uses X-Forwarded-For for logs, rate limits, or access decisions.

webDragon behind terminating HAProxy

# /etc/haproxy/haproxy.cfg
global
    log /dev/log local0

defaults
    mode http
    log global
    option httplog
    timeout connect 5s
    timeout client  1m
    timeout server  1m

frontend http_in
    bind :80
    http-request redirect scheme https code 301 unless { ssl_fc }

frontend https_in
    bind :443 ssl crt /etc/haproxy/certs/www.example.test.pem
    http-request set-header X-Forwarded-Proto https
    option forwardfor
    default_backend webdragon

backend webdragon
    server webdragon 192.0.2.30:80 check

Validate, then test

# Validate before changing the live listener.
haproxy -c -f /etc/haproxy/haproxy.cfg
rc-service haproxy restart

# Confirm edge and backend ownership.
ss -lntp '( sport = :80 or sport = :443 )'
curl -I http://192.0.2.30/
curl -vk --resolve www.example.test:443:203.0.113.10 https://www.example.test/

TLS pass-through example

Use TCP pass-through when webDragon must own the TLS certificate. The HAProxy edge cannot redirect HTTP to HTTPS or inject X-Forwarded-For in this arrangement because it never decrypts the connection. It can still health-check a TCP connection and enforce network-level policy.

webDragon owns TLS

defaults
    mode tcp
    timeout connect 5s
    timeout client  1m
    timeout server  1m

frontend https_passthrough
    bind :443
    default_backend webdragon_tls

backend webdragon_tls
    server webdragon 192.0.2.30:443 check

Failure paths and safe recovery

Browser receives a 503: HAProxy is listening but cannot use the backend. Test the private backend URL from the HAProxy host and inspect its firewall and route.
Application logs show the proxy address: that is expected until the application is configured to trust the proxy's forwarding headers. Never trust client-supplied headers from arbitrary sources.
Certificate renews but visitors still see an old certificate: identify which machine owns TLS, renew there, validate there, and reload only that service after a successful check.
HTTP works internally but public HTTPS fails: test the router/provider delivery, HAProxy 443 listener, edge firewall, certificate path, and backend in that order.