TOC

Compréhension des algorithmes de sélection de blocs d’emplacement et de serveur Nginx

introduction

Nginx est l’un des serveurs Web les plus populaires au monde. Il peut gérer avec succès des charges élevées avec de nombreuses connexions client simultanées et peut facilement fonctionner en tant que serveur Web, serveur de messagerie ou serveur proxy inversé.

Dans ce guide, nous aborderons certains des détails de l’arrière-plan qui déterminent la manière dont Nginx traite les demandes des clients. Comprendre ces idées peut aider à simplifier la conception des blocs de serveur et d’emplacement et à rendre le traitement des demandes moins imprévisible.

Configurations de blocs Nginx

Nginx divise logiquement les configurations destinées à servir un contenu différent en blocs, qui vivent dans une structure hiérarchique. Chaque fois qu’une demande client est faite, Nginx commence un processus de détermination des blocs de configuration à utiliser pour traiter la demande. Ce processus de décision est ce que nous allons discuter dans ce guide.

Les principaux blocs dont nous allons parler sont le bloc * server * et le bloc * location *.

Un bloc de serveur est un sous-ensemble de la configuration de Nginx qui définit un serveur virtuel utilisé pour gérer les requêtes d’un type défini. Les administrateurs configurent souvent plusieurs blocs de serveur et décident quel bloc doit gérer quelle connexion en fonction du nom de domaine demandé, du port et de l’adresse IP demandés.

Un bloc d’emplacement réside dans un bloc de serveur et sert à définir la manière dont Nginx doit gérer les demandes de ressources et d’URI différents pour le serveur parent. L’espace URI peut être subdivisé de la manière que l’administrateur préfère utiliser avec ces blocs. C’est un modèle extrêmement flexible.

Comment Nginx décide quel bloc de serveur traitera une demande

Étant donné que Nginx permet à l’administrateur de définir plusieurs blocs de serveur fonctionnant comme des instances de serveur Web virtuel distinctes, une procédure permettant de déterminer lequel de ces blocs de serveur sera utilisé pour répondre à une demande est nécessaire.

Pour ce faire, il utilise un système de contrôles défini utilisé pour trouver la meilleure correspondance possible. Les directives de bloc du serveur principal qui concernent Nginx au cours de ce processus sont la directive + listen + et la directive + nom_serveur +.

Analyser la directive «écouter» pour trouver les correspondances possibles

Tout d’abord, Nginx examine l’adresse IP et le port de la demande. Cela correspond à la directive + listen + de chaque serveur pour créer une liste des blocs de serveur pouvant éventuellement résoudre la demande.

La directive + listen + définit généralement l’adresse IP et le port auxquels le bloc serveur répondra. Par défaut, tout bloc serveur n’incluant pas de directive + listen + se voit attribuer les paramètres d’écoute +0.0.0.0: 80 + (ou +0.0.0.0: 8080 + si Nginx est exécuté par une commande normale. , utilisateur non root). Cela permet à ces blocs de répondre aux requêtes sur n’importe quelle interface du port 80, mais cette valeur par défaut n’a pas beaucoup de poids dans le processus de sélection du serveur.

La directive + listen + peut être définie sur:

  • Un combo adresse IP / port.

  • Une adresse IP unique qui sera ensuite écoutée sur le port 80 par défaut.

  • Un seul port qui écoutera toutes les interfaces de ce port.

  • Le chemin d’accès à un socket Unix.

La dernière option n’aura généralement d’incidences que lors du transfert de demandes entre différents serveurs.

Lors de la tentative de détermination du bloc serveur auquel envoyer une demande, Nginx essaiera d’abord de décider en fonction de la spécificité de la directive + listen + en utilisant les règles suivantes:

  • Nginx traduit toutes les directives «incomplètes» + listen + en substituant les valeurs manquantes à leurs valeurs par défaut afin que chaque bloc puisse être évalué par son adresse IP et son port. Quelques exemples de ces traductions sont:

  • Un bloc sans directive + listen + utilise la valeur +0.0.0.0: 80 +.

  • Un bloc défini avec une adresse IP + 111.111.111.111 + sans port devient +111.111.111.111: 80 +

  • Un bloc défini sur le port + 8888 + sans adresse IP devient +0.0.0.0: 8888 +

  • Nginx tente ensuite de collecter une liste des blocs de serveur correspondant à la requête, en fonction de l’adresse IP et du port. Cela signifie que tout bloc utilisant de manière fonctionnelle + 0.0.0.0 + comme adresse IP (pour correspondre à n’importe quelle interface) ne sera pas sélectionné s’il existe des blocs correspondants répertoriant une adresse IP spécifique. Dans tous les cas, le port doit correspondre exactement.

  • S’il n’y a qu’une seule correspondance la plus spécifique, ce bloc de serveur sera utilisé pour servir la demande. S’il existe plusieurs blocs de serveur avec le même niveau de correspondance de spécificité, Nginx commence alors à évaluer la directive + nom_serveur + de chaque bloc de serveur.

