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

Objetivos

Transformar el Pi 2 en un servidor web doméstico. Sus 1 GB de RAM y su quad-core le confieren un margen real para un servicio ligero, pero su Ethernet 100 Mbps compartido con el bus USB limita el caudal de red: elegir un servidor sobrio (nginx o Caddy, no Apache+PHP pesado) es estratégico. Instalarás el servidor, un sitio estático, un servicio systemd, y medirás el caudal real.

Materiales

• Raspberry Pi 2 Model B bajo Raspberry Pi OS de 32 bits, alimentado de forma estable
• Cable Ethernet (el WiFi requeriría un dongle)
• Acceso SSH (ver el tutorial SSH/red, sobre todo para fijar la MAC en v1.2)

Código completo

# 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

Verificación esperada

curl -I http://localhost devuelve HTTP/1.1 200 OK; desde otra máquina, http://IP-du-Pi muestra la página. nginx consume unas decenas de MB, dejando disponibles 3/4 de los 1 GB. iperf3 se acerca a 90 Mbit/s: más allá, no es el servidor sino el puerto Ethernet de 100 Mbps (bus USB compartido) el que limita.

Errores frecuentes

• Confundir techo de red y servidor lento: a 100 Mbps compartidos con los puertos USB, una descarga grande lo satura todo; dimensiona los usos en consecuencia.
• Olvidar un lease DHCP estable: en una placa v1.2 con MAC aleatoria, la IP del servidor cambia sola: fija la MAC primero.
• Apilar PHP, MySQL y WordPress sobre 1 GB: posible pero frágil; para un servicio ligero, estático o reverse-proxy primero.
• Certificado HTTPS en fallo detrás de una box: el DNS debe señalar realmente al servidor; en local, un reverse proxy con certificado interno es más simple.
• Reinicios en serie bajo carga: señal de una alimentación de 5 V insuficiente (subtensión), no de un bug de nginx.