Caddy Web Server for Tor Hidden Services - Simpler Configuration

Caddy's Caddyfile syntax is significantly more concise than nginx's configuration format. For hidden service operators, this means faster setup and easier maintenance. A complete Caddy configuration for a hidden service reverse proxy is typically 5 to 10 lines versus 20 to 30 for the equivalent nginx configuration. Fewer configuration lines means fewer opportunities for security-relevant misconfiguration.

Caddy has HTTP/2 enabled by default without additional directives. For nginx, HTTP/2 requires explicit protocol specification in the listen directive. This difference might seem minor but is meaningful for operators who are unfamiliar with the quirks of each server's defaults.

Caddy's automatic TLS is not useful for hidden services (TLS is handled by Tor's encryption layer), but the rest of Caddy's modern defaults are appropriate: graceful reload without request dropping, structured JSON logging, and built-in metrics endpoint for monitoring.

Install Caddy from the official repository for a maintained package that receives security updates:

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

Verify the installation: caddy version. Create the web root directory and a test page: mkdir -p /var/www/onion && echo "Hidden service working" > /var/www/onion/index.html. Caddy runs as the caddy user by default; the document root needs appropriate permissions: chown -R caddy:caddy /var/www/onion

Configure Caddy to listen on the localhost interface only and serve the hidden service content. Create /etc/caddy/Caddyfile:

:8080 {
    bind 127.0.0.1
    root * /var/www/onion
    file_server

    header {
        -Server
        -X-Powered-By
        X-Robots-Tag "noindex, nofollow"
    }

    log {
        output file /var/log/caddy/access.log
        format json
    }

    encode gzip
}

The bind 127.0.0.1 directive prevents Caddy from listening on public interfaces, ensuring the web server is accessible only through the Tor hidden service. Remove the -Server header to avoid leaking server version information. The encode gzip directive enables gzip compression for all eligible content types.

For a reverse proxy configuration (when Caddy fronts an application server): replace the root and file_server directives with: reverse_proxy 127.0.0.1:3000. This forwards all hidden service traffic to an application server on port 3000 running on localhost.

Apply header security policies to reduce information leakage from Caddy responses. Add these header directives to the Caddyfile:

header {
    -Server
    -X-Powered-By
    -X-Caddy-Hint
    X-Robots-Tag "noindex, nofollow"
    X-Frame-Options DENY
    X-Content-Type-Options nosniff
    Referrer-Policy no-referrer
}

The X-Frame-Options DENY prevents your hidden service from being embedded in iframes on other pages, which can be used in clickjacking attacks. X-Content-Type-Options nosniff prevents browsers from MIME-sniffing responses away from their declared content type. Referrer-Policy no-referrer prevents your server from receiving referrer headers when users click links to external sites from your hidden service, protecting navigation patterns.

Combine Caddy with iptables rules that block outbound clearnet traffic from all processes except the tor user, as described in the nginx hidden service setup guide. Caddy has the same clearnet leakage risk as nginx when hosting applications that make external requests.