Il est important de comprendre que Nginx n’évalue la directive + nom_serveur + lorsqu’il doit faire la distinction entre les blocs serveur correspondant au même niveau de spécificité dans la directive + listen +. Par exemple, si + exemple.com + est hébergé sur le port + 80 + de + 192.168.1.10 +, une demande de + exemple.com + sera toujours servie par le premier bloc de cet exemple, malgré la directive + nom_serveur + dans le deuxième bloc.

server {
   listen 192.168.1.10;

   . . .

}

server {
   listen 80;
   server_name example.com;

   . . .

}

Si plusieurs blocs de serveur correspondent avec une spécificité égale, l’étape suivante consiste à vérifier la directive + nom_serveur +.

Analyser la directive «nom_serveur» pour choisir une correspondance

Ensuite, pour évaluer plus en détail les demandes ayant des directives `+ listen + 'également spécifiques, Nginx vérifie l’en-tête« Host »de la demande. Cette valeur contient le domaine ou l’adresse IP que le client essayait réellement d’atteindre.

Nginx tente de trouver la meilleure correspondance pour la valeur trouvée en examinant la directive + nom_serveur + au sein de chacun des blocs de serveur toujours candidats à la sélection. Nginx les évalue en utilisant la formule suivante:

  • Nginx essaiera d’abord de trouver un bloc de serveur avec un + nom_serveur + correspondant à la valeur indiquée dans l’en-tête “Host” de la requête exactly. Si cela est trouvé, le bloc associé sera utilisé pour servir la demande. Si plusieurs correspondances exactes sont trouvées, le * premier * est utilisé.

  • Si aucune correspondance exacte n’est trouvée, Nginx essaiera ensuite de trouver un bloc de serveur avec un + nom_serveur + correspondant à l’aide d’un caractère générique de tête (indiqué par un + * + au début du nom dans la configuration). Si un est trouvé, ce bloc sera utilisé pour servir la demande. Si plusieurs correspondances sont trouvées, la * plus longue * correspondance sera utilisée pour répondre à la demande.

  • Si aucune correspondance n’est trouvée à l’aide d’un caractère générique de premier plan, Nginx recherche alors un bloc de serveur avec un + nom_serveur + correspondant à l’aide d’un caractère générique de fin (indiqué par un nom de serveur se terminant par un + * + dans la configuration). S’il en trouve un, ce bloc est utilisé pour servir la demande. Si plusieurs correspondances sont trouvées, la * plus longue * correspondance sera utilisée pour répondre à la demande.

  • Si aucune correspondance n’est trouvée à l’aide d’un caractère générique de fin, Nginx évalue ensuite les blocs de serveur qui définissent le + nom_serveur + à l’aide d’expressions régulières (indiquées par un + ~ + avant le nom). Le * first * + nom_serveur + avec une expression régulière correspondant à l’en-tête "Host" sera utilisé pour répondre à la demande.

  • Si aucune expression régulière ne correspond, Nginx sélectionne ensuite le bloc de serveur par défaut pour cette adresse IP et ce port.

Chaque combinaison adresse IP / port comporte un bloc serveur par défaut qui sera utilisé lorsqu’un plan d’action ne peut pas être déterminé avec les méthodes ci-dessus. Pour un combo adresse IP / port, il s’agira du premier bloc de la configuration ou du bloc contenant l’option + default_server + dans le cadre de la directive + listen + (qui remplacerait l’algorithme trouvé en premier). Il ne peut y avoir qu’une seule déclaration + default_server + par combinaison d’adresse IP / port.

Exemples

S’il existe un + nom_serveur + défini qui correspond exactement à la valeur de l’en-tête “Host”, ce bloc de serveur est sélectionné pour traiter la demande.

Dans cet exemple, si l’en-tête «Host» de la demande était défini sur «host1.example.com», le deuxième serveur serait sélectionné:

server {
   listen 80;
   server_name *.example.com;

   . . .

}

server {
   listen 80;
   server_name host1.example.com;

   . . .

}

Si aucune correspondance exacte n’est trouvée, Nginx vérifie ensuite s’il existe un + nom_serveur + avec un caractère générique de départ qui convient. La correspondance la plus longue commençant par un caractère générique sera sélectionnée pour répondre à la demande.

Dans cet exemple, si la requête avait un en-tête “Host” de “http://www.example.org [www.example.org]”, le deuxième bloc de serveur serait sélectionné:

server {
   listen 80;
   server_name www.example.*;

   . . .

}

server {
   listen 80;
   server_name *.example.org;

   . . .

}

server {
   listen 80;
   server_name *.org;

   . . .

}

Si aucune correspondance n’est trouvée avec un caractère générique de départ, Nginx verra s’il existe une correspondance utilisant un caractère générique à la fin de l’expression. À ce stade, la correspondance la plus longue se terminant par un caractère générique sera sélectionnée pour répondre à la demande.

Par exemple, si l’en-tête «Host» de la demande est défini sur «http://www.example.com [www.example.com]», le troisième bloc de serveur sera sélectionné:

server {
   listen 80;
   server_name host1.example.com;

   . . .

}

server {
   listen 80;
   server_name example.com;

   . . .

}

server {
   listen 80;
   server_name www.example.*;

   . . .

}

Si aucun caractère générique ne peut être trouvé, Nginx tentera ensuite de faire correspondre les directives + nom_serveur + qui utilisent des expressions régulières. L’expression régulière correspondante first sera sélectionnée pour répondre à la demande.

Par exemple, si l’en-tête «Host» de la demande est défini sur «http://www.example.com [www.example.com]», le deuxième bloc de serveur sera sélectionné pour satisfaire la demande:

server {
   listen 80;
   server_name example.com;

   . . .

}

server {
   listen 80;
   server_name ~^(www|host1).*\.example\.com$;

   . . .

}

server {
   listen 80;
   server_name ~^(subdomain|set|www|host1).*\.example\.com$;

   . . .

}

Si aucune des étapes ci-dessus ne permet de satisfaire la demande, celle-ci sera transmise au serveur default pour l’adresse IP et le port correspondants.

Correspondance des blocs d’emplacement

Semblable au processus utilisé par Nginx pour sélectionner le bloc de serveur qui traitera une demande, Nginx dispose également d’un algorithme établi pour décider du bloc d’emplacement du serveur à utiliser pour le traitement des demandes.

Syntaxe de blocage d’emplacement

Avant de couvrir la façon dont Nginx décide quel bloc d’emplacement utiliser pour traiter les demandes, voyons quelques-unes de la syntaxe que vous pourriez voir dans les définitions de bloc d’emplacement. Les blocs d’emplacement résident dans des blocs de serveur (ou d’autres blocs d’emplacement) et sont utilisés pour décider comment traiter l’URI de la demande (la partie de la demande qui suit le nom de domaine ou l’adresse IP / le port).

Les blocs d’emplacement prennent généralement la forme suivante:

location   {

   . . .

}

Le ++ ci-dessus définit ce sur quoi Nginx doit vérifier l’URI de la demande. L’existence ou la non-existence du modificateur dans l’exemple ci-dessus affecte la façon dont Nginx tente de faire correspondre le bloc d’emplacement. Les modificateurs ci-dessous entraîneront l’interprétation du bloc d’emplacement associé:

  • * (aucun) *: Si aucun modificateur n’est présent, l’emplacement est interprété comme une correspondance prefix. Cela signifie que l’emplacement indiqué sera mis en correspondance avec le début de l’URI de la demande pour déterminer une correspondance.

  • * + = + *: Si un signe égal est utilisé, ce bloc sera considéré comme une correspondance si l’URI de la demande correspond exactement à l’emplacement indiqué.

  • * + ~ + *: Si un modificateur de tilde est présent, cet emplacement sera interprété comme une correspondance d’expression régulière sensible à la casse.

  • * + ~ * + *: Si un modificateur de tilde et d’astérisque est utilisé, le bloc d’emplacement sera interprété comme une correspondance d’expression régulière insensible à la casse.

  • * + ^ ~ + *: Si un modificateur carat et tilde est présent, et si ce bloc est sélectionné comme meilleure correspondance d’expression non régulière, la correspondance d’expression régulière n’aura pas lieu.

Exemples illustrant la syntaxe de bloc d’emplacement

Comme exemple de correspondance de préfixe, le bloc d’emplacement suivant peut être sélectionné pour répondre à des URI de demande ressemblant à + ​​/ site +, + / site / page1 / index.html + ou + / site / index.html + :

location /site {

   . . .

}

Pour une démonstration de correspondance exacte d’URI de requête, ce bloc sera toujours utilisé pour répondre à une adresse URI de requête ressemblant à + ​​/ page1 +. Il ne sera * pas * utilisé pour répondre à un URI de requête + / page 1 / index.html. Gardez à l’esprit que si ce bloc est sélectionné et que la demande est remplie à l’aide d’une page d’index, une redirection interne aura lieu vers un autre emplacement qui sera le gestionnaire actuel de la demande:

location = /page1 {

   . . .

}

À titre d’exemple d’emplacement qui doit être interprété comme une expression régulière sensible à la casse, ce bloc peut être utilisé pour gérer les demandes de + / tortoise.jpg +, mais pas * pour * + / FLOWER.PNG + `:

