Nginx

Prérequis : vous devez avoir à minima un VPS et la liberté d’installer ce que vous voulez (ce qui n’est pas le cas de O2switch). hostinger propose un VPS de ce calibre, DigitalOcean propose des instances à la demande.

Installer Nginx et PHP-FPM

# Mettre à jour le système
sudo apt update && sudo apt upgrade -y

# Installer Nginx
sudo apt install nginx -y

# Installer PHP-FPM et extensions nécessaires pour WordPress
sudo apt install php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-xmlrpc php-soap php-intl -y

Créer un dossier pour le cache Nginx

sudo mkdir -p /var/cache/nginx
sudo chown -R www-data:www-data /var/cache/nginx
sudo chmod -R 700 /var/cache/nginx

Configurer Nginx pour le cache

Éditer le fichier de site WordPress. Supposons que le site est dans /etc/nginx/sites-available/wordpress.conf.

server {
    listen 80;
    server_name ton-domaine.com www.ton-domaine.com;

    root /var/www/wordpress;
    index index.php index.html index.htm;

    # Cache configuration
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m use_temp_path=off;

    # Log files
    access_log /var/log/nginx/wordpress.access.log;
    error_log /var/log/nginx/wordpress.error.log;

    # Main location
    location / {
        try_files $uri $uri/ /index.php?$args;

        # Enable caching
        proxy_cache WORDPRESS;
        proxy_cache_valid 200 60m;  # Cache 200 responses 60 minutes
        proxy_cache_valid 301 302 10m;  # Cache redirects 10 minutes
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    }

    # PHP-FPM handling
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock; # Adapte selon ta version de PHP
    }

    # Disable caching for admin and login
    location ~* /(wp-admin|wp-login\.php) {
        proxy_cache off;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    # Static files caching
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|webp)$ {
        expires 30d;
        access_log off;
    }
}

Ici, proxy_cache_path définit le cache, sa taille (100m) et l’endroit où il est stocké. On active le cache pour les pages publiques, et on le désactive pour les pages d’administration ou login.

Tester la configuration Nginx

sudo nginx -t
sudo systemctl reload nginx

Activer le log de cache

tail -f /var/log/nginx/wordpress.access.log

2. On devrait voir des en-têtes comme :

• HIT → la page vient du cache.
• MISS → la page vient du serveur PHP (premier chargement ou cache expiré).

Pour ajouter un en-tête qui montre si une page est en cache :

proxy_set_header X-Cache $upstream_cache_status;

Placez-le dans la section location /.

Conseils pour WordPress

• Installe un plugin de cache léger (comme LiteSpeed Cache ou WP Super Cache) si tu veux contrôler le purging automatique, sinon Nginx ne sait pas quand le contenu change.
• Les images et fichiers statiques (CSS/JS) peuvent être directement servis avec expires pour ne pas passer par PHP.
• Configure un cron ou purge Nginx pour vider le cache si tu changes beaucoup de contenu.

Version sans plugin Cache côté WordPress

Il n’est pas obligé d’avoir un WP CACHE pour dire à Nginx quand c’est invalidé. La version sans WP CACHE est disponible sur cette page.

1. Nginx en mode cache simple (proxy_cache)

• Nginx cache les réponses HTTP qu’il reçoit de ton backend (PHP-FPM pour WordPress).
• Il ne connaît pas la logique métier de WordPress : il ne sait pas si un post a été édité, si un commentaire est ajouté, etc.
• Donc, par défaut, Nginx utilise un TTL (proxy_cache_valid 200 60m) pour déterminer combien de temps garder la page.
• Après expiration, il refait une requête à PHP-FPM.

💡 En résumé : Nginx “voit” seulement les codes HTTP et les headers, pas l’état de WordPress.

2. Comment invalider intelligemment le cache ?

Pour qu’un cache Nginx soit “intelligent” et se purge automatiquement quand WordPress change quelque chose :

1. Plugins WordPress dédiés :
   • LiteSpeed Cache ou WP Rocket peuvent envoyer des commandes de purge au serveur Nginx via HTTP ou socket quand un post/page est mis à jour.
   • Le plugin sait quand une page devient “obsolète” et demande à Nginx de la supprimer du cache.
