mod_rewrite pour Nginx : .htaccess dans CMS

Module Nginx mod_rewrite : Prise en charge de .htaccess pour les CMS

Nginx ne prend pas en charge le fichier .htaccess d'Apache, ce qui pose des défis lors de la migration de sites web vers des plateformes CMS populaires comme WordPress, Drupal ou Grav. Ces systèmes dépendent de mod_rewrite pour les URL optimisées pour le référencement, la protection des répertoires et la gestion des erreurs. Sans .htaccess, les CMS renvoient des erreurs 404 ou nécessitent des configurations Nginx + Apache, ajoutant de la complexité.

Un module appelé nginx-mod-rewrite a été développé pour émuler mod_rewrite. Il analyse .htaccess à la volée, appliquant les règles de réécriture, y compris les redirections internes et le repli sur index.php. Le module fonctionne aux niveaux serveur, location et .htaccess, minimisant les lectures de fichiers grâce à un cache dans le pool de requêtes.

Approches de solution dans les panneaux de contrôle

Les panneaux de contrôle comme HestiaCP abordent le problème de deux manières :

• try_files $uri $uri/ index.php?$args — couvre 50–80 % des cas mais pas toutes les règles mod_rewrite.
• Modèles ngx_http_rewrite_module — un équivalent complet de .htaccess pour des CMS spécifiques, mais lie étroitement la configuration à la plateforme.

Le module nginx-mod-rewrite élimine ces limitations : il prend en charge RewriteMap (minimalement), RewriteOptions, ne nécessite pas de modèles et permet de modifier .htaccess sans privilèges d'administrateur serveur.

Construction et installation du module

La construction est possible sur l'hôte ou dans Docker. Pour Almalinux 9 :

• Installez Docker.
• Clonez le dépôt.
• Exécutez bash package_preparer.sh prepare "almalinux:9".

Le résultat est des paquets RPM dans tmpbuild/ :

tmpbuild/nginx-mod-rewrite-0.1-1.el9.src.rpm
tmpbuild/nginx-mod-rewrite-0.1-1.el9.x86_64.rpm
tmpbuild/nginx-mod-rewrite-debuginfo-0.1-1.el9.x86_64.rpm
tmpbuild/nginx-mod-rewrite-debugsource-0.1-1.el9.x86_64.rpm

De même pour Debian — paquets DEB.

Configuration du serveur

Exemple de bloc serveur pour un site CMS :

server {
	listen      127.0.0.1:80;
	server_name test.my.brp www.test.my.brp;
	root        /home/test/web/test.my.brp/public_html;
	index       index.php index.html index.htm;

	HtaccessEnable on;

	location ~ /\.(?!well-known\/) {
		deny all;
		return 404;
	}

	location ~* ^.+\.(jpeg|jpg|png|webp|gif|bmp|ico|svg|css|js|txt)$ {
		expires max;
		fastcgi_hide_header "Set-Cookie";
	}

	location / {
		RewriteEngine On;

		location ~ [^/]\.php(/|$) {
			try_files $uri =404;

			include /etc/nginx/fastcgi_params;

			fastcgi_index index.php;
			fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

			fastcgi_pass unix:/run/php74-fpm.sock;
		}
	}
}

HtaccessEnable on active l'analyse de .htaccess. Les fichiers statiques sont exclus du traitement de réécriture pour la performance.

Benchmarks de performance

Tests sur Drupal (wrk, 30 secondes) :

| Scénario | Nginx + php-fpm | Nginx + mod_rewrite | Nginx + Apache + php-fpm |

|---------------------------|-----------------|--------------------|---------------------------|

| / (repli index.php) | 129,74 req/s | 125,94 req/s | 121,31 req/s |

| /robots.txt (statique) | 7384,25 req/s | 4591,31 req/s | 2007,70 req/s |

| /user/login (réécriture) | 126,48 req/s | 128,58 req/s | 117,78 req/s |

Le module est proche de Nginx pur en vitesse et surpasse la combinaison Apache. Le contenu statique ralentit en raison de l'analyse de .htaccess mais est optimisé avec des exclusions de location.

Points clés

• Le module émule entièrement mod_rewrite, y compris les redirections internes et le cache .htaccess.
• Prise en charge des CMS sans modèles : WordPress, Drupal, Grav fonctionnent avec .htaccess natif.
• Performance : 90–100 % de Nginx pur, sans surcharge Apache.
• Construction en RPM/DEB pour RHEL/Debian, avec support Docker.
• Limitations : RewriteMap minimal, RewriteOptions simplifié (suffisant pour les CMS).

— Editorial Team