location ~ \.(jpe?g|png|gif|ico)$ {

   . . .

}

Un bloc qui permettrait une correspondance insensible à la casse similaire à celle ci-dessus est présenté ci-dessous. Ici, les deux + / tortoise.jpg + et + / FLOWER.PNG + peuvent être gérés par ce bloc:

location ~* \.(jpe?g|png|gif|ico)$ {

   . . .

}

Enfin, ce bloc empêcherait la correspondance des expressions rationnelles s’il est déterminé qu’il s’agit de la meilleure correspondance d’expression non régulière. Il pourrait gérer les demandes de + / costumes / ninja.html:

location ^~ /costumes {

   . . .

}

Comme vous le voyez, les modificateurs indiquent comment le bloc d’emplacement doit être interprété. Cependant, cela ne nous indique pas l’algorithme utilisé par Nginx pour décider du bloc d’emplacement auquel envoyer la demande. Nous allons passer à cela plus tard.

Comment Nginx choisit quel emplacement utiliser pour traiter les demandes

Nginx choisit l’emplacement qui sera utilisé pour répondre à une demande de la même manière que pour sélectionner un bloc de serveur. Il exécute un processus qui détermine le meilleur bloc d’emplacement pour une demande donnée. Comprendre ce processus est essentiel pour pouvoir configurer Nginx de manière fiable et précise.

