mod_rewrite für Nginx: .htaccess in CMS

Nginx mod_rewrite-Modul: .htaccess-Unterstützung für CMS

Nginx unterstützt nicht die .htaccess-Dateien von Apache, was Herausforderungen bei der Migration von Websites zu beliebten CMS-Plattformen wie WordPress, Drupal oder Grav mit sich bringt. Diese Systeme setzen auf mod_rewrite für SEO-freundliche URLs, Verzeichnisschutz und Fehlerbehandlung. Ohne .htaccess liefern CMS entweder 404-Fehler aus oder erfordern Nginx + Apache-Konfigurationen, was zusätzlichen Aufwand bedeutet.

Ein Modul namens nginx-mod-rewrite wurde entwickelt, um mod_rewrite zu emulieren. Es analysiert .htaccess-Dateien on-the-fly und wendet Rewrite-Regeln an, einschließlich interner Weiterleitungen und Fallback auf index.php. Das Modul arbeitet auf Server-, Location- und .htaccess-Ebene und minimiert Dateizugriffe durch Request-Pool-Caching.

Lösungsansätze in Control Panels

Control Panels wie HestiaCP gehen das Problem auf zwei Arten an:

• try_files $uri $uri/ index.php?$args — deckt 50–80 % der Fälle ab, aber nicht alle mod_rewrite-Regeln.
• ngx_http_rewrite_module-Vorlagen — eine vollständige .htaccess-Entsprechung für bestimmte CMS, bindet die Konfiguration jedoch eng an die Plattform.

Das nginx-mod-rewrite-Modul beseitigt diese Einschränkungen: Es unterstützt RewriteMap (minimal), RewriteOptions, benötigt keine Vorlagen und ermöglicht die Bearbeitung von .htaccess-Dateien ohne Server-Admin-Rechte.

Bauen und Installieren des Moduls

Der Bau ist auf dem Host oder in Docker möglich. Für Almalinux 9:

• Docker installieren.
• Repository klonen.
• bash package_preparer.sh prepare "almalinux:9" ausführen.

Das Ergebnis sind RPM-Pakete in 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

Analog für Debian — DEB-Pakete.

Server-Konfiguration

Beispiel-Serverblock für eine CMS-Website:

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 aktiviert die .htaccess-Analyse. Statische Dateien sind für die Leistung von der Rewrite-Verarbeitung ausgeschlossen.

Performance-Benchmarks

Tests mit Drupal (wrk, 30 Sekunden):

| Szenario | Nginx + php-fpm | Nginx + mod_rewrite | Nginx + Apache + php-fpm |

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

| / (Fallback index.php) | 129,74 Anfragen/s | 125,94 Anfragen/s | 121,31 Anfragen/s |

| /robots.txt (statisch) | 7384,25 Anfragen/s | 4591,31 Anfragen/s | 2007,70 Anfragen/s |

| /user/login (Rewrite) | 126,48 Anfragen/s | 128,58 Anfragen/s | 117,78 Anfragen/s |

Das Modul ist in der Geschwindigkeit nahe an reinem Nginx und übertrifft die Apache-Kombination. Statische Inhalte verlangsamen sich durch .htaccess-Analyse, werden aber mit Location-Ausschlüssen optimiert.

Wichtige Punkte

• Das Modul emuliert mod_rewrite vollständig, einschließlich interner Weiterleitungen und .htaccess-Caching.
• CMS-Unterstützung ohne Vorlagen: WordPress, Drupal, Grav funktionieren mit nativer .htaccess.
• Leistung: 90–100 % von reinem Nginx, ohne Apache-Overhead.
• Baut in RPM/DEB für RHEL/Debian, mit Docker-Unterstützung.
• Einschränkungen: minimale RewriteMap, vereinfachte RewriteOptions (ausreichend für CMS).

— Editorial Team