Comment configurer correctement Nginx + PHP

Pour de nombreuses personnes, configurer Nginx+PHP n'est rien d'autre que rechercher un tutoriel puis le copier-coller. Il semble qu'il n'y ait rien de mal à cela, mais en fait, de nombreuses informations sur Internet sont délabrées et pleines de lacunes. Si vous vous contentez de copier et coller sans demander une compréhension plus approfondie, vous en paierez le prix tôt ou tard. .

Supposons que nous utilisions PHP pour implémenter un contrôleur frontal, ou pour parler franchement, une entrée unifiée : envoyez toutes les requêtes PHP vers le même fichier, puis implémentez le routage en analysant "REQUEST_URI" dans ce fichier.

Configurez-le généralement comme ceci
À l'heure actuelle, de nombreux tutoriels vous apprendront à configurer Nginx+PHP comme ceci :

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;
  }
}

Il y a beaucoup d'erreurs dans cela, ou du moins, il a un mauvais goût. Jetez un œil et voyez combien vous pouvez en trouver.
Nous devons d'abord comprendre la relation d'héritage des instructions dans le fichier de configuration Nginx :
Le fichier de configuration Nginx est divisé en plusieurs blocs. Les plus courants de l'extérieur vers l'intérieur sont "http", "server", ". location", etc. , la relation d'héritage par défaut est de l'extérieur vers l'intérieur, ce qui signifie que le bloc interne obtiendra automatiquement la valeur du bloc externe comme valeur par défaut.

Commençons par la directive "index"
Dans la configuration du problème, elle est définie dans "location" :

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

Une fois que de nouvelles données doivent être ajoutées dans le "emplacement" futur, il y aura inévitablement des instructions "index" définies à plusieurs reprises. En effet, plusieurs "emplacements" sont dans une relation horizontale et il n'y a pas d'héritage à ce stade, "index" doit être défini dans "serveur" avec le. à l'aide de la relation d'héritage, la commande "index" peut prendre effet dans tous les "emplacements".

Jetons un coup d'œil à la commande "if"
Il n'est pas exagéré de dire que c'est la commande Nginx la plus mal comprise :

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

Beaucoup de gens aiment use "if" La commande effectue une série de vérifications, mais c'est en fait la responsabilité de la commande "try_files" :
try_files $uri $uri/ /index.php
De plus, les débutants pensent souvent que le La commande "if" est constituée d'instructions au niveau du noyau, mais en fait elle fait partie du module de réécriture. De plus, la configuration de Nginx est en fait déclarative plutôt que procédurale, donc lorsqu'elle est mélangée à des instructions provenant de modules non réécrits, le résultat peut ne pas être obtenu. soyez ce que vous voulez.

Jetons un coup d'œil au fichier de configuration "fastcgi_params"
inclut fastcgi_params
Nginx a deux fichiers de configuration fastcgi, à savoir "fastcgi_params" et "fastcgi.conf", ils ne le sont pas. trop gros La seule différence est que ce dernier a une ligne de définition "SCRIPT_FILENAME" de plus que le premier :
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
Remarque : il n'y a pas de / entre $document_root et $fastcgi_script_name;
À l'origine, Nginx n'avait que "fastcgi_params". Plus tard, on a découvert que de nombreuses personnes utilisaient le codage en dur pour définir "SCRIPT_FILENAME", donc "fastcgi.conf" a été introduit pour standardiser l'utilisation.
Cependant, cela soulève une question : pourquoi faut-il introduire un nouveau fichier de configuration au lieu de modifier l'ancien fichier de configuration ? En effet, l'instruction "fastcgi_param" est de type tableau. Identique à l'instruction ordinaire : la couche interne remplace la couche externe. La différence avec l'instruction ordinaire est que lorsqu'elle est utilisée plusieurs fois au même niveau, elle est ajoutée à la place. remplacé. En d'autres termes, si "SCRIPT_FILENAME" est défini deux fois au même niveau, ils seront tous deux envoyés au backend, ce qui peut entraîner des problèmes potentiels. Afin d'éviter de telles situations, un nouveau fichier de configuration a été introduit.
De plus, nous devons également prendre en compte un problème de sécurité : lorsque PHP active "cgi.fix_pathinfo", PHP peut analyser le mauvais type de fichier en tant que fichier PHP. Si Nginx et PHP sont installés sur le même serveur, la solution la plus simple est d'utiliser la commande "try_files" pour filtrer :
try_files $uri =404;
Version améliorée
Suivez l'analyse précédente et donnez une version améliorée version. Est-elle beaucoup plus propre que la version originale :

server {
  listen 80;
  server_name foo.com;
 
  root /path;
  index index.html index.htm index.php;
 
  location / {
    try_files $uri $uri/ /index.php$is_args$args;
  }
 
  location ~ /.php$ {
    try_files $uri =404;
 
    include fastcgi.conf;
    fastcgi_pass 127.0.0.1:9000;
  }
}

Ce qui précède est l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'étude de chacun. J'espère également que tout le monde en apprendra davantage. Accueil des scripts.