الـ Reverse Proxy للمبتدئ: ليه بتحط NGINX قدام تطبيقك؟

server {
    listen 80;
    server_name app.example.com;

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

سطور الـ proxy_set_header دي مهمة: من غيرها تطبيقك هيشوف كل الطلبات جاية من 127.0.0.1، ومش هيعرف الآيبي الحقيقي للزائر ولا إن الاتصال كان HTTPS.

فعّل الإعداد واختبره قبل ما تعيد التشغيل:

عايز توزيع الحمل على أكتر من نسخة؟ عرّف مجموعة خوادم وبدّل الـ proxy_pass يشاور عليها:

سيناريو واقعي بالأرقام

خلّي بالك، الأرقام دي تقديرية للتوضيح وبتفرق حسب تطبيقك. لو موقعك بياخد 50 ألف زائر في اليوم، ونسخة واحدة من تطبيقك بتقدر تخدم حوالي 500 طلب في الثانية وقت الذروة. لو الذروة عدّت الرقم ده، الزوار يبدأوا يستنّوا أو ياخدوا أخطاء.

تحط Reverse Proxy قدام 3 نسخ، فالسقف النظري يبقى حوالي 1500 طلب في الثانية. وتخلّي البوابة تعمل cache للملفات الثابتة، فممكن تشيل عن تطبيقك حوالي 60 إلى 70 بالمية من الطلبات لأنها ملفات مكررة مش محتاجة تطبيقك أصلاً. كمان الـ TLS handshake — اللي بياخد عشرات المللي ثانية — بيحصل مرة واحدة عند البوابة بدل ما يتكرر على كل نسخة.

الـ trade-off وما يجب الانتباه له

مفيش حاجة ببلاش. البوابة بتضيف قفزة شبكة زيادة قبل ما توصل لتطبيقك — عادةً بتكلّف من 1 لـ 2 مللي ثانية لو البوابة والتطبيق على نفس السيرفر. المكسب: HTTPS مركزي، توزيع حمل، وحماية. الخسارة: طبقة زيادة تظبطها وتصونها.

وفيه نقطة مهمة: البوابة نفسها بقت نقطة فشل واحدة. لو NGINX وقع، الموقع كله وقع حتى لو نسخ التطبيق شغّالة. الحل لما تكبر: تشغّل بوابتين مع keepalived يتبادلوا الآيبي لو واحدة وقعت. للمواقع الصغيرة، بوابة واحدة كفاية.

متى لا تستخدم هذه الطريقة

مش كل حالة محتاجة الكلام ده. لو عندك أداة داخلية بيستخدمها 5 أشخاص على شبكة مقفولة ومش محتاجة HTTPS، البوابة تعقيد زيادة. وكمان لو إنت شغّال على منصة مُدارة زي Vercel أو Cloud Run أو خلف Load Balancer جاهز من مزود السحابة (زي AWS ALB)، فإنت أصلاً عندك Reverse Proxy شغّال، متحطّش واحد تاني فوقه من غير سبب.

الخطوة التالية

افتح سيرفرك دلوقتي وشوف تطبيقك شغّال على أنهي منفذ. انسخ إعداد NGINX اللي فوق، بدّل app.example.com بدومينك و3000 بمنفذك، وشغّل sudo nginx -t. لو طلعلك syntax is ok، إنت على بعد أمر واحد (reload) من إن تطبيقك يبقى ورا بوابة محترمة. لو ظهرلك خطأ، ابعتلي نص الرسالة.

المصادر

• NGINX — دليل الـ Reverse Proxy الرسمي: docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy
• NGINX — موازنة الحمل (HTTP Load Balancing): docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer
• Cloudflare — What is a reverse proxy: cloudflare.com/learning/cdn/glossary/reverse-proxy
• MDN — Proxy servers and tunneling: developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling
• Certbot (Let's Encrypt) — تركيب HTTPS تلقائيًا مع NGINX: certbot.eff.org/instructions