# Configurer un bloc serveur nginx pour WordPress, de zéro jusqu’à la production

> Un fichier de configuration nginx propre évite la moitié des soucis de performance et de sécurité d'un site WordPress. Voici un bloc serveur complet, expliqué ligne par ligne.

- Auteur : Clément Hadrot
- Publié le : 2020-07-08
- Mis à jour le : 2020-07-08
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/configurer-bloc-serveur-nginx-wordpress-production/

## L’essentiel

- Le bloc location protège wp-config.php et les fichiers sensibles
- try_files gère les permaliens sans .htaccess
- Le socket PHP-FPM doit être déclaré explicitement

Contrairement à Apache, nginx ne lit pas de fichier `.htaccess` à chaque requête : toute la configuration doit être écrite explicitement dans le bloc serveur, une fois pour toutes. C'est un changement d'habitude pour un développeur venu d'un environnement mutualisé habitué au fichier `.htaccess` généré automatiquement par WordPress. La bonne nouvelle, c'est que cette configuration statique, une fois correcte, est plus rapide à l'exécution et plus simple à auditer.

Ce guide part d'un VPS Debian avec nginx et PHP-FPM déjà installés, et construit un bloc serveur complet pour un site WordPress classique, sans multisite. Chaque section explique pourquoi elle existe, pas seulement ce qu'elle fait.

## Le bloc serveur de base

Le fichier se place généralement dans `/etc/nginx/sites-available/exemple.fr`, avec un lien symbolique vers `sites-enabled` :

```
server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    root /var/www/exemple.fr/public;
    index index.php;

    access_log /var/log/nginx/exemple.fr-access.log;
    error_log /var/log/nginx/exemple.fr-error.log;
}
```

Ce squelette ne fait encore rien de spécifique à WordPress : il faut y ajouter la gestion des permaliens, l'exécution PHP et la protection des fichiers sensibles.

## Gérer les permaliens avec try_files

WordPress s'appuie sur des URL réécrites (les permaliens) qui n'existent pas physiquement sur le disque. La directive `try_files` reproduit le comportement du `.htaccess` par défaut :

```
location / {
    try_files $uri $uri/ /index.php?$args;
}
```

Cette ligne signifie : « essaie de servir le fichier demandé tel quel, sinon essaie un dossier de ce nom, sinon transmets tout à `index.php` avec les paramètres d'origine ». C'est ce mécanisme qui permet à une URL comme `/mon-article/` d'être interprétée correctement par WordPress.

## Transmettre les requêtes PHP à PHP-FPM

PHP-FPM tourne en général comme un processus séparé, joignable via un socket Unix ou un port TCP. Le bloc suivant transmet toute requête `.php` à ce processus :

> L'essentiel à retenir : Le bloc location protège wp-config.php et les fichiers sensibles ; try_files gère les permaliens sans .htaccess ; Le socket PHP-FPM doit être déclaré explicitement

```
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.0-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
```

Le chemin du socket doit correspondre exactement à celui déclaré dans le pool PHP-FPM concerné (fichier dans `/etc/php/8.0/fpm/pool.d/`). Une erreur fréquente consiste à copier un exemple trouvé en ligne sans vérifier ce chemin, ce qui provoque une erreur 502 Bad Gateway sur chaque page dynamique.

## Protéger les fichiers sensibles

Certains fichiers ne doivent jamais être servis directement par le navigateur, même s'ils sont accessibles par leur chemin exact :

- `wp-config.php`, qui contient les identifiants de la base de données.
- Les fichiers cachés commençant par un point, comme `.git` ou `.env` s'ils traînent par erreur.
- Les fichiers XML et journaux qui ne servent qu'en interne.

```
location ~ /wp-config.php {
    deny all;
}
location ~ /\. {
    deny all;
}
```

## Bloquer l'exécution PHP dans les uploads

Le dossier `wp-content/uploads` ne devrait jamais exécuter de script PHP : c'est un vecteur classique d'intrusion, lorsqu'un fichier malveillant déguisé en image y est déposé puis exécuté directement. Un bloc dédié referme cette porte :

```
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}
```

## Mettre en cache les fichiers statiques

Les images, feuilles de style et scripts n'ont pas besoin de repasser par PHP à chaque requête. Une directive dédiée fixe une durée de cache navigateur raisonnable :

```
location ~* \.(jpg|jpeg|png|gif|css|js|woff2)$ {
    expires 30d;
    access_log off;
}
```

> Une configuration nginx correcte pour WordPress tient toujours sur moins d'une centaine de lignes. Si le fichier grandit sans cesse, c'est souvent le signe d'un contournement mal compris plutôt que d'un vrai besoin.

## Notre verdict

Écrire ce bloc serveur soi-même, plutôt que de copier un exemple générique trouvé en ligne, oblige à comprendre chaque directive. C'est un investissement de trente minutes qui évite des heures de diagnostic plus tard, le jour où une page blanche apparaît en production et qu'il faut savoir exactement ce que le serveur fait de chaque requête.