فهم خوارزميات اختيار خادم Nginx وكتلة الموقع

المقدمة

إن Nginx هو واحد من أشهر خوادم الويب في العالم. يمكنه التعامل بنجاح مع أعباء عالية مع العديد من الاتصالات العميل المتزامنة، ويمكن أن يعمل كخادم ويب أو كخادم بريد أو كخادم بروكسي عكسي.

في هذا الدليل، سنناقش بعض التفاصيل الخلفية التي تحدد كيفية معالجة Nginx لطلبات العملاء. فهم هذه الأفكار يمكن أن يساعد في إزالة التخمين من تصميم كتل الخادم والموقع ويمكن أن يجعل معالجة الطلب تبدو أقل تكهنًا.

تكوينات كتل Nginx

يقسم Nginx بشكل منطقي التكوينات المخصصة لخدمة محتوى مختلف إلى كتل، التي تعيش في هيكل هرمي. في كل مرة يتم فيها إجراء طلب عميل، يبدأ Nginx في عملية تحديد أي كتل التكوين يجب استخدامها لمعالجة الطلب. هذه العملية هي ما سنناقشه في هذا الدليل.

الكتل الرئيسية التي سنناقشها هي كتلة server وكتلة location.

A server block is a subset of Nginx’s configuration that defines a virtual server used to handle requests of a defined type. Administrators often configure multiple server blocks and decide which block should handle which connection based on the requested domain name, port, and IP address.

A location block lives within a server block and is used to define how Nginx should handle requests for different resources and URIs for the parent server. The URI space can be subdivided in whatever way the administrator likes using these blocks. It is an extremely flexible model.

كيف تقرر Nginx أي كتلة خادم ستتعامل مع الطلب

نظرًا لأن Nginx يسمح للمسؤول بتعريف عدة كتل خادم تعمل كمثيلات منفصلة لخوادم الويب الافتراضية، فإنه يحتاج إلى إجراء لتحديد أي من هذه الكتل الخادم سيتم استخدامها لتلبية الطلب.

يفعل ذلك من خلال نظام محدد من الفحوصات تُستخدم للعثور على أفضل تطابق ممكن. توجيهات كتلة الخادم الرئيسية التي يهتم بها Nginx خلال هذه العملية هي التوجيه الـ listen وتوجيه الـ server_name.

تحليل التوجيه listen للعثور على التطابقات المحتملة

أولاً، ينظر Nginx إلى عنوان IP ومنفذ الطلب. يُطابق ذلك مع التوجيه listen لكل خادم لبناء قائمة من كتل الخوادم التي يمكن أن تُحل الطلب على الأرجح.

توجيه الاستماع يحدد عادة العنوان IP والمنفذ الذي سيستجيب إليه كتلة الخادم. بشكل افتراضي، يُعطى أي كتلة خادم لا تتضمن توجيه الاستماع معلمات الاستماع 0.0.0.0:80 (أو 0.0.0.0:8080 إذا كانت Nginx يتم تشغيلها بواسطة مستخدم عادي، غير مستخدم root). يتيح هذا لهذه الكتل الاستجابة للطلبات على أي واجهة على المنفذ 80، ولكن هذه القيمة الافتراضية لا تحمل الكثير من الوزن ضمن عملية اختيار الخادم.

يمكن تعيين توجيه الاستماع إلى:

• مجموعة عنوان IP/منفذ.
• A lone IP address which will then listen on the default port 80.
• A lone port which will listen to every interface on that port.
• المسار إلى مأخذ Unix.

الخيار الأخير عادةً ما يكون له تأثير عند تمرير الطلبات بين خوادم مختلفة.

عند محاولة تحديد أي كتلة خادم يتم إرسال الطلب إليها، سيحاول Nginx في البداية القرار استنادًا إلى تخصيصية توجيه الاستماع باستخدام القواعد التالية:

• يقوم Nginx بترجمة جميع التوجيهات الاستماع “غير المكتملة” عن طريق استبدال القيم المفقودة بقيمها الافتراضية بحيث يمكن تقييم كل كتلة بواسطة عنوانها IP ومنفذها. بعض أمثلة هذه الترجمات هي:
  • تستخدم كتلة بدون توجيه الاستماع القيمة 0.0.0.0:80.
  • تصبح كتلة معينة إلى عنوان IP 111.111.111.111 بدون منفذ 111.111.111.111:80
  • تصبح كتلة معينة إلى منفذ 8888 بدون عنوان IP 0.0.0.0:8888
