So konfigurieren Sie Nginx + PHP richtig

Für viele Menschen ist die Konfiguration von Nginx+PHP nichts anderes, als nach einem Tutorial zu suchen und es dann zu kopieren und einzufügen. Es hört sich so an, als wäre daran nichts auszusetzen, aber tatsächlich sind viele Informationen im Internet in einem schlechten Zustand und voller Lücken. Wenn Sie sie einfach kopieren und einfügen, ohne nach einem tieferen Verständnis zu suchen, werden Sie früher oder später den Preis zahlen.

Angenommen, wir verwenden PHP, um einen Front-End-Controller zu implementieren, oder um es klar auszudrücken, einen einheitlichen Eingang: Senden Sie alle PHP-Anfragen an dieselbe Datei und implementieren Sie dann das Routing, indem Sie „REQUEST_URI“ in dieser Datei analysieren.

Konfigurieren Sie es im Allgemeinen so
Zu diesem Zeitpunkt lernen Sie in vielen Tutorials, wie Sie Nginx+PHP wie folgt konfigurieren:

server {
  listen 80;
  server_name foo.com;
 
  root /path;
 
  location / {
    index index.html index.htm index.php;
 
    if (!-e $request_filename) {
      rewrite . /index.php last;
    }
  }
 
  location ~ /.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
  }
}

Darin oder bei Zumindest ist es ein schlechter Geruch. Schauen wir mal, wie viele Sie finden können.
Wir müssen zunächst die Vererbungsbeziehung der Anweisungen in der Nginx-Konfigurationsdatei verstehen:
Die Nginx-Konfigurationsdatei ist in viele Blöcke unterteilt. Die häufigsten sind von außen nach innen „http“, „server“, „. „Standort“ usw. Die Standardvererbungsbeziehung verläuft von außen nach innen, was bedeutet, dass der innere Block automatisch den Wert des äußeren Blocks als Standardwert erhält.

Beginnen wir mit der „Index“-Direktive
In der Problemkonfiguration ist sie in „Standort“ definiert:

location / {
  index index.html index.htm index.php;
}

Sobald ein neuer „Standort“ vorhanden ist, wird es ihn zwangsläufig immer wieder geben Dies liegt daran, dass mehrere „Standorte“ in einer horizontalen Beziehung stehen und keine Vererbung erfolgt. Zu diesem Zeitpunkt sollte „Index“ in „Server“ definiert werden und die Vererbungsbeziehung „Index“ verwendet werden. Die Richtlinie ist an allen „Standorten“ wirksam.

Werfen wir einen Blick auf den „if“-Befehl
Es ist keine Übertreibung zu sagen, dass es der am meisten missverstandene Nginx-Befehl ist:

if (!-e $request_filename) {
  rewrite . /index.php last;
}

Viele Leute verwenden gerne den „if“-Befehl Eine Reihe von Prüfungen, aber dies liegt eigentlich in der Verantwortung der „try_files“-Anweisung:
try_files $uri $uri/ /index.php
Darüber hinaus denken Anfänger oft, dass das „if“; Die Anweisung ist eine Direktive auf Kernel-Ebene, aber eigentlich Teil des Rewrite-Moduls, und die Nginx-Konfiguration ist eigentlich deklarativ und nicht prozedural. Wenn sie also mit Anweisungen von Nicht-Rewrite-Modulen gemischt wird, ist das Ergebnis möglicherweise nicht das, was Sie wollen.

Werfen wir einen Blick auf die Konfigurationsdatei „fastcgi_params“
include fastcgi_params;
Nginx hat zwei Fastcgi-Konfigurationsdateien, nämlich „fastcgi_params“ und „fastcgi.conf“, das sind sie nicht zu groß Der einzige Unterschied besteht darin, dass Letzteres eine Zeile mehr mit der Definition von „SCRIPT_FILENAME“ hat als Ersteres:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Ursprünglich hatte Nginx nur „fastcgi_params“. Später stellte sich heraus, dass viele Leute beim Definieren von „SCRIPT_FILENAME“ Hartcodierung verwendeten, daher wurde „fastcgi.conf“ eingeführt, um die Verwendung zu standardisieren.
Dies wirft jedoch eine Frage auf: Warum muss eine neue Konfigurationsdatei eingeführt werden, anstatt die alte Konfigurationsdatei zu ändern? Dies liegt daran, dass die Anweisung „fastcgi_param“ ein Array-Typ ist. Die innere Schicht ersetzt die äußere Schicht. Der Unterschied zur gewöhnlichen Anweisung besteht darin, dass sie bei mehrfacher Verwendung auf derselben Ebene hinzugefügt wird ersetzt. Mit anderen Worten: Wenn „SCRIPT_FILENAME“ zweimal auf derselben Ebene definiert ist, werden beide an das Backend gesendet, was zu potenziellen Problemen führen kann. Um solche Situationen zu vermeiden, wurde eine neue Konfigurationsdatei eingeführt.
Darüber hinaus müssen wir auch ein Sicherheitsproblem berücksichtigen: Wenn PHP „cgi.fix_pathinfo“ aktiviert, analysiert PHP möglicherweise den falschen Dateityp als PHP-Datei. Wenn Nginx und PHP auf demselben Server installiert sind, besteht die einfachste Lösung darin, den Befehl „try_files“ zum Filtern zu verwenden:
try_files $uri =404;
Verbesserte Version
Folgen Sie der vorherigen Analyse und geben Sie eine verbesserte Version an Ist es viel sauberer als die Originalversion? Das Obige ist der gesamte Inhalt dieses Artikels. Ich hoffe auch, dass jeder das Skript unterstützt.