المستوى: مبتدئ

لو تطبيق Node.js أو Django عندك شغّال على بورت 3000 وفتحت الـ firewall ليه مباشرة، انت غالبًا بتدفع ضريبة 3 مشاكل في وقت واحد: HTTPS متعب، أي DDoS صغير بيقع السيرفر، ومش قادر تحط أكتر من تطبيق على نفس الجهاز. Reverse Proxy بـ NGINX بيحلّ التلاتة بـ 15 سطر إعداد فقط.

Reverse Proxy: ليه محتاجه أصلًا

تخيّل إنك بتدير عيادة فيها 4 أطباء. لو كل مريض دخل العيادة بيدوّر بنفسه على الدكتور الصح، هتحصل فوضى: مرضى تايهين في الطرقات، أطباء بيتقاطعوا، وحد بدون موعد ممكن يدخل عند أي حد. سكرتيرة الاستقبال بتاخد المريض، تشوف هو محتاج إيه، وتوجّهه للدكتور المناسب. كمان لو في زبون مزعج بيحاول يدخل بدون موعد، السكرتيرة بترفض من قبل ما يتعب الأطباء.

NGINX قدّام تطبيقك بيلعب دور سكرتيرة الاستقبال دي بالظبط. هو بيستقبل كل طلبات الإنترنت على بورت 80 و 443، يشوف الطلب رايح فين، ويوجّهه لتطبيقك الداخلي على البورت بتاعه. تطبيقك يفضل مخفي ومش متعرّض للإنترنت مباشرة، وأي طلب ضارّ بيتفلتر قبل ما يوصلّه.

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

تطبيق Express أو Django أو Flask بشكل افتراضي بيستمع على بورت زي 3000 أو 8000. ده بورت غير قياسي، ومحدش بيكتب http://example.com:3000 في المتصفح. عشان كده انت محتاج حاجة تشتغل على بورت 80 (HTTP القياسي) و 443 (HTTPS) وتحوّل الطلبات لتطبيقك.

الحل اللي بيتقال أحيانًا للمبتدئ هو إنك تشغّل تطبيقك مباشرة على بورت 80. الطريقة دي بتفشل في 3 حالات: محتاجة صلاحيات root خطيرة (لأن أي بورت أقل من 1024 محجوز للنظام)، مش بتدعم HTTPS بسهولة، وميقدرش يكون عندك تطبيق تاني على نفس السيرفر.

المفهوم بشكل علمي ودقيق

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

الافتراض إن عندك سيرفر Linux واحد على الأقل بـ NGINX أو Caddy أو Traefik مثبّت، وتطبيق واحد أو أكثر بتشتغل على بورتات داخلية (3000، 4000، 5000…) ومش بتسمع على الـ public IP مباشرة.

إعداد NGINX كـ Reverse Proxy في 15 سطر

بعد ما تثبّت NGINX على Ubuntu بأمر sudo apt install nginx، افتح ملف /etc/nginx/sites-available/myapp وحط فيه الإعداد ده:

server {
    listen 80;
    server_name example.com;

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

بعدها نشّط الإعداد بأمرين:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

الأمر nginx -t بيتحقق من صحة الإعداد قبل التطبيق. خطوة بسيطة لكن بتمنع كوارث: لو فيه typo، النظام مش هيقبل reload، وكل التطبيقات الشغّالة هتفضل شغّالة.

إيه اللي كل سطر بيعمله

• listen 80: NGINX يستمع على بورت HTTP القياسي.
• server_name example.com: الإعداد ده ينطبق فقط على الدومين ده (مفيد لو عندك أكتر من موقع).
• proxy_pass: لمّا يجي طلب، حوّله للتطبيق الداخلي على بورت 3000.
• X-Real-IP و X-Forwarded-For: مهم جدًا، لأن من غيرهم تطبيقك هيشوف كل الطلبات جاية من 127.0.0.1 مش من الزائر الحقيقي.

إيه اللي بتكسبه فعلًا

1. HTTPS مجاني وآلي: تثبّت Certbot وبأمر واحد بيدير شهادات Let's Encrypt على NGINX ويعمل auto-renewal كل 60 يوم. تطبيقك مش بيشوف أي شيء عن SSL، وده بيخفّف عبء حسابي بحوالي 4-7% من CPU.
2. أكتر من تطبيق على سيرفر واحد: ضيف server block جديد لكل دومين، كل واحد بيوجّه لبورت داخلي مختلف. سيرفر VPS بـ 10$ يقدر يستضيف 5 تطبيقات صغيرة بدلاً من واحد.
3. Rate limiting بسطر واحد: توجيه limit_req_zone بيوقف 5000 طلب/ثانية من نفس الـ IP قبل ما يوصلوا تطبيقك. بدون كده، أي حد بسكريبت بسيط ممكن يقع السيرفر.
4. Static files أسرع 8 مرات: NGINX بيقدّم الصور والـ CSS والـ JS مباشرة من الديسك بدون ما يلمس Node.js. ده بيقلل الحمل على تطبيقك بنسبة كبيرة لو موقعك فيه أصول كتيرة.

الـ Trade-off اللي لازم تفهمه

الإضافة دي مش مجانية. أنت بتدفع 3 تكاليف:

• طبقة شبكة جديدة بتضيف 0.4ms - 1.2ms latency لكل طلب. غير ملحوظ في تطبيقات الويب العادية، لكن لو بتعمل High-Frequency Trading أو لعبة realtime، ده مهم.
• إعداد إضافي تحتاج تتعلّمه: directives في nginx.conf ليها قواعد خاصة، والـ documentation طويل وبيحتاج صبر.
• نقطة فشل واحدة (SPOF): لو NGINX قع، كل تطبيقاتك بتقع. الحل البسيط: systemd بيعمل restart تلقائي. الحل المتقدّم: load balancer قدام كذا instance من NGINX (لكن ده مرحلة تالية).

متى لا تستخدم Reverse Proxy

في حالات قليلة جدًا ميكونش محتاج:

• لو سيرفرك خاص بـ API داخلي بين خدمتين على نفس الجهاز، ومش هيتعرّض للإنترنت أبدًا، الموضوع overhead زيادة.
• لو بتستخدم منصة PaaS زي Vercel أو Heroku أو Railway، هي عاملة Reverse Proxy بنفسها وأنت مش محتاج تعدّ نفسك.
• لو بتشغّل تطبيق محلي على جهازك للتطوير فقط على localhost:3000، مفيش داعي.

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

اعمل الخطوات دي على سيرفر تجريبي قبل الإنتاج: ثبّت NGINX، شغّل تطبيق Node.js بسيط على بورت 3000 (node server.js)، حط الـ config أعلاه، اعمل reload، وادخل على الدومين بتاعك من المتصفح. لو الصفحة ظهرت من غير ذكر بورت 3000 في الـ URL، انت كده فاهم Reverse Proxy ومستفيد منه. بعدها ضيف Certbot للـ HTTPS وانت كده بنيت أساس production-ready مش هيحرجك في أول مستخدم بيدخل بـ HTTPS.

المصادر

• NGINX Documentation — Module ngx_http_proxy_module: nginx.org
• Let's Encrypt — Getting Started Guide: letsencrypt.org
• Cloudflare Learning — What is a Reverse Proxy: cloudflare.com
• RFC 7230 — HTTP/1.1 Message Syntax and Routing: datatracker.ietf.org
• DigitalOcean — How To Use NGINX as a Reverse Proxy: digitalocean.com