• ثم يحاول Nginx جمع قائمة من كتل الخوادم التي تتطابق مع الطلب بشكل أكثر تحديدًا استنادًا إلى عنوان IP والمنفذ. وهذا يعني أن أي كتلة تستخدم بشكل وظيفي 0.0.0.0 كعنوان IP (للتطابق مع أي واجهة)، لن يتم اختيارها إذا كانت هناك كتل متطابقة تقدم عنوان IP محدد. في أي حال، يجب أن يتم تطابق المنفذ بدقة.
• إذا كان هناك تطابق واحد الأكثر تحديدًا، ستُستخدم تلك الكتلة لخدمة الطلب. إذا كانت هناك عدة كتل للخوادم بنفس مستوى التحديد المتطابق، يبدأ Nginx بعد ذلك في تقييم توجيه server_name لكل كتلة خادم.

من المهم فهم أن Nginx سيقوم بتقييم توجيه server_name فقط عندما يحتاج إلى التمييز بين كتل الخوادم التي تتطابق على نفس مستوى التحديد في التوجيه listen. على سبيل المثال، إذا كان example.com مستضافًا على المنفذ 80 من 192.168.1.10، فإن طلب لـ example.com سيتم خدمته دائمًا بواسطة الكتلة الأولى في هذا المثال، على الرغم من توجيه server_name في الكتلة الثانية.

server {
    listen 192.168.1.10;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

في حالة مطابقة أكثر من كتلة للخادم بنفس مستوى التحديد، يتم التحقق في الخطوة التالية من توجيه server_name.

تحليل توجيه server_name لاختيار التطابق

بعد ذلك، لتقييم الطلبات التي تحتوي على توجيهات listen محددة بنفس الدقة، يقوم Nginx بفحص رأس الطلب Host. تحمل هذه القيمة النطاق أو عنوان الآي بي الذي كان العميل يحاول بالفعل الوصول إليه.

يحاول Nginx العثور على أفضل تطابق للقيمة التي يجدها من خلال النظر إلى التوجيه server_name داخل كل كتلة خادم لا تزال مرشحة للاختيار. يقوم Nginx بتقييم هذه باستخدام الصيغة التالية:

• سيحاول Nginx في البداية العثور على كتلة خادم تحتوي على server_name يتطابق مع القيمة في رأس الطلب Host بالضبط. إذا تم العثور على ذلك، سيتم استخدام الكتلة المرتبطة لخدمة الطلب. إذا تم العثور على عدة تطابقات بالضبط، سيتم استخدام الأولى.
• إذا لم يتم العثور على تطابق بالضبط، سيحاول Nginx بعد ذلك العثور على كتلة خادم تحتوي على server_name يتطابق باستخدام علامة النجمة المؤدية (المشار إليها بـ * في بداية الاسم في التكوين). إذا تم العثور على واحدة، سيتم استخدام تلك الكتلة لخدمة الطلب. إذا تم العثور على عدة تطابقات، سيتم استخدام التطابق الأطول لخدمة الطلب.
• إذا لم يتم العثور على تطابق باستخدام علامة النجمة المؤدية، يبحث Nginx بعد ذلك عن كتلة خادم تحتوي على server_name يتطابق باستخدام علامة النجمة الختامية (المشار إليها بانتهاء اسم الخادم بـ * في التكوين). إذا تم العثور على واحدة، سيتم استخدام تلك الكتلة لخدمة الطلب. إذا تم العثور على عدة تطابقات، سيتم استخدام التطابق الأطول لخدمة الطلب.
• إذا لم يتم العثور على تطابق باستخدام محدد البحث الذي يأتي في نهاية السلسلة، يقوم Nginx بمتابعة تقييم الكتل الخادمة التي تحدد server_name باستخدام التعبيرات العادية (المشار إليها بعلامة ~ قبل الاسم). سيتم استخدام أول server_name يحتوي على تعبير عادي يتطابق مع رأس “Host” لخدمة الطلب.
• إذا لم يتم العثور على تطابق للتعبير العادي، يقوم Nginx بعد ذلك باختيار كتلة الخادم الافتراضية لعنوان IP ومنفذ معين.

يحتوي كل من توصيلة العنوان IP/المنفذ على كتلة خادم افتراضية ستُستخدم عندما لا يمكن تحديد مسار العمل باستخدام الطرق المذكورة أعلاه. بالنسبة لتوصيلة العنوان IP/المنفذ، سيكون هذا إما الكتلة الأولى في التكوين أو الكتلة التي تحتوي على خيار default_server كجزء من التوجيهة listen (والتي ستغلب على خوارزمية البحث عن الكتلة الأولى). يمكن أن يكون هناك محضر default_server واحد فقط لكل توصيلة عنوان IP/منفذ.

أمثلة

إذا كان هناك server_name محدد يتطابق تمامًا مع قيمة رأس Host، يتم تحديد كتلة الخادم هذه لمعالجة الطلب.

في هذا المثال، إذا تم تعيين رأس Host للطلب إلى host1.example.com، سيتم اختيار الخادم الثاني:

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

    . . .

}

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

    . . .

}