En gardant à l’esprit les types de déclaration d’emplacement décrits ci-dessus, Nginx évalue les contextes d’emplacement possibles en comparant l’URI de la demande à chacun des emplacements. Pour ce faire, il utilise l’algorithme suivant:

  • Nginx commence par vérifier toutes les correspondances d’emplacement basées sur un préfixe (tous les types d’emplacement ne comportant pas d’expression régulière). Il vérifie chaque emplacement par rapport à l’URI de la demande complète.

  • Tout d’abord, Nginx cherche une correspondance exacte. Si un bloc d’emplacement utilisant le modificateur + = + est trouvé pour correspondre exactement à l’URI de la demande, ce bloc d’emplacement est immédiatement sélectionné pour servir la demande.

  • Si aucune correspondance de bloc d’emplacement exacte (avec le modificateur + = +) n’est trouvée, Nginx passe ensuite à l’évaluation des préfixes non exacts. Il découvre l’emplacement du préfixe correspondant le plus long pour l’URI de la demande donnée, qu’il évalue ensuite comme suit:

  • Si l’emplacement du préfixe correspondant le plus long comporte le modificateur + ^ ~ +, Nginx met immédiatement fin à sa recherche et sélectionne cet emplacement pour répondre à la demande.

  • Si le plus long emplacement de préfixe correspondant n’utilise pas le modificateur + ^ ~ +, la correspondance est mémorisée par Nginx pour le moment afin que le focus de la recherche puisse être déplacé.

  • Une fois que l’emplacement du préfixe correspondant le plus long est déterminé et stocké, Nginx passe à l’évaluation des emplacements des expressions régulières (sensibles à la casse et insensibles). S’il existe des emplacements d’expressions régulières dans le plus long emplacement de préfixe correspondant, Nginx les déplacera en haut de la liste d’emplacements d’expressions régulières à vérifier. Nginx tente ensuite de faire correspondre les emplacements des expressions régulières de manière séquentielle. Le * premier * emplacement de l’expression régulière correspondant à l’URI de la demande est immédiatement sélectionné pour répondre à la demande.

  • Si aucun emplacement d’expression régulière correspondant à l’URI de la demande n’est trouvé, l’emplacement de préfixe précédemment stocké est sélectionné pour répondre à la demande.

