mod_rewrite dla Nginx: .htaccess w CMS

Moduł mod_rewrite dla Nginx: obsługa .htaccess w systemach CMS

Nginx nie obsługuje plików .htaccess z Apache, co utrudnia migrację stron na popularne systemy CMS, takie jak WordPress, Drupal czy Grav. Te systemy opierają się na mod_rewrite do obsługi przyjaznych URL-i (SEO), ochrony katalogów i zarządzania błędami. Bez .htaccess CMS mogą zwracać błąd 404 lub wymagać połączenia Nginx + Apache, co zwiększa obciążenie.

Opracowano moduł nginx-mod-rewrite, który emuluje mod_rewrite. Analizuje on .htaccess w locie, stosując reguły rewrite, w tym wewnętrzne przekierowania i fallback do index.php. Moduł działa na poziomach server, location i .htaccess, minimalizując odczyty pliku dzięki buforowaniu w puli żądań.

Podejścia do rozwiązania w panelach zarządzania

Panele kontrolne, takie jak HestiaCP, rozwiązują problem na dwa sposoby:

• try_files $uri $uri/ index.php?$args — obejmuje 50–80% przypadków, ale nie wszystkie reguły mod_rewrite.
• Szablony ngx_http_rewrite_module — pełny odpowiednik .htaccess dla konkretnego CMS, ale sztywno wiążą konfigurację z platformą.

Moduł nginx-mod-rewrite eliminuje ograniczenia: obsługuje RewriteMap (w minimalnym zakresie), RewriteOptions, nie wymaga szablonów i umożliwia edycję .htaccess bez uprawnień administratora serwera.

Kompilacja i instalacja modułu

Kompilacja jest możliwa na hoście lub w Dockerze. Dla Almalinux 9:

• Zainstaluj Docker.
• Sklonuj repozytorium.
• Wykonaj bash package_preparer.sh prepare "almalinux:9".

Wynik to pakiety RPM w 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

Analogicznie dla Debiana — pakiety DEB.

Konfiguracja serwera

Przykład bloku server dla strony z 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 aktywuje analizę .htaccess. Pliki statyczne są wyłączone z przetwarzania rewrite dla wydajności.

Testy wydajności

Testy na Drupal (wrk, 30 sekund):

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

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

| / (fallback index.php) | 129.74 req/s | 125.94 req/s | 121.31 req/s |

| /robots.txt (statyczny) | 7384.25 req/s | 4591.31 req/s | 2007.70 req/s |

| /user/login (rewrite) | 126.48 req/s | 128.58 req/s | 117.78 req/s |

Moduł jest zbliżony do czystego Nginx pod względem prędkości, przewyższa połączenie z Apache. Obsługa plików statycznych spowalnia z powodu analizy .htaccess, ale można to zoptymalizować wyjątkami w location.

Co jest ważne

• Moduł w pełni emuluje mod_rewrite, w tym wewnętrzne przekierowania i buforowanie .htaccess.
• Obsługa CMS bez szablonów: WordPress, Drupal, Grav działają z natywnymi plikami .htaccess.
• Wydajność: 90–100% czystego Nginx, bez obciążenia Apache.
• Kompilacja w RPM/DEB dla RHEL/Debian, obsługa Docker.
• Ograniczenia: minimalny RewriteMap, uproszczone RewriteOptions (wystarczające dla CMS).

— Editorial Team