إذا لم يتم العثور على تطابق دقيق، يقوم Nginx بالتحقق من وجود server_name ببداية مع النجمة التي تتناسب. سيتم اختيار أطول تطابق يبدأ بنجمة لتلبية الطلب.

في هذا المثال، إذا كان لدى الطلب رأس Host بقيمة www.example.org، سيتم اختيار الكتلة الخادم الثانية:

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

    . . .

}

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

    . . .

}

server {
    listen 80;
    server_name *.org;

    . . .

}

إذا لم يتم العثور على تطابق بداية بنجمة، سيقوم Nginx بالتحقق بعد ذلك مما إذا كان هناك تطابق باستخدام نجمة في نهاية التعبير. في هذه النقطة، سيتم اختيار أطول تطابق ينتهي بنجمة لخدمة الطلب.

على سبيل المثال، إذا كان لدى الطلب رأس Host محددًا بقيمة www.example.com، سيتم اختيار الكتلة الخادم الثالثة:

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

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

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

    . . .

}

إذا لم يتم العثور على تطابقات بنجمة، سيقوم Nginx بالانتقال بعد ذلك لمحاولة مطابقة توجيهات server_name التي تستخدم التعابير العادية. سيتم اختيار أول تطابق يستخدم تعبيرًا عاديًا للرد على الطلب.

على سبيل المثال، إذا كان رأس الطلب Host محددًا بقيمة www.example.com، فستتم اختيار الكتلة الخادم الثانية لتلبية الطلب:

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

    . . .

}

إذا لم تتمكن أي من الخطوات السابقة من تلبية الطلب، سيتم تمرير الطلب إلى الخادم الافتراضي لعنوان IP ومنفذ متطابقين.

تطابق كتل الموقع

مشابهة للعملية التي يستخدمها Nginx لتحديد كتلة الخادم التي ستعالج الطلب، يحتوي Nginx أيضًا على خوارزمية مُنشأة لتحديد أي كتلة موقع داخل الخادم يجب استخدامها لمعالجة الطلب.

بناء كتلة الموقع النحوي

قبل أن نغطي كيف يقرر Nginx أي كتلة موقع يجب استخدامها لمعالجة الطلب، دعنا نستعرض بعض الصيغ التي قد تراها في تعريفات كتل الموقع. تعيش كتل الموقع ضمن كتل الخادم (أو كتل الموقع الأخرى) وتُستخدم لتحديد كيفية معالجة معرف الطلب (الجزء من الطلب الذي يأتي بعد اسم النطاق أو عنوان IP/المنفذ).

تأخذ كتل الموقع عمومًا النموذج التالي:

location optional_modifier location_match {

    . . .

}

الـlocation_match في المثال أعلاه يحدد ما يجب على Nginx التحقق منه في معرف الطلب. يؤثر وجود أو عدم وجود المعدل في المثال أعلاه على الطريقة التي يحاول بها Nginx مطابقة كتلة الموقع. ستؤدي المعدلات أدناه إلى تفسير كتلة الموقع المرتبطة على النحو التالي:

• (لا شيء): إذا لم يكن هناك معدلات موجودة، يُفسر الموقع على أنه مطابقة بادئة. هذا يعني أن الموقع المعطى سيُطابق بداية معرف الطلب لتحديد المطابقة.
• =: إذا استخدمت علامة يساوي، سيتم اعتبار هذه الكتلة مطابقة إذا كان معرف الطلب يُطابق بالضبط الموقع المعطى.
• ~: إذا كانت هناك علامة التيلد، سيتم تفسير هذا الموقع كمطابقة لتعبير منتظم يحترم حالة الأحرف.
• ~*: إذا تم استخدام علامة التيلد مع علامة النجمة، سيتم تفسير كتلة الموقع كمطابقة لتعبير منتظم يحترم حالة الأحرف.
• ^~: إذا كانت هناك علامة السهم والتيلد معًا، وإذا تم اختيار هذه الكتلة كأفضل مطابقة غير متطابقة للتعبير العادي، فلن يتم إجراء مطابقة للتعبير العادي.

