Serveur Hetzner : administrer, sécuriser et maintenir une vraie production Linux

Contexte serveur

Le serveur est une machine Linux louee chez Hetzner et administree en ligne de commande, principalement via SSH. Il heberge plusieurs projets : sites statiques, applications Node.js, backend Express, WordPress WooCommerce et sites publics avec leurs propres domaines ou sous-domaines.

La logique est pragmatique : chaque projet garde sa racine dans /var/www, Nginx sert les fichiers statiques ou redirige vers les services applicatifs, et les certificats HTTPS sont geres par Certbot et Let's Encrypt.

Nginx et reverse proxy

Nginx sert de point d'entree central. Il gere les noms de domaine, les redirections HTTPS, les certificats, les caches d'assets et les reverse proxies vers les applications Node. Pour WordPress, il transmet les requetes PHP a PHP-FPM.

Cette organisation permet d'heberger des stacks differentes sur le meme serveur : React statique, Express derriere PM2, WordPress avec PHP-FPM, MariaDB, et des sous-domaines dedies comme lxcdm.loading-y.com.

Cybersécurité

La securite est traitee a plusieurs niveaux. UFW limite l'exposition reseau, Fail2ban surveille les tentatives abusives, SSH reste le canal d'administration, et Nginx ajoute des headers defensifs : X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, CSP et HSTS.

Le serveur utilise aussi des certificats TLS Let's Encrypt, avec renouvellement via Certbot. Le but n'est pas de rendre l'infrastructure spectaculaire, mais de construire une base saine : moins de surface d'attaque, des accès contrôlés, et des navigateurs mieux protégés.

Ameliorations SEO

Le SEO technique depend aussi du serveur. La configuration met en avant HTTPS, cache long pour les assets versionnes, gzip, racines propres par projet, fichiers statiques servis directement, et reverse proxy stable pour les backends.

Ces choix aident les sites heberges a charger plus vite et a rester fiables : moins d'erreurs serveur, moins de latence sur les ressources statiques, des certificats valides, et une meilleure experience mobile. Le SEO n'est donc pas seulement du contenu : c'est aussi de l'exploitation propre.

Exemples de configuration

Ces extraits resumés montrent le type de configuration utilisee : headers de securite, cache statique et proxy applicatif.

Headers de securite

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; frame-ancestors 'none';" always;

Cache statique

location ~* \.(jpg|jpeg|png|gif|ico|css|js|webp)$ {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable" always;
}

Reverse proxy Node.js

location /api/ {
  proxy_pass http://localhost:5000;
}

Ce que cette partie montre

• Administration Linux en ligne de commande sur serveur distant.
• Configuration Nginx multi-sites avec HTTPS et reverse proxy.
• Mise en place de briques de cybersécurité : UFW, Fail2ban, headers, CSP, HSTS.
• Exploitation de stacks differentes : Node.js, WordPress, PHP-FPM, MariaDB, sites statiques.
• Compréhension du lien entre performance serveur, sécurité et SEO technique.