إيفلون - مدونة البرمجة وتطوير البرمجيات

إعداد Nginx كـ Reverse Proxy لتطبيق ويب

عند تشغيل تطبيق Python أو Node مباشرة على منفذ داخلي، تحتاج غالباً إلى طبقة تستقبل الطلبات العامة وتوجهها إلى التطبيق. Nginx يمكنه أداء دور Reverse Proxy، وإنهاء TLS، وتقديم الملفات الثابتة، ووضع حدود أولية للطلبات. سنكتب إعداداً بسيطاً يوجه المسار العام إلى تطبيق يعمل على localhost، ثم نشرح معنى proxy_pass والرؤوس التي تحافظ على معلومات الطلب. المثال لا يغني عن ضبط أمني كامل، لكنه يوضح كيف تفصل واجهة الشبكة عن عملية التطبيق.

الفكرة الأساسية

يستقبل Nginx الطلب من العميل ثم يمرره إلى upstream داخلي. يجب ضبط Host وX-Real-IP وX-Forwarded-For حتى يعرف التطبيق مصدر الطلب والبروتوكول الأصلي. في تطبيقات WebSocket تحتاج إلى رؤوس ترقية خاصة، بينما تكفي إعدادات مختلفة للملفات الثابتة. لا تضع التطبيق على عنوان عام إذا كان Nginx هو نقطة الدخول المقصودة، واحرص على أن تكون الخوادم الداخلية غير متاحة من الإنترنت.

مثال برمجي عملي

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /static/ {
        alias /srv/app/static/;
        expires 7d;
    }
}

شرح المثال

يحدد server المنفذ واسم النطاق، ثم يرسل كل ما يقع تحت / إلى التطبيق الداخلي على 8000. الرؤوس تمنع فقدان معلومات مهمة عند مرور الطلب عبر الوكيل. يستخدم alias لتقديم الملفات الثابتة من مسار محدد، وتضيف expires توجيهاً للمتصفح حول مدة التخزين. في بيئة TLS ينبغي أن يستمع Nginx على 443 ويعيد توجيه HTTP، مع إدارة الشهادة وتجديدها بطريقة موثوقة.

ثبت Nginx في بيئة اختبار، وضع ملف الإعداد داخل sites-available ثم فعّله بعد فحص الصياغة. شغل التطبيق داخلياً واختبر الوصول عبر Nginx لا عبر المنفذ الداخلي فقط. راقب access وerror logs، وجرب طلباً إلى مسار غير موجود. بعد نجاح التوجيه أضف TLS وحدوداً لحجم الجسم والمهلات بما يتناسب مع التطبيق، ثم اختبر الملفات الثابتة وطلبات API.

ابدأ من عقد واضح

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

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

تجارب ينبغي ألا تهملها

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

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

ما الذي يجعل الحل عملياً؟

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

خطوة ما بعد المثال

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

أخطاء ينبغي تجنبها

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

خطوة تالية مناسبة

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

حماية تطبيق خلف Nginx

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

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

خطة تطبيق عملية

بعد فهم موضوع «إعداد Nginx كـ Reverse Proxy لتطبيق ويب»، لا تنقل المثال إلى مشروع كبير دفعة واحدة. أنشئ مجلداً صغيراً، وثبت نسخة الأدوات التي ستستخدمها، ثم اكتب حالة نجاح واحدة يمكن تشغيلها من البداية إلى النهاية. احتفظ بالمدخل الذي استخدمته والنتيجة التي توقعتها، لأن ذلك يمنحك نقطة مقارنة عندما تغير الكود. إذا كان الموضوع يعتمد على خدمة أو قاعدة بيانات، جهز بيانات تجريبية لا تحمل معلومات حقيقية، واكتب طريقة تنظيفها بعد انتهاء الاختبار.

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

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

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

اختبار الإعداد

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

الخلاصة

أضف مساراً لتطبيق ثانٍ باسم مختلف، ثم جرّب موازنة الطلبات بين منفذين. راجع إعدادات security headers وسجل الطلبات، وحدد ما يمكن حجبه من معلومات الخادم قبل النشر. يوضح هذا الموضوع كيف تتحول الفكرة النظرية إلى خطوات يمكن تشغيلها وفحصها.

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

تعديل المقال