أمثلة توضيحية لصيغ كتلة الموقع

كمثال على المطابقة بالبادئة، قد يتم اختيار الكتلة التالية للرد على طلبات URIs التي تبدو مثل /site, /site/page1/index.html, أو /site/index.html:

location /site {

    . . .

}

لتوضيح مطابقة URI الدقيقة، سيتم استخدام هذه الكتلة دائمًا للرد على طلب URI الذي يبدو مثل /page1. لن تستخدم للرد على طلب URI /page1/index.html. خذ في الاعتبار أنه إذا تم اختيار هذه الكتلة وتم تنفيذ الطلب باستخدام صفحة فهرس، ستحدث إعادة توجيه داخلي إلى مكان آخر سيكون هو المعالج الفعلي للطلب:

location = /page1 {

    . . .

}

كمثال على الموقع الذي يجب تفسيره كتعبير منتظم يعتمد على حالة الأحرف، يمكن استخدام هذا الكتلة للتعامل مع الطلبات لـ /tortoise.jpg، ولكن لا لـ /FLOWER.PNG:

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

    . . .

}

A block that would allow for case-insensitive matching similar to the above is shown below. Here, both /tortoise.jpg and /FLOWER.PNG could be handled by this block:

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

    . . .

}

وأخيرًا، ستمنع هذه الكتلة التطابق مع التعبير العادي إذا تم تحديده كأفضل تطابق غير عبارة منتظمة. يمكنها التعامل مع الطلبات لـ /costumes/ninja.html:

location ^~ /costumes {

    . . .

}

كما ترون، تشير المعدلات إلى كيفية تفسير كتلة الموقع. ومع ذلك، فهذا لا يخبرنا عن خوارزمية تقوم Nginx باستخدامها لاتخاذ قرار بإرسال الطلب إلى أي كتلة موقع. سنتناول ذلك بعد ذلك.

كيف يختار Nginx أي موقع يستخدم للتعامل مع الطلبات

يختار Nginx الموقع الذي سيتم استخدامه لخدمة طلب بطريقة مماثلة لكيفية اختياره لكتلة الخادم. يقوم بتشغيل عملية تحدد أفضل كتلة موقع لأي طلب معين. فهم هذه العملية متطلب أساسي لتمكين تكوين Nginx بشكل موثوق ودقيق.

مع الأخذ في الاعتبار أنواع الإعلانات عن الموقع التي وصفناها أعلاه، يقوم Nginx بتقييم السياقات المحتملة للموقع عن طريق مقارنة معرف الطلب بكل من المواقع. يفعل ذلك باستخدام الخوارزمية التالية:

• تبدأ Nginx بفحص جميع التطابقات القائمة على البادئة (جميع أنواع المواقع التي لا تتضمن تعبيرًا منتظمًا). تفحص كل موقع مقابل عنوان URI الكامل للطلب.
• أولاً، يبحث Nginx عن تطابق دقيق. إذا تم العثور على كتلة موقع تستخدم العلامة المحددة = لتطابق عنوان URI للطلب بشكل دقيق، يتم اختيار هذه الكتلة على الفور لخدمة الطلب.
• إذا لم يتم العثور على تطابقات دقيقة (مع العلامة المحددة =)، ينتقل Nginx إلى تقييم البادئات غير الدقيقة. يكتشف أطول موقع بادئة متطابق لعنوان URI المعطى للطلب، والذي يتم تقييمه على النحو التالي:
  • إذا كان لدى موقع البادئة المتطابق الأطول العلامة المحددة ^~، فسينهي Nginx بشكل فوري بحثه ويختار هذا الموقع لخدمة الطلب.
  • إذا كان موقع البادئة المتطابق الأطول لا يستخدم العلامة المحددة ^~، يتم تخزين التطابق بواسطة Nginx في الوقت الحالي بحيث يمكن تحويل تركيز البحث.
• بعد تحديد وتخزين أطول موقع يطابق البادئة، ينتقل Nginx إلى تقييم مواقع التعبيرات العادية (سواء كانت حساسة لحالة الأحرف أم لا). إذا كانت هناك أي مواقع للتعبيرات العادية داخل الموقع الذي يطابق أطول بادئة، سيقوم Nginx بنقل تلك المواقع إلى أعلى قائمته من مواقع التعبيرات العادية لفحصها. بعد ذلك، يحاول Nginx مطابقة المواقع للتعبيرات العادية بشكل تسلسلي. الموقع للتعبير العادي الذي يتطابق أولاً مع معرف طلب الـ URI يتم اختياره على الفور لخدمة الطلب.
• إذا لم يتم العثور على مواقع للتعبيرات العادية تتطابق مع معرف طلب الـ URI، يتم اختيار الموقع الذي تم تخزينه مسبقًا للبادئة لخدمة الطلب.

