أداة التحقق من إعدادات Nginx
الصق ملف nginx.conf لاكتشاف أخطاء بناء الجملة، والتوجيهات الموضوعة في مكان خاطئ، وأخطاء الأمان الشائعة — قبل إعادة تحميل nginx فعليًا.
أفلت ملف .conf هنا، أو الصق نص الإعدادات أعلاه.
كل شيء يتم في متصفحك — لا يتم رفع إعداداتك إلى أي خادم على الإطلاق.
الصق إعداد nginx أعلاه (أو حمّل المثال) لتظهر الفحوص هنا.
يستخدم محرك التعابير النمطية الخاص بـ JavaScript، وليس محرك PCRE الحقيقي في nginx — قريب جدًا لكنه ليس مطابقًا تمامًا (بدون possessive quantifiers/atomic groups).
اكتشاف أخطاء إعداد nginx قبل وصولها إلى الإنتاج
يعلن ملف nginx.conf المعطوب عن نفسه عادةً بإحدى طريقتين مزعجتين: إما أن يرفض `nginx -t` إعادة التحميل برسالة خطأ غامضة برقم سطر، أو، وهو الأسوأ، أن تُبقي `reload` الإعداد القديم (السليم) في الذاكرة بصمت بينما يبقى الجديد المعطوب على القرص، فلا يبدو أن شيئًا خاطئ حتى إعادة التشغيل الكاملة التالية. ويمكن تفادي الاثنين باكتشاف الفئة نفسها من الأخطاء مبكرًا وأنت ما زلت تحرر الملف.
أشيع أخطاء nginx.conf في الواقع ليس غريبًا، بل فاصلة منقوطة منسية. فبما أن قواعد nginx تهتم فقط بـ `;` و`{` و`}` (لا بفواصل الأسطر)، لا يعطيك غياب `;` خطأً واضحًا مثل «السطر 12: متوقع ;» كما تفعل معظم المحللات الحديثة، بل يُمتص اسم التوجيه التالي ووسائطه بصمت كوسائط إضافية للتوجيه السابق، وأحيانًا دون أي خطأ إلى أن يتصرف شيء لاحق بغرابة. تراقب خوارزمية فواصل الأسطر في هذه الأداة هذا النمط تحديدًا، أي ظهور اسم توجيه معروف وسط قائمة وسائط في سطر مصدر جديد، وتنبّه إليه قبل أن يتحول إلى تذكرة دعم.
وضع التوجيهات هو الفخ الشائع الثاني: لا يصلح `proxy_pass` إلا داخل كتلة `location` (أو `if`)، ولا يصلح `listen`/`server_name` إلا داخل `server`، وهكذا، لكن محلل nginx نفسه لا يرفض توجيهًا لمجرد وجوده في موضع غير معتاد ما دام اسم التوجيه معروفًا له بمعنى أوسع، وتشير رسائل الخطأ إلى سجل التوجيهات الداخلي لـ nginx لا إلى «لقد أسأت تداخل هذا». يفحص هذا المدقق جدول التوجيه-والسياق مباشرةً، فيُبلَّغ عن `proxy_pass` تُرك بالخطأ على مستوى `http` (خارج أي `server`/`location`) في سطره الدقيق، لا بمجرد «فشل تحميل الإعداد».
وإلى جانب الصياغة، لعدد من خيارات الإعداد الصغيرة عواقب أمنية كبيرة: ترك `server_tokens` على قيمته الافتراضية (`on`) يكشف رقم إصدار nginx بدقة في كل ترويسة استجابة وصفحة خطأ افتراضية، وهو استطلاع مجاني لأي شخص يبحث عن ثغرة CVE خاصة بإصدار معين؛ واستخدام المتغير `$uri` المفكوك الترميز داخل `return`/`rewrite`/`add_header` (بدل `$request_uri` الخام) قد يتيح للمهاجم حقن أحرف في هدف إعادة التوجيه في بعض الإعدادات. ولا يكسر أيٌّ من هذين شيئًا ظاهرًا أثناء الاختبار العادي، ولهذا بالضبط يستحقان تمريرة مخصصة بدل الاعتماد على ملاحظتهما بالعين في إعداد من 200 سطر.
الأسئلة الشائعة
هل تغني هذه الأداة عن `nginx -t`؟
لا. `nginx -t` هو الأداة الوحيدة التي تفحص إعدادك وفق إصدار nginx والوحدات المثبتة فعليًا على خادمك، وهو الكلمة الأخيرة قبل إعادة التحميل. يلتقط هذا المدقق الفئة نفسها من الأخطاء (أخطاء الصياغة ووضع التوجيهات في غير موضعها وبعض الملاحظات الأمنية) قبل أن تصل إلى خادم مثبت عليه nginx، وهذا مفيد أثناء التحرير محليًا أو في خطوة CI أو حين لا تملك وصولًا إلى سطر أوامر الجهاز الهدف بعد.
هل قائمة الفحوص الأمنية شاملة؟
لا، فهي تغطي مجموعة صغيرة مختارة عمدًا (غياب `server_tokens off;` و`autoindex on;` واستخدام `$uri` حيث يكون `$request_uri` أأمن) مستوحاة بتصرف من Gixy، مدقق إعدادات nginx مفتوح المصدر. وهي ليست بديلًا عن Gixy ولا عن تدقيق أمني كامل.
لماذا يختلف مختبر regex قليلًا عن nginx الحقيقي؟
تعتمد مطابقة `location ~` و`location ~*` في nginx على PCRE (عبر مكتبة PCRE المضمنة في ملف nginx التنفيذي). تعمل هذه الأداة بالكامل في متصفحك، لذا تستخدم محرك RegExp المدمج في JavaScript، والمحركان متقاربان جدًا في الأنماط الشائعة، لكن ميزات PCRE وحدها مثل المحددات الاستحواذية أو المجموعات الذرية لن تتصرف هنا بالطريقة نفسها.
هل يغادر إعدادي متصفحي في أي وقت؟
لا. يعمل التحليل والتحقق والمحاكيان بـ JavaScript عادي في هذا التبويب. لا يُرفع شيء ولا يُسجَّل ولا يُرسل إلى أي مكان، ويمكنك قطع الاتصال بالإنترنت بعد تحميل الصفحة وستستمر الأداة بالعمل.