Il est important de comprendre que, par défaut, Nginx servira les correspondances d’expressions régulières de préférence aux correspondances de préfixes. Cependant, il évalue d’abord les emplacements de préfixe, permettant ainsi à l’administration de remplacer cette tendance en spécifiant des emplacements à l’aide des modificateurs + = + et + ^ ~ +.

Il est également important de noter que, bien que les emplacements de préfixes soient généralement sélectionnés en fonction de la correspondance la plus longue et la plus spécifique, l’évaluation des expressions régulières est arrêtée lorsque le premier emplacement correspondant est trouvé. Cela signifie que le positionnement dans la configuration a de vastes implications pour les emplacements d’expressions régulières.

Enfin, il est important de comprendre que l’expression régulière correspond à within, la correspondance du préfixe le plus long "sautera la ligne" lorsque Nginx évaluera les emplacements des expressions rationnelles. Celles-ci seront évaluées, dans l’ordre, avant toute autre correspondance d’expressions régulières. Maxim Dounin, un développeur Nginx incroyablement utile, explique dans his post cette partie de l’algorithme de sélection.

Quand l’évaluation de blocage d’emplacement est-elle renvoyée vers d’autres emplacements?

De manière générale, lorsqu’un bloc d’emplacement est sélectionné pour servir une demande, la demande est entièrement traitée dans ce contexte à partir de ce point. Seuls l’emplacement sélectionné et les directives héritées déterminent le mode de traitement de la demande, sans interférence de blocs d’emplacement frères.

Bien qu’il s’agisse d’une règle générale qui vous permettra de concevoir vos blocs d’emplacement de manière prévisible, il est important de comprendre qu’il peut arriver qu’une nouvelle recherche d’emplacement soit déclenchée par certaines directives de l’emplacement sélectionné. Les exceptions à la règle «un seul bloc d’emplacement» peuvent avoir des conséquences sur la façon dont la demande est effectivement traitée et peuvent ne pas correspondre aux attentes que vous aviez lors de la conception de vos blocs d’emplacement.

Certaines directives pouvant mener à ce type de redirection interne sont les suivantes:

  • indice

  • * try_files *

  • récrire

  • * error_page *

Examinons-les brièvement.

La directive + index + conduit toujours à une redirection interne si elle est utilisée pour gérer la requête. Les correspondances exactes d’emplacement sont souvent utilisées pour accélérer le processus de sélection en mettant immédiatement fin à l’exécution de l’algorithme. Toutefois, si vous faites une correspondance exacte avec l’emplacement directory, il y a de bonnes chances que la demande soit redirigée vers un autre emplacement pour le traitement réel.

Dans cet exemple, le premier emplacement correspond à un URI de requête + / exact +, mais pour gérer la requête, la directive + index + héritée du bloc initie une redirection interne vers le second bloc:

index index.html;

location = /exact {

   . . .

}

location / {

   . . .

}

Dans le cas ci-dessus, si vous avez vraiment besoin que l’exécution reste dans le premier bloc, vous devrez trouver une méthode différente pour satisfaire la requête dans le répertoire. Par exemple, vous pouvez définir un + index non valide pour ce bloc et activer` + autoindex`:

location = /exact {
   index nothing_will_match;
   autoindex on;
}

location  / {

   . . .

}

C’est un moyen d’empêcher un + index + de changer de contexte, mais cela n’est probablement pas utile pour la plupart des configurations. Généralement, une correspondance exacte sur les annuaires peut être utile pour des tâches telles que la réécriture de la demande (ce qui entraîne également une nouvelle recherche d’emplacement).

Un autre cas où l’emplacement de traitement peut être réévalué est la directive + try_files +. Cette directive indique à Nginx de vérifier l’existence d’un ensemble nommé de fichiers ou de répertoires. Le dernier paramètre peut être un URI vers lequel Nginx effectuera une redirection interne.

Considérez la configuration suivante:

