Installer le serveur web Caddy avec HTTPS automatique

Caddy est un serveur web qui obtient et renouvelle les certificats TLS par défaut. Pour un petit VPS qui héberge un ou deux domaines, cela élimine toute une classe de minuteries Certbot et de fichiers d’extraits Nginx. Le langage de configuration (Caddyfile) est court. Reverse proxy, gzip et HTTP/2 sont des fonctions normales, pas un week-end de modules supplémentaires.

Nginx reste le bon choix pour certaines équipes : vous avez déjà des configs éprouvées, ou vous avez besoin d’un module très spécifique. Ce guide vise l’autre cas fréquent — vous voulez un HTTPS qui marche sur un VPS Hiddence tout neuf sans mémoriser des extraits include. Nous installerons Caddy depuis le dépôt apt officiel, expliquerons comment il parle à Let's Encrypt, servirons un site statique, proxierons une application locale, hébergerons plusieurs domaines, regarderons les journaux, et couvrirons les bagarres habituelles pour le port 80 avec Apache ou un vieux Nginx.

Quand Caddy convient bien

Le HTTPS automatique est le titre, mais le gain quotidien, ce sont moins de pièces mobiles. Caddy écoute sur 80 et 443, redirige HTTP vers HTTPS, et stocke les certificats dans son répertoire de données. Il vous faut toujours un domaine qui pointe vers le VPS. Il ne faut toujours pas casser ACME (pare-feu 80/tcp, aucun autre processus qui vole :80). Les certificats joker nécessitent un module fournisseur DNS — c’est un chemin plus long qu’un certificat pour un seul hôte.

• Redirection HTTP→HTTPS automatique et renouvellement des certificats
• Caddyfile lisible au lieu de longs blocs server
• Reverse proxy capable pour Node, Python, PHP-FPM via une config supplémentaire, ou des backends Docker
• HTTP/2 et paramètres TLS modernes sans tableur de chiffrements
• Unité systemd du paquet officiel

Prérequis

Un domaine doit résoudre vers ce VPS avant que Caddy puisse prouver ACME HTTP-01. Si le DNS se propage encore, Caddy échouera l’émission et réessaiera ; cela ressemble à « Caddy est cassé » alors que ce n’est que le DNS. Arrêtez Apache ou Nginx d’abord s’ils possèdent 80/443.

• Ubuntu 22.04 ou 24.04
• Un enregistrement A de domaine vers l’IP du VPS (et AAAA si vous utilisez IPv6)
• Ports 80 et 443 libres et autorisés dans le pare-feu
• Root ou sudo

Étape 1 : Installer Caddy depuis le dépôt officiel

N’installez pas un vieux Caddy au hasard depuis Ubuntu Universe si vous voulez un comportement TLS et ACME actuel. Le projet Caddy documente une source apt. Après l’installation, l’utilisateur caddy existe et le service est activé.

ssh root@YOUR_VPS_IP
apt update && apt -y install debian-keyring debian-archive-keyring apt-transport-https curl gpg

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 -y install caddy

caddy version
systemctl status caddy --no-pager

Étape 2 : Première Caddyfile — site statique

La Caddyfile par défaut est /etc/caddy/Caddyfile. Remplacez-la par votre domaine. Caddy essaiera d’obtenir un certificat dès le chargement de la config si le nom d’hôte n’est pas localhost. Placez les fichiers du site dans un répertoire lisible par l’utilisateur caddy (souvent des droits façon www-data, mais le paquet utilise l’utilisateur caddy).

mkdir -p /var/www/example
echo '<h1>It works</h1>' > /var/www/example/index.html
chown -R caddy:caddy /var/www/example

cat >/etc/caddy/Caddyfile <<'EOF'
example.com {
    root * /var/www/example
    file_server
    encode gzip
}
EOF

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

# Watch issuance:
journalctl -u caddy -f

Étape 3 : Reverse proxy d’une application locale

Si Gunicorn, Node ou Docker écoute sur 127.0.0.1:8000, Caddy doit être le seul processus public. La directive reverse_proxy transmet Host et les en-têtes X-Forwarded-* de façon raisonnable pour la plupart des applications. Si l’application génère des URL HTTP absolues, réglez les indicateurs de proxy de confiance / HTTPS dans l’application (Django SECURE_PROXY_SSL_HEADER, Express trust proxy, etc.).

app.example.com {
    encode gzip
    reverse_proxy 127.0.0.1:8000
}

# Several hosts in one file are normal:
# blog.example.com {
#     root * /var/www/blog
#     file_server
# }

Étape 4 : Pare-feu et systemd

Autorisez 80 et 443. L’unité de Caddy est caddy.service ; un reload suffit après des modifications de Caddyfile si le processus est sain. Si vous changez des variables d’environnement pour un plugin DNS, un redémarrage complet est plus clair. Les certificats vivent par défaut sous /var/lib/caddy/.local/share/caddy/ — incluez ce chemin dans les sauvegardes si les limites de débit lors d’une réinstallation vous importent.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