2. Purge manuel via Nginx :
   • On peut créer une URL spéciale comme /purge/some-path que WordPress appelle via un hook save_post.
   • Cette URL est configurée pour supprimer les fichiers du cache correspondants.
3. Cache-Control et ETag :
   • Si WordPress envoie les headers Cache-Control et ETag, Nginx peut les respecter pour savoir quand revalider une page.
   • Cela permet un cache plus dynamique sans toucher au filesystem.

En pratique : Nginx est très rapide pour servir le cache, mais il a besoin d’un signal externe pour savoir quand le contenu est obsolète. WordPress côté PHP ou un plugin fournit ce signal.

Pull de l’image Debian

Vous qui avez l’habitude de fonctionner avec Apache, vous allez voir une alternative intéressante avec Nginx, qui peut à la différence de Apache jouer plusieurs rôles, reverse proxy, load balancer, mise en cache.

Nous allons partir d’une image docker debian de base officielle

docker pull debian
docker run -it debian

Nous aurions pu faire un dockerfile pour installer les packages nécessaire mais nous allons essayer de faire une configuration minimaliste, sans systemd ni supervisor.

Installation des packages

nous aurons besoin de curl nginx vim php-fpm etc (on découvrira au fur et à mesure)

apt update
apt install nginx php-fpm curl vim

configuration du fichier vhost de phpsite

Ce fichier est à placer dans le répertoire /etc/nginx/sites-available/

server {
    listen 80;
    server_name phpsite;

    root /var/www/phpsite;
    index index.php index.html;

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
    }
}

la ligne include fastcgi_params est important, car permet à Nginx d’exécuter le PHP, sinon un curl vous renvoit le texte du code.

La ligne fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Vous testez ce script avec la commande nginx -t qui vérifiera s’il n’y a pas d’erreur.

Pour rendre ce site actif il faut créer un lien symbolic dans le répertoire /etc/nginx/sites-enabled/ qui pointe vers ce fichiers de configuration de vhsot qu’on appelera phpsite.conf

sudo ln -s /etc/nginx/sites-available/phpsite.conf /etc/nginx/sites-enabled/phpsite.conf

Le fichier DNS local /etc/hosts

Il faut ajouter le site phpsite dans /etc/hosts

127.0.0.1  localhost
127.0.0.1   phpsite

Ainsi le navigateur va résoudre l’adresse phpsite en pointant vers 127.0.0.1 qui est en fait votre machine.

Le fichier php info.php

cd /var/www/phpsite
touch info.php
nano info.php

<?php 
echo "Hello";
?>

Vous devez démarrer php-fpm pour prendre en charge l’exécution du php et démarrer nginx aussi

Démarrage des services pour accéder à un site en php

Démarrage de php-fpm

le fait qu’on n’utilise pas systemd ni supervisor nécessite qu’on démarre à la main php-fpm et utiliser le socket TCP et non le socket Unix

 /usr/sbin/php-fpm8.2 -F

le -F fait démarrer php-fpm en foreground.

Démarrage de Nginx

nginx -g "daemon off;"

Cette commande évite de démarrer nginx en tâche de fond, comme ça on a les logs si jamais il y a une erreur. Le flag -g indique qu’on passe une directive globale au lancement, ça permet d’overrider une directive du fichier de configuration nginx.conf.

Erreurs et problèmes possibles

Si vous essayez d’atteindre une page php avec curl

curl http://phpsite/info.php

// n'oubliez pas d'ajouter dans le fichier /etc/hosts/ le vhost phpsite
vim /etc/hosts

// contenu du fichier

et que vous avez un erreur 502 Bad Gateway, c’est que php-fpm écoute sur un socket Unix et que Nginx est paramétré sur un socket TCP. Pour savoir quel type de configuration a php-fpm:

// commande pour savoir quel type de socket php-fpm utilise
grep -E "^listen" /etc/php/8.2/fpm/pool.d/www.conf

//Dans le fichier /etc/php/8.2/fpm/pool.d/www.conf, remplacez le socket Unix par le socket TCP.
listen = /run/php/php8.2-fpm.sock  # socket Unix
listen = 127.0.0.1:9000    # socket TCP

