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

هذا المقال يتطلب مستوى: مبتدئ

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

لو تطبيقك شغّال على المنفذ 3000 ومربوط بالإنترنت مباشرة، إنت فاتح باب لثلاث مشاكل: مفيش HTTPS، مفيش حماية، ولو التطبيق وقع الموقع كله يقع. بعد المقال ده هتعرف تحط بوابة واحدة قدامه تحل التلاتة في أقل من 10 دقايق.

المشكلة باختصار

لما تشغّل تطبيق Node أو Python، هو بيسمع على منفذ زي 3000. أسهل طريقة إنك تربط الدومين بالسيرفر على المنفذ ده والدنيا تمشي. لكن ساعتها كل زائر بيكلّم تطبيقك على طول. يعني تطبيقك هو اللي لازم يتعامل مع الـ HTTPS، ومع الزحمة، ومع أي طلب خبيث. ولو عندك أكتر من نسخة من التطبيق، مفيش حاجة بتوزّع عليهم.

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

يعني إيه Reverse Proxy؟ نبدأ بمثال

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

الـ Reverse Proxy هو موظف الاستقبال ده بالظبط. العميل (المتصفح) بيوصل للبوابة، والبوابة بتقرر تبعت الطلب لأنهي نسخة من تطبيقك، وترجّع الرد. العميل مش عارف مين اللي ردّ عليه فعلاً.

دلوقتي بالتعريف الدقيق: الـ Reverse Proxy هو خادم وسيط بيستقبل طلبات العملاء نيابةً عن خادم واحد أو أكتر في الخلف، وبيمرّر الردود للعميل. الفرق بينه وبين الـ Forward Proxy إن الـ Forward بيقف جنب العميل ويخفيه (زي VPN)، أما الـ Reverse فبيقف جنب الخادم ويخفيه. الاتجاه معكوس، ومن هنا جه الاسم.

الأربع حاجات اللي بيعملهالك

1. إنهاء الـ TLS (HTTPS): البوابة هي اللي بتحمل شهادة SSL وبتفك تشفير الطلب، فتطبيقك يشتغل HTTP عادي في الداخل من غير ما تلمس كوده. تركّب الشهادة في مكان واحد بدل ما تكررها في كل نسخة.
2. موازنة الحمل (Load Balancing): لو عندك 3 نسخ من التطبيق، البوابة بتوزّع الطلبات عليهم بالتساوي. لو نسخة وقعت، بتوقف عن إرسال الطلبات ليها لوحدها.
3. التخزين المؤقت (Caching): الملفات الثابتة زي الصور وملفات CSS ممكن البوابة تحتفظ بيها وترجّعها من غير ما تتعب تطبيقك في كل مرة.
4. تحديد معدل الطلبات (Rate Limiting): تقدر تقول "أقصى 20 طلب في الثانية من نفس الآيبي" فتحمي تطبيقك من الزحمة المفاجئة أو محاولات الإساءة.

مثال تنفيذي: NGINX قدام تطبيقك

ده أبسط إعداد. تطبيقك شغّال على 127.0.0.1:3000، وNGINX هيستقبل من النت ويمرّر ليه. حط الإعداد ده في /etc/nginx/sites-available/app.conf:

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.

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

# فعّل الموقع
sudo ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/

# اختبر الصياغة الأول — لو فيه غلطة هيقولك قبل ما تكسر حاجة
sudo nginx -t

# أعد التحميل بدون قطع الاتصالات الشغّالة
sudo systemctl reload nginx

# HTTPS مجاني في دقيقة — Certbot بيعدّل الإعداد لوحده
sudo certbot --nginx -d app.example.com

# تأكد إنه شغّال
curl -I https://app.example.com

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

upstream app_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
}

server {
    listen 80;
    server_name app.example.com;
    location / {
        proxy_pass http://app_backend;   # NGINX هيوزّع بينهم بالتناوب
    }
}

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

خلّي بالك، الأرقام دي تقديرية للتوضيح وبتفرق حسب تطبيقك. لو موقعك بياخد 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