🛠 Serveur web léger : nginx ou Caddy sur le Pi 2

Objectifs

Transformer le Pi 2 en serveur web domestique. Ses 1 GB de RAM et son quad-core lui confèrent une vraie marge pour un service léger, mais son Ethernet 100 Mbps partagé avec le bus USB plafonne le débit réseau : le choix d'un serveur sobre (nginx ou Caddy, pas Apache+PHP lourd) est stratégique. Tu installeras le serveur, un site statique, un service systemd, et tu mesureras le débit réel.

Matériel

• Raspberry Pi 2 Model B sous Raspberry Pi OS 32 bits, alimenté de façon stable
• Câble Ethernet (le WiFi nécessiterait un dongle)
• Accès SSH (voir le tuto SSH/réseau, surtout pour épingler la MAC sur v1.2)

Code complet

# Option A : nginx (leger et classique)
sudo apt install nginx
sudo bash -c 'echo "<h1>Bonjour depuis le Pi 2</h1>" > /var/www/html/index.html'
sudo systemctl enable --now nginx

# Option B : Caddy (HTTPS automatique, binaire unique)
curl -1 https://r.caddy.sh | sudo bash -s
sudo bash -c 'echo "Pi2.example.com { root * /srv/pi2 }" > /etc/caddy/Caddyfile'
sudo systemctl enable --now caddy

# Vérifications locales
curl -I http://localhost
systemctl status nginx | head -n 5
free -h          # 1 GB de RAM : garder de la marge

# Débit réseau réel (attendu ~90 Mbit/s max)
sudo apt install iperf3 && iperf3 -c 192.168.1.10

Vérification attendue

curl -I http://localhost renvoie HTTP/1.1 200 OK ; depuis un autre poste, http://IP-du-Pi affiche la page. nginx consomme quelques dizaines de Mo, laissant les 3/4 des 1 GB disponibles. iperf3 approche 90 Mbit/s : au-delà, ce n'est pas le serveur mais le port Ethernet 100 Mbps (bus USB partagé) qui limite.

Erreurs fréquentes

• Confondre plafond réseau et serveur lent : à 100 Mbps partagés avec les ports USB, un gros téléchargement sature tout ; dimensionne les usages en conséquence.
• Oublier le bail DHCP stable : sur une carte v1.2 à MAC aléatoire, l'IP du serveur change toute seule — épingler la MAC d'abord.
• Empiler PHP, MySQL et WordPress sur 1 GB : possible mais fragile ; pour un service léger, statique ou reverse-proxy d'abord.
• Certificat HTTPS en échec derrière une box : le DNS doit réellement pointer vers le serveur ; en local, un reverse proxy avec certificat interne est plus simple.
• Redémarrages en série sous charge : signe d'une alimentation 5 V insuffisante (sous-tension), pas d'un bug de nginx.