كل ما درسناه في هذه السلسلة كان يتجه نحو هذا الدرس. أنت تمتلك الآن المفردات اللازمة — إنهاء TLS، والبروكسي العكسي، ومجموعات الخوادم الخلفية، والتخزين المؤقت، وتحديد معدل الطلبات، ورؤوس الأمان، ومفاتيح الضبط. يربط هذا المشروع جميع هذه العناصر معاً في تهيئة Nginx واحدة مختبرة ميدانياً يمكنك نشرها أمام تطبيق حقيقي اليوم. التطبيق النموذجي هو عملية Node.js أو Python أو PHP تستمع على 127.0.0.1:8000، لكن النمط متطابق مع أي لغة أو إطار عمل.
سنبني التهيئة في طبقات متعمدة — نجعلها تعمل أولاً، ثم نجعلها صحيحة، ثم سريعة وصلبة. يعكس هذا التطور الطريقة الفعلية التي يكرر بها المهندسون الكبار على البنية التحتية للإنتاج.
معمارية المشروع
طبقات Nginx للإنتاج: إنهاء TLS، وتحديد المعدل، والتخزين المؤقت، وتمرير البروكسي إلى مجموعة التطبيقات الخلفية.
الخطوة الأولى — تخطيط المجلدات والمتطلبات الأساسية
قبل كتابة أي توجيه واحد، أنشئ تخطيط الملفات. تستخدم البيئات المؤسسية الكبرى نمط sites-available / sites-enabled مع الروابط الرمزية حتى يمكن إدارة كل مضيف ظاهري باستقلالية وتعطيله دون لمس الآخرين.
# Install Nginx and Certbot (Debian/Ubuntu)
apt-get update && apt-get install -y nginx certbot python3-certbot-nginx
# Create directory structure
mkdir -p /etc/nginx/conf.d
mkdir -p /var/cache/nginx/app_cache
mkdir -p /var/log/nginx
mkdir -p /var/www/app/public
# Set cache directory ownership
chown -R www-data:www-data /var/cache/nginx
# Obtain a TLS certificate (DNS must already point to this server)
certbot certonly --nginx -d example.com -d www.example.com \
--non-interactive --agree-tos -m ops@example.com
الخطوة الثانية — خط أساس nginx.conf العالمي
يضبط الملف العالمي ضبط العمال، وتنسيق التسجيل، ويُعلن منطقة التخزين المؤقت المشتركة. تعيش منطقة التخزين المؤقت هنا — وليس في كتلة الخادم — لأن المنطقة هي منطقة ذاكرة مشتركة، وليست خاصة بكل مضيف ظاهري.
لماذا تنسيق سجل JSON؟ تتطلب السجلات العادية المدمجة محللات تعبير منتظم في كل مجمّع سجلات. يُرسَل سجل JSON المنظّم مباشرة إلى Elasticsearch أو Datadog أو Splunk دون أي تحويل. كل حقل — وقت استجابة الخادم الخلفي، حالة ضربة التخزين المؤقت، الأسلوب — يصبح بُعداً قابلاً للتصفية. على نطاق واسع، هذا هو الفرق بين حادث يستغرق 30 دقيقة وحادث يستغرق 3 دقائق.
الخطوة الثالثة — تهيئة المضيف الظاهري
هذا هو ملف /etc/nginx/conf.d/example.conf الكامل. اقرأ التعليقات الداخلية بعناية — لكل توجيه سبب سيُهم في الإنتاج.
الخطوة الخامسة — تجديد TLS التلقائي وإعادة تحميل Nginx
تنتهي صلاحية الشهادات كل 90 يوماً. يُثبّت Certbot مؤقت systemd يُشغّل التجديد مرتين يومياً، لكنه لا يُعيد تحميل Nginx تلقائياً بعد التجديد. يجب أن تتصل بخطوة ما بعد التجديد.
# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/bash
set -e
nginx -t && systemctl reload nginx
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
# Test the full renewal flow without actually renewing
certbot renew --dry-run
أنماط الفشل الشائعة في الإنتاج
كل نمط في هذه التهيئة موجود لأن شيئاً ما انكسر في الإنتاج. إليك أكثر أنماط الفشل شيوعاً التي يواجهها المهندسون مع هذا الإعداد بالتحديد:
502 Bad Gateway بعد النشر: أُعيد تشغيل عملية التطبيق لكن مجموعة keepalive للخادم الخلفي لا تزال تحتفظ باتصال بـ FD العملية القديمة. الإصلاح: اضبط proxy_next_upstream error timeout invalid_header http_502 حتى يُعيد Nginx المحاولة مع الخادم التالي عند الفشل.
تسميم التخزين المؤقت عبر حقن رأس Host: يُرسل المهاجم رأس Host مصنوعاً خصيصاً؛ يُخزّن Nginx استجابة مفهرسة لنطاق مختلف. الإصلاح: اضبط صراحةً proxy_cache_key "$scheme$host$request_uri" ولا تُضمّن رؤوس يوفرها المستخدم في مفتاح التخزين المؤقت.
إقفال HSTS لنطاق ما: إذا ضبطت max-age طويلاً ثم احتجت للعودة إلى HTTP، سترفض المتصفحات الاتصال طوال مدة HSTS بأكملها. ابدأ بـ max-age=300 في بيئة التجريب؛ اضبط 63072000 (سنتان) في الإنتاج فقط عند الاستقرار التام.
تحديد المعدل يحجب المستخدمين الشرعيين خلف NAT: بروكسي مؤسسي يعني مئات المستخدمين يتشاركون عنوان IP واحداً. حد معدل 30 طلباً/ثانية لكل IP يصبح 0.3 طلب/ثانية لكل مستخدم. تخفيف: استخدم $http_x_forwarded_for إن كان بروكسي موثوق يضبطه، أو زد قيم burst للمسارات التي تستخدمها تطبيقات سطح المكتب.
فشل تجديد الشهادة بصمت: يُجدّد Certbot الشهادة لكن خطاف النشر لم يُجعل قابلاً للتنفيذ. النتيجة: يستمر Nginx في تقديم الشهادة القديمة حتى تنتهي صلاحيتها. نفّذ دائماً certbot renew --dry-run فور إضافة خطافات التجديد.
لا تضبط add_header داخل كتلة location وفي مستوى كتلة server في آنٍ معاً — فهما لا تُدمجان. يستبدل add_header داخل كتلة location جميع الرؤوس الموروثة من كتلة server الأصل. إذا ضبطت HSTS على مستوى server ثم أضفت أي add_header داخل كتلة location /api/، سيُسقط رأس HSTS بصمت من جميع استجابات API. الإصلاح هو تكرار جميع رؤوس الأمان المطلوبة في كل كتلة location، أو ضبطها فقط على مستوى server وعدم استخدامها أبداً داخل كتل location.
ما الذي بنيته
تُنفّذ هذه التهيئة كل طبقة من طبقات الواجهة الأمامية للإنتاج: TLS 1.2/1.3 مع تدبيس OCSP واستئناف الجلسة، وHTTP/2، وتجديد الشهادات التلقائي، وتسجيل HSTS المسبق، ومجموعة رؤوس أمان كاملة، وتخزين مؤقت للبروكسي مدعوم بالقرص مع دلالات stale-while-revalidate، وتحديد معدل لكل مسار مع هامش burst، وتجميع اتصالات keepalive للخادم الخلفي، وسجلات وصول JSON منظّمة، وفصل نظيف بين خدمة الملفات الثابتة (دون أي تورط لعملية التطبيق) والبروكسي الديناميكي. هذا هو النمط المستخدم بالضبط عبر البيئات السحابية الأصلية في شركات ذات حركة مرور عالية — بمعلمة كتلة upstream مختلفة ونطاق مختلف، يصبح الواجهة الأمامية لأي تطبيق في مكدسك.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية