Apache zu Nginx migrieren — die Übersetzungs-Patterns und das Playbook, das wir nutzen

Apache-zu-Nginx-Migrationen hängen fast immer am selben Punkt fest: .htaccess. Der Anwendungs-Owner glaubt, die Datei mache etwas Unersetzliches. Neun von zehn Malen ist es eine RewriteRule-Kette, die sich in zwei Zeilen Nginx-Konfig übersetzen lässt. Das zehnte Mal ist eine mod_rewrite-Regel so labyrinthisch, dass die sicherere Antwort ist, die Anwendung stattdessen zu fixen.

Dies ist die Übersetzungstabelle, das Runbook und die Stolperfallen-Liste, die wir in jedem Apache-zu-Nginx-Engagement nutzen.

Die Übersetzungstabelle — die Regeln, die 90 % der Fälle abdecken

# Apache: RewriteRule ^(.*)$ /index.php?route=$1 [L]
location / {
  try_files $uri $uri/ /index.php?route=$request_uri;
}
 
# Apache: Order Deny,Allow / Deny from all
location ~ /\.git { deny all; return 404; }
 
# Apache: AuthType Basic / AuthUserFile
location /admin/ {
  auth_basic "restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

.htaccess hat kein sauberes Äquivalent in Nginx — und das ist ein Feature. Die Konfiguration lebt an einem Ort, nicht über jedes Verzeichnis Ihres Webroots verteilt.

Der vollständige Beitrag behandelt:

• Die mod_rewrite-Patterns, die direkt mappen, und die, die ein Umdenken erfordern
• Die PHP-FPM-Verdrahtung — der FastCGI-Block, den wir auf jede Site kopieren
• Apache-vs-Nginx-Logging-Eigenheiten (Combined-Format-Unterschiede, Error-Log-Levels)
• Sticky-Session- und Cookie-Affinity-Patterns beim Load Balancing
• Der Dual-Running-Cutover (Apache auf :8080, Nginx auf :443, Traffic am Edge geshaped)
• Der 24-Stunden-Smoke-Test, den wir nach dem Cutover fahren, bevor wir „fertig" erklären

Melden Sie sich, wenn Sie ein zweites Augenpaar auf Ihre möchten.