systemctl enable --now caddy
systemctl reload caddy

# Backup cert storage (path may vary slightly by version):
ls -la /var/lib/caddy/

Étape 5 : Journaux, compression et en-têtes

Les journaux d’accès aident quand un robot martèle un chemin ou quand vous déboguez des 404. Vous pouvez journaliser par site. Ajoutez des en-têtes de sécurité si vous hébergez une application navigateur ; ne copiez pas un énorme paquet d’en-têtes sans comprendre HSTS (une fois un max-age long défini, les navigateurs s’en souviennent).

example.com {
    root * /var/www/example
    file_server
    encode gzip
    log {
        output file /var/log/caddy/example.log
    }
    header {
        X-Content-Type-Options nosniff
        Referrer-Policy no-referrer-when-downgrade
        -Server
    }
}

mkdir -p /var/log/caddy
chown caddy:caddy /var/log/caddy
systemctl reload caddy

Étape 6 : PHP et autres extras

Caddy peut parler à PHP-FPM avec la directive php_fastcgi. Cela suffit pour beaucoup d’hébergements WordPress ou Laravel, mais il vous faut encore php-fpm installé et un chemin de socket qui correspond. Si vous avez déjà une config PHP Nginx parfaite, migrer en une soirée est facultatif — Caddy brille davantage en reverse proxy + statique + TLS automatique.

example.com {
    root * /var/www/example
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

# Confirm FPM is running:
systemctl status php8.3-fpm

Migrer depuis Nginx sans surprises de coupure

Arrêtez Nginx avant de démarrer Caddy, sinon ils se battront pour 80/443. Baissez le TTL DNS la veille si vous changez aussi d’IP. Testez avec curl --resolve pour frapper le nouveau VPS avant de basculer l’enregistrement A. Gardez les configs Nginx dans git une semaine au cas où il faudrait revenir en arrière.

• systemctl stop nginx && systemctl disable nginx
• Installer Caddy, valider la Caddyfile, démarrer Caddy
• curl -I --resolve example.com:443:NEW_IP https://example.com
• Ne changer le DNS qu’ensuite si l’IP est nouvelle
• La réémission est automatique ; ne lancez pas aussi Certbot contre le même nom d’hôte

Dépannage

Les échecs ACME sont presque toujours le DNS, le pare-feu, ou un autre service sur le port 80. Les lignes de journal Caddy mentionnent tls.obtain. Si le site marche en HTTP mais pas en HTTPS, l’émission n’a jamais abouti. Si vous voyez trop de certificats, vous avez touché les limites de débit Let's Encrypt — utilisez l’autorité de certification de staging pour tester, pas la production.

• validate échoue : syntaxe Caddyfile, accolade manquante
• permission denied sur root : chown caddy pour le répertoire du site
• bind: address already in use — ss -tulpn | grep -E ':80|:443'
• délai d’attente du certificat : dig +short le domaine depuis le VPS, ufw allow 80
• 502 reverse_proxy : backend arrêté, ou vous avez proxifié vers localhost depuis un réseau de conteneurs de façon incorrecte

Notes de sécurité

Les paramètres TLS par défaut de Caddy sont conservateurs. Votre travail, c’est la sécurité applicative et SSH. N’activez pas l’API d’administration Caddy sur une interface publique. Le point d’administration par défaut est local ; laissez-le ainsi. Si vous utilisez une Caddyfile trouvée sur Internet, lisez chaque matcher — un extrait qui reverse_proxie /* vers une IP interne peut devenir un proxy ouvert.

• N’exposez pas l’API d’administration
• Gardez le paquet à jour
• HSTS seulement après être sûr que HTTPS marche pour tous les noms d’hôte
• Séparez les noms d’hôte de test et de production pour protéger les limites de débit ACME

Conseils

• caddy fmt --overwrite /etc/caddy/Caddyfile garde le fichier lisible
• Utilisez des extraits import quand vous avez beaucoup de sites similaires
• Pour Docker, l’image caddy:alpine avec une Caddyfile montée est courante
• Les certificats joker nécessitent un module DNS et un jeton d’API — protégez ce jeton
• Lisez journalctl -u caddy avant de réécrire tout le fichier

Caddy sur un VPS, c’est : paquet officiel, une Caddyfile courte, ports 80/443 ouverts, DNS déjà pointé vers le serveur, et reload systemd après les modifications. Utilisez-le comme serveur de fichiers statiques ou comme reverse proxy devant Gunicorn, Node ou Docker. Le HTTPS automatique fonctionne quand ACME peut répondre sur le port 80 ; si l’émission échoue, corrigez DNS et conflits de ports avant d’accuser Caddy. Sauvegardez /var/lib/caddy si vous réinstallez souvent.