من المهم فهم أنه، بشكل افتراضي، سيخدم Nginx تطابقات التعبير العادية بالأفضلية على التطابقات البادئة. ومع ذلك، يقوم بتقييم مواقع البادئة أولاً، مما يسمح للمسؤول بتجاوز هذا الاتجاه عن طريق تحديد المواقع باستخدام المعدلات = و ^~.

من المهم أيضًا ملاحظة أنه، بينما تقوم مواقع البادئة عمومًا باختيار الموقع الأطول والأكثر تحديدًا، يتم إيقاف تقييم التعبيرات العادية عندما يتم العثور على أول موقع مطابق. وهذا يعني أن الوضع داخل التكوين له تأثيرات هائلة على مواقع التعبيرات العادية.

أخيرًا، من المهم فهم أن تطابق التعبير العادي داخل أطول تطابق بادئ سيقفز السطر عندما يقوم Nginx بتقييم مواقع التعبير العادية. سيتم تقييم هذه المواقع، بالترتيب، قبل النظر في أي من التطابقات الأخرى للتعبير العادي. يشرح ماكسيم دونين، مطور Nginx المفيد للغاية، في هذه المشاركة هذا الجزء من خوارزمية الاختيار.

متى يتم الانتقال في تقييم كتلة المواقع إلى مواقع أخرى؟

بشكل عام، عندما يتم اختيار كتلة المواقع لخدمة طلب، يتم التعامل مع الطلب بالكامل داخل ذلك السياق ابتداءً من ذلك النقطة. فقط الموقع المحدد والتوجيهات الموروثة تحدد كيفية معالجة الطلب، دون تداخل من كتل المواقع الأخرى.

على الرغم من أن هذه قاعدة عامة تسمح لك بتصميم كتل المواقع الخاصة بك بطريقة قابلة للتنبؤ، إلا أنه من المهم أن ندرك أن هناك أوقات يتم فيها تشغيل بحث الموقع الجديد بواسطة توجيهات معينة داخل الموقع المحدد. قد تكون الاستثناءات من قاعدة “كتلة الموقع الواحدة فقط” لها تأثيرات على كيفية خدمة الطلب في الواقع وقد لا تتماشى مع التوقعات التي كانت لديك عند تصميم كتل المواقع الخاصة بك.

بعض التوجيهات التي يمكن أن تؤدي إلى هذا النوع من إعادة التوجيه الداخلي هي:

• index
• try_files
• rewrite
• error_page

لنلق نظرة على هذه بإيجاز.

توجد توجيهات index دائمًا تؤدي إلى إعادة توجيه داخلي إذا تم استخدامها للتعامل مع الطلب. يتم استخدام تطابق الموقع الدقيق في كثير من الأحيان لتسريع عملية الاختيار عن طريق إنهاء تنفيذ الخوارزمية مباشرة. ومع ذلك، إذا قمت بتحديد موقع دقيق هو دليل، فهناك فرصة جيدة لأن يتم إعادة توجيه الطلب إلى موقع مختلف للمعالجة الفعلية.

في هذا المثال، يتم تطابق الموقع الأول بواسطة طلب URI لـ /exact، ولكن للتعامل مع الطلب، فإن توجيه index الذي ورثه الكتلة يبدأ بإعادة توجيه داخلي إلى الكتلة الثانية:

index index.html;

location = /exact {

    . . .

}

location / {

    . . .

}

في الحالة أعلاه، إذا كنت بحاجة حقًا إلى بقاء التنفيذ في الكتلة الأولى، ستحتاج إلى استخدام طريقة مختلفة لتلبية الطلب على الدليل. على سبيل المثال، يمكنك تعيين index غير صالح لتلك الكتلة وتشغيل autoindex:

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

location  / {

    . . .

}

هذه طريقة واحدة لمنع index من تغيير السياقات، لكنها ربما لا تكون مفيدة لمعظم التكوينات. في الغالب، يمكن أن يكون التطابق الدقيق على الدلائل مفيدًا لأمور مثل إعادة كتابة الطلب (التي تنتج أيضًا عن بحث موقع جديد).