Dans notre cas (fonctionnement sans systemd et supervisor, on va choisir les socket TCP.)

On va donc changer la configuration de php-fpm

vim /etc/php/8.2/fpm/pool.d/www.conf 
on cherche la ligne où on a 
listen = /run/php/php8.2-fpm.sock 
pour remplacer par
listen = 127.0.0.1:9000

et on redémarre php-fpm et nginx 

PHP ne s’exécute pas mais affiche le code à la place, Nginx n’arrive pas à communiquer avec php-fpm. Vérifiez que ce dernier soit bien démarré.

cela veut dire que le fichier est traité comme un fichier texte, vérifiez que vous avez inclus

Note : Créer une nouvelle image avec ces modifications

Créer une image avec toutes ces modifications, afin de ne pas avoir à refaire les manipulations, en somme préparer une image pour un usage.

Important avant de commiter

/!\ Quittez tous les process à l’intérieur du docker, quittez le docker et vérifiez que le process docker en question est stoppé avec docker ps.

Ensuite on va commiter le docker avec son id selon la syntaxe suivante:

docker ps -a // pour voir l'id du container 

docker commit <nom_ou_id_du_conteneur> monimage:1.0

docker commit b425 monimage:1.0

Sauver l’image docker dans le repository distant (hub de docker)

Ensuite vous devez sauver cette image dans un repository, le plus commun est le hub de docker.com

// connexion avec le hub
docker login

// tagging de l'image avant de pouvoir l'envoyer dans le repository
docker tag debian-nginx refschool/debian-nginx:1.0
^ debian-nginx est l'image qu'on vient de créer
// push de l'image docker
docker push refschool/debian-nginx:1.0

Rappel de commandes Nginx sans Systemd et sans supervisor

