Comment configurer correctement Nginx + PHP

Cet article présente principalement les étapes de configuration de Nginx + PHP en détail, et comprend le tutoriel simple de configuration de Nginx + PHP. Les amis intéressés peuvent s'y référer

Pour beaucoup de gens, la configuration Nginx + PHP n'est rien. plus que rechercher un didacticiel, puis le copier et le coller. Il semble qu’il n’y ait rien de mal à cela, mais en réalité, de nombreuses informations sur Internet sont délabrées et pleines de failles. Si vous vous contentez de copier et coller sans chercher à mieux comprendre, 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, qu'il s'agisse d'une entrée unifiée : envoyez toutes les requêtes PHP vers le même fichier, puis dans ce fichier, le routage est implémenté en analysant "REQUEST_URI".

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, ou du moins de mauvais goût, jetez un œil et vous pourrez en trouver quelques-unes.
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 qu'un nouvel « emplacement » devra être ajouté à l'avenir, il y aura inévitablement des instructions « d'index » définies à plusieurs reprises. En effet, plusieurs « emplacements » sont dans une relation horizontale. , il n'y a pas d'héritage pour le moment, "index" doit être défini dans "server". Avec 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 utiliser la commande "if" pour effectuer 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 l'instruction "if" est une instruction au niveau du noyau, mais en fait elle fait partie du module de réécriture, et la configuration Nginx est en fait une déclaration. Elle est formelle et non procédurale, donc lorsqu'elle est mélangée à des instructions provenant de modules non réécrits, les résultats peuvent ne pas être ceux que vous souhaitez.

Jetons un coup d'œil au fichier de configuration "fastcgi_params"
incluez fastcgi_params
Nginx a deux fichiers de configuration fastcgi, à savoir " fastcgi_params" " et "fastcgi.conf", il n'y a pas beaucoup de différence entre eux. La seule différence est que ce dernier a une ligne de définition de "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
Basée sur l'analyse précédente, voici une version améliorée. 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;
  }
}

Recommandations associées :

nginx ne peut pas analyser le script php

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!