حالة أخرى حيث قد يتم إعادة تقييم موقع المعالجة هو باستخدام توجيه try_files. يقول هذا التوجيه لـ Nginx بالتحقق من وجود مجموعة مسماة من الملفات أو الدلائل. يمكن أن يكون آخر معلم هو URI سيقوم Nginx بإجراء إعادة توجيه داخلي إليه.

Considere la siguiente configuración:

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

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

En el ejemplo anterior, si se realiza una solicitud para /blahblah, inicialmente la primera ubicación recibirá la solicitud. Intentará encontrar un archivo llamado blahblah en el directorio /var/www/main. Si no puede encontrar uno, buscará un archivo llamado blahblah.html. Luego intentará ver si hay un directorio llamado blahblah/ dentro del directorio /var/www/main. Si fallan todos estos intentos, se redireccionará a /fallback/index.html. Esto desencadenará otra búsqueda de ubicación que será capturada por el segundo bloque de ubicación. Este servirá el archivo /var/www/another/fallback/index.html.

Otra directiva que puede llevar a una transferencia de control de bloque de ubicación es la directiva rewrite. Al usar el parámetro last con la directiva rewrite, o al no usar ningún parámetro en absoluto, Nginx buscará una nueva ubicación coincidente basada en los resultados de la reescritura.

Por ejemplo, si modificamos el último ejemplo para incluir una reescritura, podemos ver que la solicitud a veces se pasa directamente al segundo bloque de ubicación sin depender de la directiva 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;
}

En el ejemplo anterior, una solicitud para /rewriteme/hello será manejada inicialmente por el primer bloque de ubicación. Será reescrito a /hello y se buscará una ubicación. En este caso, coincidirá nuevamente con la primera ubicación y será procesado por try_files como de costumbre, tal vez regresando a /fallback/index.html si no se encuentra nada (usando la redirección interna try_files que discutimos anteriormente).

ومع ذلك، إذا تم تقديم طلب لـ /rewriteme/fallback/hello، فإن الكتلة الأولى ستتطابق مرة أخرى. سيتم تطبيق إعادة الكتابة مرة أخرى، مما يؤدي هذه المرة إلى /fallback/hello. ثم سيتم تقديم الطلب من الكتلة الثانية.

A related situation happens with the return directive when sending the 301 or 302 status codes. The difference in this case is that it results in an entirely new request in the form of an externally visible redirect. This same situation can occur with the rewrite directive when using the redirect or permanent flags. However, these location searches shouldn’t be unexpected, since externally visible redirects always result in a new request.

يمكن أن تؤدي التوجيهة error_page إلى إعادة توجيه داخلي مماثل لتلك التي تم إنشاؤها بواسطة try_files. تُستخدم هذه التوجيهة لتعريف ما يجب أن يحدث عندما يتم مواجهة رموز حالة معينة. من المحتمل أن لا تتم تنفيذها أبدًا إذا تم تعيين try_files، لأن هذه التوجيهة تتعامل بالكامل مع دورة حياة الطلب.

افترض هذا المثال:

root /var/www/main;

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

location /another {
    root /var/www;
}

سيتم التعامل مع كل طلب (باستثناء تلك التي تبدأ بـ /another) بواسطة الكتلة الأولى، التي ستقدم الملفات من /var/www/main. ومع ذلك، إذا لم يتم العثور على الملف (رمز حالة 404)، سيحدث إعادة توجيه داخلي إلى /another/whoops.html، مما يؤدي إلى بحث جديد عن الموقع سينتهي في النهاية في الكتلة الثانية. سيتم تقديم هذا الملف من /var/www/another/whoops.html.

كما يمكن ملاحظة، فإن فهم الظروف التي يؤدي فيها Nginx إلى بحث جديد عن الموقع يمكن أن يساعد في توقع السلوك الذي ستراه عند إجراء الطلبات.

الاستنتاج

فهم طرق معالجة طلبات العميل من قِبل Nginx يمكن أن يجعل عملك كمسؤول أسهل بكثير. ستكون قادرًا على معرفة أي كتلة خادم سيختار Nginx استنادًا إلى كل طلب عميل. ستكون أيضًا قادرًا على معرفة كيف سيتم اختيار كتلة الموقع استنادًا إلى معرفة طلب URI. بشكل عام، معرفة الطريقة التي يختار بها Nginx كتل مختلفة ستمنحك القدرة على تتبع السياقات التي ستطبقها Nginx لخدمة كل طلب.