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

مقدمة

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

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

أولاً وقبل كل شيء، إليك دليل تعليمي شامل حول كيفية تثبيت Nginx على خادم Ubuntu الخاص بك. الآن، لنبدأ!

تكوين الكتل باستخدام Nginx

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

الكتل الرئيسية التي سنناقشها ستكون كتل server وكتل location المغلقة. كتل Server هي مجموعة فرعية من التكوينات التي ينشئها Nginx والتي تحدد الخادم الافتراضي الذي سيكون مسؤولاً عن معالجة نوع معين من الطلبات. وهي تعتمد في الغالب على عنوان IP، أو اسم النطاق، أو منفذ الطلب الوارد. يقوم المسؤولون بتكوين كتل server متعددة. بعد ذلك، يتعين عليهم تحديد أي من الاتصالات يجب أن يعالج الطلب.

توجد كتل Location داخل كتل server. هذه الكتل هي صانعة القرار بشأن كيفية ومصادر الموارد التي يمكنك الاستفادة منها لمعالجة الطلبات الواردة إلى الخادم الأصل الخاص بها. هذا النموذج مرن للغاية. يمكن تكوين مساحة URI لاستخدام هذه الكتل بأي طريقة يراها المسؤول أفضل.

تحديد الكتلة التي ستعالج أي طلب باستخدام Nginx

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

يتعامل Nginx بشكل أساسي مع توجيهين رئيسيين لكتل الخادم: listen و server_name.

البحث عن التطابقات المحتملة باستخدام التوجيه 'Listen'

أول شيء يقيمه Nginx هو المنفذ وعنوان IP الخاص بالطلب. بعد ذلك، يطابقه مع التوجيه listen الخاص بكل خادم. يساعد تحليل قائمة الخوادم هذا في عزل كتل server التي يمكنها حل الطلب المعني فقط.

عادةً، يحدد التوجيه listen المنفذ وعنوان IP الذي ستكون كتلة server معينة مسؤولة عن الاستجابة له. تتلقى كتلة server التي لا تحتوي على التوجيه listen معلمات الاستماع لـ 0.0.0.0:80 افتراضياً. إذا تم تشغيل Nginx بواسطة مستخدم عادي غير جذر، فسيتم تحديد معلمة listen كـ 0.0.0.0:8080. وهذا يعني أنه مهما كانت الواجهة، إذا كانت الكتل تأتي من المنفذ 80، فإن الكتل المحددة بهذه الطريقة ستستجيب لها. ومع ذلك، لا يتم إعطاء هذه القيمة الافتراضية وزناً كبيراً في عملية اختيار الخادم.

يمكنك تكوين التوجيه listen لـ:

• عنوان IP فردي يستمع للطلبات على المنفذ الافتراضي (80).
• منفذ فردي يستمع إلى أي واجهة على ذلك المنفذ.
• مزيج من المنفذ وعنوان IP.
• مسار مقبس Unix محدد (هذا الخيار له تأثيرات فقط عندما تمر الطلبات عبر خوادم مختلفة).

سيقوم Nginx بتطبيق مجموعة من القواعد عند تحديد كتلة server التي سيتم إرسال الطلب إليها. تعتمد القواعد على التكوين الخاص للتوجيه listen. وهي كما يلي:

• إذا كان التوجيه listen غير مكتمل، فستحصل الأجزاء المفقودة على قيمها الافتراضية. وهذا يعني أنه سيتم إكمال عنوان IP والمنفذ بالقيم الافتراضية من أجل معالجة الطلب.
  • في هذه الحالة، ستستخدم الكتلة التي لا تحتوي على توجيه listen القيمة الافتراضية 0.0.0.0:80.
  • الكتلة التي تفتقد إلى منفذ، ولديها عنوان IP هو 111.111.111.111 ستصبح 111.111.111.111:80.
  • عندما لا يكون هناك عنوان IP، فإن الكتلة ذات المنفذ 8888 ستكتسب عنوان IP الافتراضي لإلحاقه لإنشاء 0.0.0.0:8888.
