Nginx + WP Rocket : Comment configurer le Bypass PHP

C’est le défi permanent de tout administrateur système : comment rendre une infrastructure WordPress tellement robuste qu’un pic de trafic ne fera pas broncher le CPU ? Dans un précédent article, nous avions vu comment optimiser la sécurité globale de WordPress Si vous cherchez la performance ultime, configurer un bypass php nginx wp rocket est la solution la plus efficace. En effet, si vous gérez vos optimisations applicatives avec l’excellent plugin WP Rocket, l’extension va naturellement générer des pages HTML statiques sur votre serveur. C’est une excellente première étape, mais par défaut, la configuration laisse souvent PHP faire une partie du travail de distribution.

Comprendre l’architecture interne

Pour mesurer l’impact du Bypass PHP, il faut analyser la manière dont un serveur Nginx fait transiter les requêtes.

Le frontal SSL (Port 443) : Il gère le chiffrement HTTPS et applique vos règles de sécurité globales.
Le serveur applicatif (Port 8080) : C’est lui qui héberge l’instance WordPress et communique directement avec PHP-FPM.

Le problème du circuit par défaut

Même lorsque WP Rocket a déjà généré une page HTML statique dans son dossier de cache, le circuit d’une requête standard ressemble à ceci :

+--------------+          +------------------------+          +--------------------------+
 |  🌐 Visiteur  | --------> |   🔒 Nginx Frontal     | --------> |    ⚙️ Nginx Applicatif    |
 +--------------+          |      (Port 443)        |          |       (Port 8080)        |
        ^                  +------------------------+          +--------------------------+
        |                                                                   |
        |                                                                   v
 +------------------------------+                              +--------------------------+
 |  🚀 WP Rocket (Lit le HTML)  | <--------------------------- |    🐘 PHP-FPM (Actif)    |
 +------------------------------+                              +--------------------------+

Bien que la base de données MySQL soit soulagée, PHP-FPM doit s’activer à chaque visite pour charger le script de WP Rocket, qui va ensuite lire le fichier HTML sur le disque. Lors d’une forte affluence, les processus PHP s’empilent et le CPU du VPS sature inutilement.

L’objectif du Bypass PHP est radical : couper l’accès à PHP-FPM pour les pages déjà cachées.

+--------------+          +------------------------+          +--------------------------+
 |  🌐 Visiteur  | --------> |        ⚙️ Nginx        | --------> |   💾 Stockage SSD/NVMe   |
 +--------------+          |      (Bypass PHP)      |          |  (Lecture directe HTML)  |
        ^                  +------------------------+          +--------------------------+
        |                                                                   |
        +-------------------------------------------------------------------+
                             [ 🛑 PHP-FPM RESTE EN VEILLE ]

Pourquoi cette architecture hybride est redoutable

Décharger le serveur web tout en conservant une extension de cache peut sembler paradoxal, mais cela offre le meilleur des deux mondes :

Côté Serveur (Nginx) : Il gère la distribution du HTML brut pour les utilisateurs anonymes à une vitesse proche du statique pur.
Côté Applicatif (WP Rocket) : L’extension conserve la main sur la structure des fichiers, l’optimisation fine du Front-End (minification CSS/JS, lazyloading, polices) et la purge automatique lors de la publication d’un article.

Configuration du Vhost : Mettre en place le bypass php nginx wp rocket

La modification se passe au niveau du port applicatif 8080 dans CloudPanel pour intercepter la requête juste avant qu’elle ne soit transmise à PHP.

Étape 1 : Accéder au Vhost

Dans votre interface CloudPanel, allez dans Sites, sélectionnez votre instance WordPress et ouvrez l’onglet Vhost.

Étape 2 : Injecter les règles Nginx

Faites défiler le fichier jusqu’au bloc server {} qui écoute sur le listen 8080;.

Juste au-dessus de la ligne try_files $uri $uri/ /index.php?$args;, insérez le bloc suivant :

# --- DEBUT DU BLOC OPTIMISATION WP ROCKET ---
  # Initialisation des variables pour sécuriser le comportement de Nginx
  set $rocket_end 1;
  set $rocket_bypass 0;

  # Exclusion stricte du cache (Requêtes POST, variables de recherche, etc.)
  if ($request_method = POST) { set $rocket_end 0; }
  if ($query_string != "") { set $rocket_end 0; }
  if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $rocket_end 0; }

  # Définition du chemin dynamique vers le fichier HTML de WP Rocket
  set $rocket_file "/wp-content/cache/wp-rocket/$http_host$request_uri/index-https.html";

  # Vérification de l'existence physique du fichier sur le stockage
  if (-f $document_root$rocket_file) { 
      set $rocket_bypass $rocket_end; 
  }

  # Si toutes les conditions sont validées (= 1), Nginx sert le HTML directement
  if ($rocket_bypass = 1) {
      rewrite ^(.*)$ $rocket_file last;
  }
  # --- FIN DU BLOC OPTIMISATION WP ROCKET ---

Étape 3 : Sauvegarder

Cliquez sur Save. CloudPanel valide la syntaxe Nginx et recharge le service instantanément et sans coupure.

Le verdict : Crash test du TTFB

Analysez le temps de réponse de votre document principal, le TTFB (Time To First Byte) :

Avant l’optimisation : Le TTFB moyen oscillait entre 150ms et 300ms (le temps de traitement par PHP-FPM).
Après l’optimisation : Le TTFB s’effondre entre 10 et 25 millisecondes.

Le gain est immédiat. Nginx distribue désormais le HTML à la vitesse de l’éclair directement depuis le stockage NVMe, sans consommer de ressources CPU pour PHP. Votre serveur respire, vos scores Core Web Vitals s’envolent, et votre infrastructure WordPress est parée pour encaisser de lourdes charges.