root /var/www/main;
location / {
   try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
   root /var/www/another;
}

Dans l’exemple ci-dessus, si une demande est faite pour + / blahblah +, le premier emplacement obtiendra initialement la demande. Il essaiera de trouver un fichier nommé + blahblah + dans le répertoire + / var / www / main +. S’il ne parvient pas à en trouver un, il recherchera ensuite un fichier nommé + blahblah.html +. Il essaiera ensuite de voir s’il existe un répertoire appelé + blahblah / + dans le répertoire + / var / www / main +. À défaut de toutes ces tentatives, il sera redirigé vers + / fallback / index.html. Cela déclenchera une autre recherche d’emplacement qui sera interceptée par le deuxième bloc d’emplacement. Cela servira le fichier + / var / www / another / fallback / index.html.

La directive + rewrite + est une autre directive pouvant conduire à la suppression d’un bloc d’emplacement. Lors de l’utilisation du paramètre + last + avec la directive + rewrite + ou en l’absence de paramètre, Nginx recherchera un nouvel emplacement correspondant en fonction des résultats de la réécriture.

Par exemple, si nous modifions le dernier exemple pour inclure une réécriture, nous pouvons voir que la demande est parfois passée directement au deuxième emplacement sans s’appuyer sur la directive + try_files +:

root /var/www/main;
location / {
   rewrite ^/rewriteme/(.*)$ /$1 last;
   try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
   root /var/www/another;
}

Dans l’exemple ci-dessus, une demande de + / rewriteme / hello + sera traitée initialement par le premier bloc d’emplacement. Il sera réécrit en + / hello + et une localisation sera recherchée. Dans ce cas, il correspondra à nouveau au premier emplacement et sera traité par le + try_files + comme d’habitude, retournant peut-être à + ​​/ fallback / index.html + si rien n’est trouvé (en utilisant la redirection interne + try_files + discuté ci-dessus).

Cependant, si une demande est faite pour + / rewriteme / fallback / hello +, le premier bloc correspondra à nouveau. La réécriture sera appliquée à nouveau, cette fois, ce qui donnera + / fallback / hello +. La demande sera alors traitée en dehors du deuxième bloc d’emplacement.

Une situation connexe se produit avec la directive + return + lors de l’envoi des codes d’état + 301 + ou + 302 +. La différence dans ce cas est qu’il en résulte une demande entièrement nouvelle sous la forme d’une redirection visible de l’extérieur. Cette même situation peut se produire avec la directive + rewrite + lorsque vous utilisez les indicateurs + redirect + ou + permanent +. Cependant, ces recherches d’emplacement ne doivent pas être inattendues, car les redirections visibles de l’extérieur donnent toujours lieu à une nouvelle demande.

La directive + error_page + peut conduire à une redirection interne similaire à celle créée par + try_files +. Cette directive est utilisée pour définir ce qui doit se passer lorsque certains codes d’état sont rencontrés. Cela ne sera probablement jamais exécuté si + try_files + est défini, car cette directive gère le cycle de vie complet d’une requête.

Considérons cet exemple:

root /var/www/main;

location / {
   error_page 404 /another/whoops.html;
}

location /another {
   root /var/www;
}

Chaque demande (autre que celles commençant par + / another +) sera traitée par le premier bloc, qui servira les fichiers en dehors de + / var / www / main +. Cependant, si un fichier n’est pas trouvé (statut 404), une redirection interne vers + / another / whoops.html + se produira, ce qui conduira à une nouvelle recherche d’emplacement qui aboutira éventuellement sur le deuxième bloc. Ce fichier sera servi à partir de + / var / www / another / whoops.html.

Comme vous pouvez le constater, comprendre les circonstances dans lesquelles Nginx déclenche une nouvelle recherche d’emplacement peut aider à prévoir le comportement que vous verrez lors de la création de demandes.

Conclusion

Comprendre les méthodes de traitement des demandes des clients par Nginx peut vous faciliter la tâche en tant qu’administrateur. Vous serez en mesure de savoir quel bloc de serveur Nginx sélectionnera en fonction de chaque demande du client. Vous pourrez également savoir comment le bloc d’emplacement sera sélectionné en fonction de l’URI de la demande. De manière générale, connaître la façon dont Nginx sélectionne différents blocs vous donnera la possibilité de tracer les contextes que Nginx appliquera afin de répondre à chaque demande.

Related