• بعد تحديد عنوان IP والمنفذ، سيبحث Nginx بعد ذلك عن كتل الخادم المقدمة كمطابقة لذلك المنفذ.
• إذا وجد مطابقة محددة واحدة فقط، فستكون هذه هي كتلة الخادم. وإذا كانت هناك كتل متعددة مؤهلة، فسيتجه Nginx إلى توجيه server_name لمزيد من التفصيل للوصول إلى كتلة الخادم المعنية بدقة.

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

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

البحث عن المطابقات المحتملة باستخدام توجيه 'Server_Name'

إذا كانت توجيهات listen محددة بالتساوي، فسيقوم Nginx بفحص ترويسة 'Host' الخاصة بالطلب’. هذه قيمة ستحتوي على عنوان IP الخاص بالنطاق الذي كان العميل يتطلع للوصول إليه في البداية. سيستخدم Nginx توجيه server_name داخل كل كتلة خادم مرشحة لا تزال مؤهلة. ويقوم بإجراء هذه التقييمات بناءً على صيغة معينة، وهي كالتالي:

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

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

أمثلة على تحديد كتلة الخادم

إذا كان الـ server_name المحدد يطابق قيمة ترويسة ‘Host’ تمامًا، فستكون هي كتلة الخادم المحددة لمعالجة الطلب. يوضح المثال التالي ترويسة ‘Host’ للطلب المحددة كـ “host1.example.com”. في هذه الحالة، سيتم تحديد الخادم الثاني:

بدون مطابقة تامة، سيتحقق Nginx مما إذا كان الـ server_name الذي يحتوي على علامة بديلة موجودًا. وإذا لم يكن موجودًا، فسيتم تحديد المطابقة الأطول التي تبدأ بعلامة بديلة. في ما يلي، “www.example.org” موجودة في ترويسة “Host”. وهذا يعني أنه سيختار الكتلة الثانية:

بدون تطابق يبدأ بحرف البدل (wildcard)، ينتقل Nginx إلى التحقق من حرف البدل اللاحق. سيتم تحديد أطول تطابق ينتهي بحرف البدل لمعالجة الطلب. في هذه الحالة، ترويسة “Host” هي “www.example.com”، لذلك سيختار كتلة الخادم (server block) الثالثة:

إذا لم تكن هناك أي تطابقات بعد، فسيحاول Nginx مطابقة توجيهات server_name باستخدام التعبيرات القياسية. يتم تحديد أول هذه التعبيرات لمعالجة الطلب. إذا كان “Host” هو “www.example.com”، فستكون كتلة الخادم الثانية هي الخيار لتلبية الطلب:

مع عدم وجود تطابقات حتى الآن، سينتقل الطلب إلى تركيبة عنوان IP والمنفذ (port) مع إعداد الخادم الافتراضي المطابق.

مطابقة كتل الموقع (Location Block)

يحتاج Nginx أيضًا إلى تحديد خوارزمية يقرر من خلالها أي كتلة موقع (location block) على الخادم ستكون مسؤولة عن الاستجابة للطلب.

صيغة كتل الموقع (Location Blocks)

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

تبدو كتل الموقع عادةً على النحو التالي:

سيقوم Nginx بالتحقق من URI الخاص بالطلب مقابل الـ location_match. وسواء كان المعدل (modifier) المذكور أعلاه موجودًا أم لا، فإن ذلك سيحدد الطريقة التي سيحاول بها Nginx مطابقة الكتل. اعتمادًا على المعدل، سيتم تفسير كتل الموقع وفقًا للقواعد التالية:

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

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

لتقديم مثال على مطابقة البادئة، ستكون كتلة الموقع هي الخيار للاستجابة لـ URI الخاص بطلب على شكل /site، أو /site/page1/index.html، أو /site/index/html:

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

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

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

المتغير الأخير هو المتغير الذي تمنع فيه الكتلة حدوث مطابقة التعبيرات العادية إذا تبين أنها المطابقة المثلى غير التعبيرية العادية. يمكن لهذه الكتلة معالجة الطلبات الخاصة بـ /costumes/ninja.html:

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

اختيار الموقع الذي سيتعامل مع الطلبات بواسطة Nginx