• démarrer en avant plan : nginx -g « daemon off »; »
• test du fichier de configuration : nginx -t
• arrêt : nginx -s stop
• arrêt graceful : nginx -s quit (nginx arrête les connexions avant de s’arrêter
• redémarrer : nginx -s reload
• savoir si nginx tourne : ps aux | grep nginx

ON a vu comment mettre Nginx en reverse proxy, nous aller plus loin en configurant un load balancer

Qu’est ce qu’un load balancer?

Un load balancer permet de répartir la charge d’un site web sur plusieurs serveur qui tournent indépendamment. Un serveur web qui reçoit beaucoup de visite aura tendance à ralentir, ce n’est pas la résolution de la ressource qui est lente, car l’opération demande peu de ressource, mais le travail du serveur pour calculer la page web. D’où l’idée de monter plusieurs serveurs et de monter un reverse proxy qui va être le premier à intercepter la requête et à la rediriger vers un des serveurs.

Installation de Nginx

sudo apt install -y nginx

Fichier de configuration de Nginx

Le fichier de configuration se trouve dans /etc/nginx/nginx.conf

server {

listen 80;
server_name   myserver;

location /static {
    root /var/www/myserver;

}

location / {
    proxy_pass  http://localhost:8000;
    proxy_http_version. 1.1;
    proxy_set_header X-Forwarder-Host $server_name;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

}

}

Modification du fichier de configuration pour indiquer les 3 hôtes

log_format upstreamlog '$server_name to: $upstream_addr [$request] '
    'upstream_response_time $upstream_response_time'
    'msec $msec

upstream serveurs {
    server http://localhost:8000;
    server http://localhost:8001;
    server http://localhost:8002;

}


server {

    listen 80;
    server_name   myserver;
    access_log    /var/log/nginx/access.log  upstreamlog;

location /static {
    root /var/www/myserver;

}

location / {
    proxy_pass  http://serveurs;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarder-Host $server_name;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

}

}

Dry run ou lancement d’essai pour vérifier que le script n’est pas en erreur

sudo nginx -t 

// pas d'erreur normalement


sudo systemctl reload nginx


sudo tail -f /var/www/nginx/access_log

Maintenant dans votre navigateur, allez à l’adresse http://myserver, et rechargez plusieurs fois. Regardez les logs, on doit voir les 3 port du localhost utilisés.

La stratégie round robin

Avec cette stratégie, le reverse proxy distribue à tout le monde équitablement, chacun son tour.

On va faire une application NodeJS qu’on va lancer trois fois avec des ports différents

Je passe un peu en revue les directives utilisées dans le fichier de configuration du cache.

Nginx utilisé en reverse proxy sans le caching des pages ne rime à rien. On l’utilise pour servir du contenu statique afin d’accélérer grandement le temps de téléchargement, et croyez moi il est plutôt performant !

Un serveur proxy se met entre l’internaute et le serveur Apache par exemple (mais ça peut être n’importe quel serveur).

 

 

Directive	Signification
proxy_cache	définit une zone mémoire partagée pour stocker le cache
proxy_cache_bypass
proxy_cache_key	une valeur de type string, utilisée pour classer les parties du cache
proxy_cache_lock	si plusieurs requêtes demandent une page non cachée, la première crée le contenu caché avant que les autres puissent lire le cache évitant à toutes les requêtes de demander du contenu dynamique
proxy_cache_lock_timeout
proxy_cache_min_uses	nombre de fois qu’un contenu demandé avant d’être caché
proxy_cache_path	répertoire ou sera placé le contenu caché, on y place les clé (qui identifie les pages cachées) et le métadonnées
proxy_cache_use_stale	définit le cas de figure où l’on sert du contenu caché lorsque l’appel au serveur du backend (Apache) donne une erreur
proxy_cache_valid	durée du vie du cache (la page web doit retourner 200,301 ou 301), ici cela veut dire que les page retournant un code cité ci-dessus sera caché, les pages 404 par exemple ne sont pas cachée

Aujourd’hui le moteur de recherche Google veut faire de la vitesse de chargement d’un site web un critère de ranking dans les SERPs.

Ce n’est pas idiot, et de toute façon, sans même parler de moteur de recherche, il est important d’avoir un site web qui va vite.

Dans le domaine du e-commerce par exemple, il ne faut pas que la vitesse de chargement dépasse 4 secondes.(les puriste disent 2), mais on va dire 3 (coupons la poire en deux) c’est ok.

Le problème est quand le site de e-commerce devient grand, quand il y a beaucoup de gens qui visitent le site (forcément vous avez un site qui marche sinon), et de même il n’y a pas que des humains qui vous rendent visite il y a aussi les spiders !

Entre Google bot qui passe toutes les minutes ou toutes les 10 secondes, les bots de majesticSEO ou de Ahrefs, archive.org etc, votre Apache hé bien il est surchargé.

Vous aurez beau optimiser les facteurs suivants : compression GZIP, mise en place d’un cache, utilisation de serveur de médias, de CDN, de minification des scripts, de mise en place de javascript à la fin, ces solution ont une limite à la fin, cela ne suffira pas.

La solution ultime c’est NGINX !

C’est quoi Nginx? c’est un serveur web comme Apache, écrit par un Russe, il est plutôt peu gourmand en ressource, et il est rapide pour servir des fichiers statique. Statique? vous dites Cache? hé bien c’est pas loin !

Le secret ici est de servir tout ce qui est statique par NGINX et ce qui est dynamique par Apache.

Nginx est dans ce cas ce qu’on appelle un reverse proxy, ou serveur frontal. Définition sur cette page.

Donc avec Nginx on peut faire ces 5 choses :

1. servir du contenu statique
2. intermédiaire de sécurité
3. terminal SSL
4. répartition de charge (load balancing)
5. compression de site

Nous allons donc dans les lignes qui suivent, installer Nginx sur un serveur dédié qui tourne déjà avec le serveur web Apache, ils seront donc sur la même machine.

Installation de Nginx en ligne de commande (Linux Debian)

Là je suppose que vous avez des connaissance en shell, c’est très simple, il faut installer Nginx avec la commande suivante :

$ apt-get install nginx

il faut que vous vous loggiez en root pour faire marcher cette commande.

Une fois que Nginx est installé, il y a déjà un fichier de configuration example. Sauvegardez ce fichier sur votre ordinateur pour le réutiliser si besoin, mais on n’aura pas besoin, cependant renommez ce fichier au nom de votre site web. J’utilise Winscp pour manipuler de manière sécurisée les fichiers depuis mon ordinateur en effet le faire en ligne de commande est assez fastidieux.

Configuration d’un fichier serveur Nginx

Le fichier de configuration de site web de Nginx doit être installé dans le répertoire (pour les Debian) , comme pour Apache 2, dans sites-available et sites-enabled.

« Available » veut disponible et « enable » veut dire activé. En fait si vous avez un fichier dans « enabled », ça veut dire que le site est en ligne.

Le fichier dans sites-enabled est un lien symbolique vers le fichier de configuration du répertoire site-available.

Nginx en ce qui concerne les webmasters a deux fonctions bien distinctes, soit vous l’utilisez pour remplacer Apache (ce dernier est donc à virer) soit vous l’utiliser comme reverse proxy (thème de cet article), donc il fonctionnera parallèlement à Apache !

Notion fondamentale : Si Nginx et Apache fonctionnement en même temps, pour éviter tout conflit, Apache qui écoute habituellement sur le port 80 doit changer de port, on le mettre sur le port 8080, et Nginx sur le port 80, ce qui suppose une modification du fichier de configuration d’Apache comme on le verra plus tard dans cet article.

Imaginons que je veuille proxier phpninja.fr

server {

  listen   80; ## listen for ipv4

  server_name  phpninja.fr www.phpninja.fr;
  access_log  /var/log/nginx/localhost.access.log;

  location / {
    root   /home/phpninja.fr/public_html/;
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php;
  }


  # proxy the PHP scripts to Apache listening on 127.0.0.1:8080
  #
  location ~ \.php$ {

  proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;

  proxy_set_header Host $host;
  proxy_pass   http://88.191.158.109:8080;
  }



  # deny access to .htaccess files, if Apache's document root
  # concurs with nginx's one
  #
  location ~ /\.ht {
    deny  all;
  }
}

Listen 80 : on dit à nginx d'écouter sur le port 80

Server name : on donne les sites à proxier

Un fichier de log est spécifié, utile quand vous voulez débugger.

Dans Location /, vous lui dites où se trouve la racine du site web, le fichier index, et try files sert à dire à Nginx de proxier toutes les requêtes, si Nginx ne peut pas, alors il va passer le requête à Apache.

Location ~ \.php$  est trè_s important, il dit qu’il faut passer les fichier php à Apache. Comme dit plus haut Nginx ne vient pas avec le support de php, donc il est logique que ce soit Apache qui le fasse.

Proxy pass indique l’adresse IP du serveur auquel les requêtes sont passée (adresse IP de votre virtual host Apache).

Enfin location ~ /\.ht sert à éviter tout conflit dans l’interprétation du fichier type htaccess, ht_password etc dans le cas ou Nginx et Apache en ont.

Modification de la partie Apache

Il faut maintenant qu’Apache écoute sur le port 8080, c’est la seule modification que vous aurez à faire. Dans le cas de Debian, il faut modifier le fichier ports.conf comme suit:

Listen 88.191.158.109:8080
Listen 443

Il faut aussi modifier NameVirtualHost

NameVirtualHost 88.191.158.109:8080

Faire la manip sur tous les fichiers Vhost même si vous ne voulez pas les proxier. Dans tous les cas il faut le faire car Apache doit écouter sur 8080 au lieu de 80, sinon le démarrage de Nginx sera problématique.

ensuite il faut installer le module rpaf.

Il sert à envoyer à Apache l’IP du navigateur et non celui de Nginx, sinon vous perdrez cette information.

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 213.246.45.34

spécifier l’adresse publique du proxy.

Conclusion

Redémarrer Apache et Nginx avec les commandes :

service apache2 restart
service nginx restart

Si tout se passe bien, vous allez voir une accélération de votre site ! Et encore on n’a pas encore fait les optimisations de Nginx !

Pour vous amuser, vous pouvez mettre un fichier info.php avec l’instruction phpinfo().

Dans la page qui s’affichera, vous verrez la signature de Apache.

Par contre si vous avez Firebug, ou Httpfox, vous verrez la réponse du serveur le nom Nginx.