قائمة مراجعة Nginx Reverse Proxy قبل الإنتاج

يبدأ إعداد Nginx غالباً بعدة أسطر من دليل framework، لكن بيئة الإنتاج تحتاج مراجعة أعمق لأن الـ proxy يتحكم في هوية العميل والبروتوكول وحجم الطلب والمهل وTLS وجزء من تجربة الفشل.

مرر سياق الطلب الصحيح

location / {
    proxy_pass http://app_upstream;
    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;
}

يجب أن يثق التطبيق في الرؤوس المحولة فقط عندما يأتي الطلب من proxies معروفة. الثقة العمياء في X-Forwarded-For تسمح للعميل باختراع عنوانه.

حدد المهل بناءً على السلوك

المهل ليست مجرد تحسين أداء؛ هي تحدد مدة حجز الموارد والفشل الذي يراه المستخدم.

اجعل مهلة الاتصال قصيرة، وحدد مهلة الاستجابة بناءً على endpoint الحقيقي. لا ترفع كل المهل من أجل عملية تصدير واحدة بطيئة؛ انقل العمل الطويل إلى Queue مع متابعة للحالة أو رابط تنزيل عند الاكتمال.

راجع حد رفع الملفات وbuffering بوضوح. إعداد مناسب لـ JSON API قد يرفض ملفات مشروعة، وحد عالمي ضخم يوسع الخطر على كل المسارات.

أنهِ TLS بعناية

استخدم إصدارات TLS الحديثة وجدولة تلقائية لتجديد الشهادة، واختبر مسار التجديد قبل أول تاريخ انتهاء.

أضف HSTS فقط بعد التأكد أن كل النطاقات الفرعية المطلوبة تعمل عبر HTTPS. يجب أن يكون هناك مالك واضح لرؤوس الحماية حتى لا يكررها التطبيق وNginx بشكل متعارض.

اجعل فشل الخدمة مفهوماً

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

السجلات المفيدة تحتوي زمن الطلب، وزمن استجابة upstream، والحالة، وعنوان upstream، ومعرف الطلب، والطريقة، والمسار. لا تسجل authorization أو cookies أو query strings حساسة.

قبل الإطلاق اختبر الطلبات الكبيرة، وبطء upstream، وانقطاع الاتصال، وWebSocket إن وجد، وإلغاء العميل للطلب، وتجديد الشهادة، والتحويل إلى HTTPS، والتعامل مع IP الحقيقي، وصفحة الفشل.