إن الطريقة التي يختار بها Nginx الموقع الذي يعالج الطلب تشبه كيفية تحديد كتل الخادم (server blocks). وبعبارة أخرى، فإنه يحدد الموقع الأمثل لكل طلب من خلال تشغيل عملية معينة. ومن أجل تكوين Nginx بدقة وبناءً على ذلك، فمن الضروري أن تفهم هذه العملية.

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

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

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

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

والنقطة الأخيرة التي يجب التطرق إليها هي أن تطابقات التعبيرات النمطية داخل التطابق مع أطول بادئة ستتجاوز الدور أساسًا أثناء تقييمات مواقع Nginx. وسيتم وضعها في الجزء العلوي من القائمة وتقييمها قبل التعبيرات النمطية الأخرى.

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

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

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

يمكن أن تظهر عمليات إعادة التوجيه الداخلية هذه بسبب بعض التوجيهات بما في ذلك:

• index
• rewrite
• error_page
• try_files

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

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

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

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

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

دعونا نفكر في الإعدادات التالية:

إذا كان هناك طلب لـ /blahblah، فسيستقبله الـ location الأول. وعدم العثور على ملف blahblah في دليل /var/www/main سيؤدي إلى إطلاق بحث لاحق عن blahblah.html. بعد ذلك، سيبحث عن دليل فرعي باسم blahblah في دليل /var/www/main. وإذا فشلت كل هذه الفحوصات، فسيتم إعادة التوجيه إلى /fallback/index.html. سيؤدي هذا إلى إطلاق بحث آخر عن location سيلتقطه block location آخر. بعد ذلك، سيعالج الملف /var/www/another/fallback/index.html.

التوجيه الآخر الذي يؤدي إلى إعادة التوجيه إلى block location آخر هو توجيه rewrite. سيبحث Nginx عن location مطابق جديد بناءً على نتيجة توجيه rewrite عند استخدام المعلمة last. إذا تم تعديل المثال الأخير ليشمل الآن توجيه rewrite هذا، فسيصبح من الواضح أنه يمكن إعادة توجيه الطلب إلى location آخر دون تنفيذ توجيه try_files:

في هذا المثال، سيتم التعامل مع الطلب الخاص بـ /rewrite/hello بواسطة الـ location الأول في البداية. بعد إعادة كتابته إلى /hello، سيتم إطلاق بحث ثانوي عن location. وسيتطابق مع الـ location الأول. وسيتم معالجته بواسطة توجيه try_file، مع إمكانية الرجوع إلى /fallback/index.html إذا لم يؤدِ إلى أي نتائج.

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

تحدث مواقف مماثلة عندما تستخدم توجيه return لإرسال رموز الحالة 301 أو 302. الفرق الوحيد هو أنه ينتج عن ذلك طلب جديد، ويظهر في شكل إعادة توجيه واضحة للغاية. وبالمثل، يمكن أن يحدث هذا مع توجيه rewrite عندما تقوم بتطبيق علامتي permanent أو redirect.

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

دعونا نفكر في المثال التالي:

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

كما هو واضح، فإن فهم الحالات التي سيقوم فيها Nginx بتشغيل بحث جديد عن الموقع (location) يمكن أن يساعد في التنبؤ بشكل أفضل بسلوك النظام عند معالجة الطلبات.

الخلاصة

تصبح مهام المسؤولين أسهل بكثير عندما يفهمون الطرق التي يتعامل بها Nginx مع طلبات العملاء. يتيح ذلك للمسؤولين التأكد من كتلة الخادم (server block) التي سيذهب إليها الطلب. يمكنهم أيضًا تحديد كتلة الموقع (location block) التي سيتم اختيارها بناءً على معرف URI الخاص بالطلب. وبشكل عام، فإنه يمنح المسؤولين أيضًا القدرة على تتبع السياقات المطبقة من Nginx عند معالجة كل طلب.

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

• عالم خوادم الويب: Apache مقابل Nginx
• كيفية تأمين Nginx باستخدام Let’s Encrypt على Ubuntu 20.04
• أتمتة تجديدات شهادة SSL من LetsEncrypt لـ Nginx
• نشر Laravel و Nginx و MySQL باستخدام Docker Compose

حوسبة سعيدة!