شرح NGINX Reverse Proxy: ربط الدومين بتطبيقك عبر proxy

يتيح لك NGINX Reverse Proxy ربط الدومين بتطبيقك الداخلي بأمان دون كشف المنافذ. عند تشغيل تطبيق Node.js أو Python أو Laravel Octane أو خدمة داخل حاوية Docker، غالبًا يعمل التطبيق على منفذ داخلي مثل 3000 أو 8000 أو 8080. لكن الزائر لا يفترض أن يكتب اسم الدومين متبوعًا برقم المنفذ في كل مرة، كما أن تعريض منافذ التطبيقات مباشرة للإنترنت ليس دائمًا الخيار الأفضل من ناحية الأمان والإدارة.

هنا يأتي دور NGINX Reverse Proxy، حيث يستقبل NGINX طلبات الزوار على المنافذ القياسية 80 و443، ثم يمررها إلى التطبيق الخلفي الذي يعمل على منفذ داخلي باستخدام التوجيه proxy_pass.

بهذه الطريقة يستطيع الزائر فتح:

https://example.com

بينما يقوم NGINX في الخلفية بتمرير الطلب إلى:

http://127.0.0.1:3000

دون أن يعرف الزائر رقم المنفذ الداخلي أو تفاصيل البنية الخلفية للسيرفر.

في هذا الدليل سنشرح مفهوم Reverse Proxy في NGINX، وكيفية ربط الدومين بتطبيق داخلي، وطريقة استخدام proxy_pass، وأهم إعدادات تمرير الطلبات، إضافة إلى شرح أسباب أخطاء 502 Bad Gateway و504 Gateway Timeout وطريقة تشخيصها وحلها.

محتويات المقال

← ما هو NGINX؟
← ما هو Reverse Proxy؟
← ما الفرق بين Reverse Proxy وForward Proxy؟
← لماذا لا نربط الدومين بالتطبيق مباشرة؟
← ما هو proxy_pass؟
← كيف تربط الدومين بالسيرفر؟
← إنشاء ملف NGINX لتطبيق داخلي
← شرح إعدادات Reverse Proxy الأساسية
← ربط NGINX بتطبيق Node.js
← ربط NGINX بتطبيق Python وGunicorn
← ربط NGINX بحاوية Docker
← ربط مسار محدد بتطبيق خلفي
← انتبه إلى الشرطة المائلة في proxy_pass
← إعداد NGINX لدعم WebSocket
← تفعيل HTTPS أمام التطبيق
← ما معنى خطأ 502 Bad Gateway؟
← تشخيص خطأ 502 Bad Gateway
← ما معنى خطأ 504 Gateway Timeout؟
← إعداد مهلات Reverse Proxy
← كيف تفرق عمليًا بين 502 و504؟
← فحص إعدادات NGINX
← مراجعة سجلات الوصول والأخطاء
← تأمين التطبيق الخلفي
← تحديد حجم الطلبات
← تمرير الطلبات إلى أكثر من خادم
← أفضل الممارسات عند استخدام NGINX Reverse Proxy
← خطوات فحص سريعة عند توقف الموقع
← الخلاصة

ما هو NGINX؟

NGINX هو خادم ويب عالي الأداء يُستخدم لاستضافة المواقع الثابتة، وإنهاء اتصالات SSL، وتوزيع الأحمال، وتخزين المحتوى مؤقتًا، والعمل كـ Reverse Proxy أمام التطبيقات الخلفية.

يمكن أن يعمل NGINX مباشرة لعرض ملفات HTML وCSS والصور، كما يمكنه استقبال طلبات المستخدمين وتمريرها إلى تطبيق آخر يعمل على السيرفر نفسه أو على خادم مختلف.

من أشهر الاستخدامات:

استضافة المواقع الثابتة.
تشغيل مواقع WordPress مع PHP-FPM.
تمرير الطلبات إلى تطبيقات Node.js.
ربط تطبيقات Python وGunicorn بالدومين.
تمرير الطلبات إلى حاويات Docker.
إنهاء شهادات SSL وHTTPS.
توزيع الحمل بين عدة خوادم.
إضافة طبقة حماية أمام التطبيق الخلفي.

ما هو Reverse Proxy؟

يُعدّ NGINX Reverse Proxy الطريقة القياسية لنشر التطبيقات الحديثة خلف دومين واحد آمن.

الـ Reverse Proxy هو خادم وسيط يقف بين المستخدم والتطبيق الخلفي.

الطلب يمرّ عبر NGINX إلى التطبيق الداخلي

بدلًا من اتصال الزائر بالتطبيق مباشرة، يتصل الزائر بـ NGINX، ثم يتولى NGINX إرسال الطلب إلى التطبيق الداخلي وإعادة النتيجة إلى المستخدم.

يكون مسار الطلب بالشكل التالي:

الزائر
   ↓
الدومين
   ↓
DNS
   ↓
عنوان IP الخاص بالسيرفر
   ↓
NGINX على المنفذ 80 أو 443
   ↓
proxy_pass
   ↓
التطبيق الخلفي على المنفذ 3000 أو 8000

بالنسبة إلى الزائر، الموقع يعمل على الدومين بصورة طبيعية. أما داخل السيرفر، فقد يكون التطبيق يعمل على منفذ محلي غير متاح مباشرة من الإنترنت.

ما الفرق بين Reverse Proxy وForward Proxy؟

رغم تشابه الاسمين، فإن لكل منهما وظيفة مختلفة.

Forward Proxy

يعمل نيابة عن المستخدم للوصول إلى الإنترنت. يستخدم عادة لإخفاء عنوان المستخدم أو التحكم في المواقع التي يمكنه الوصول إليها.

المسار يكون:

المستخدم → Proxy → الإنترنت

Reverse Proxy

يعمل نيابة عن السيرفر أو التطبيق. يستقبل طلبات المستخدمين ثم يوجهها إلى الخادم الخلفي المناسب.

المسار يكون:

المستخدم → Reverse Proxy → التطبيق

عند استخدام NGINX أمام Node.js أو Docker أو Python، فأنت تستخدمه كـ Reverse Proxy.

لماذا لا نربط الدومين بالتطبيق مباشرة؟

افترض أن تطبيق Node.js يعمل بهذا الأمر:

node app.js

ويستمع على:

127.0.0.1:3000

يمكن نظريًا جعل المستخدم يفتح:

http://example.com:3000

لكن هذه الطريقة غير مثالية لعدة أسباب:

ظهور رقم المنفذ في رابط الموقع.
صعوبة إعداد HTTPS مباشرة في كل تطبيق.
تعريض التطبيق الخلفي للإنترنت.
عدم وجود طبقة وسيطة للتحكم بالطلبات.
صعوبة تشغيل عدة تطبيقات على عنوان IP واحد.
ضعف المرونة في إدارة التحويلات والضغط والتخزين المؤقت.
صعوبة تطبيق حدود حجم الطلب ومهلات الاتصال.

باستخدام NGINX يستطيع كل تطبيق العمل على منفذ داخلي مختلف، بينما تستخدم جميع الدومينات المنافذ القياسية 80 و443.

مثلاً:

app1.example.com → 127.0.0.1:3000
app2.example.com → 127.0.0.1:4000
api.example.com  → 127.0.0.1:8000

ما هو proxy_pass؟

التوجيه proxy_pass هو السطر الذي يخبر NGINX بالمكان الذي يجب تمرير الطلب إليه.

وproxy_pass موجّه أساسي في NGINX؛ للتوثيق الرسمي راجع دليل ngx_http_proxy_module.

مثال:

proxy_pass http://127.0.0.1:3000;

هذا يعني أن أي طلب يصل إلى هذا الجزء من إعدادات NGINX يجب تمريره إلى التطبيق الذي يستمع على المنفذ 3000 داخل السيرفر.

مثال كامل:

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

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

عندما يفتح الزائر:

http://example.com

يستقبل NGINX الطلب على المنفذ 80 ثم يمرره إلى:

http://127.0.0.1:3000

بعد ذلك يعيد NGINX استجابة التطبيق إلى الزائر.

كيف تربط الدومين بالسيرفر؟

قبل إعداد NGINX يجب توجيه الدومين إلى عنوان IP الخاص بالسيرفر من خلال سجل DNS من نوع A.

مثال:

Type: A
Name: @
Value: 203.0.113.10

ولربط www:

Type: A
Name: www
Value: 203.0.113.10

أو يمكن استخدام سجل CNAME:

Type: CNAME
Name: www
Value: example.com

بعد انتشار سجلات DNS، ستصل طلبات الدومين إلى السيرفر. عندها يحدد NGINX التطبيق الذي يجب أن يستقبل الطلب بالاعتماد على قيمة server_name.

إنشاء ملف NGINX لتطبيق داخلي

في Ubuntu وDebian غالبًا يتم إنشاء الملف داخل:

ملف إعداد مبسّط مع proxy_pass

/etc/nginx/sites-available/

مثلاً:

nano /etc/nginx/sites-available/example.com

ثم إضافة الإعدادات التالية:

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.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;
    }
}

بعد حفظ الملف، فعّله باستخدام رابط رمزي:

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com

اختبر إعدادات NGINX:

nginx -t

إذا ظهرت رسالة تفيد بأن الاختبار ناجح، أعد تحميل NGINX:

systemctl reload nginx

أو:

systemctl restart nginx

يفضل استخدام reload عندما تكون الإعدادات صحيحة، لأنه يعيد تحميلها دون قطع الاتصالات الحالية بصورة مفاجئة.

شرح إعدادات Reverse Proxy الأساسية

تحدّد هذه الإعدادات سلوك NGINX Reverse Proxy في تمرير الترويسات والاتصالات إلى التطبيق الخلفي بشكل صحيح.

listen 80

listen 80;

يعني أن NGINX يستقبل اتصالات HTTP على المنفذ 80.

وعند تفعيل HTTPS يُستخدم:

listen 443 ssl;

server_name

server_name example.com www.example.com;

يحدد الدومينات التي تنطبق عليها إعدادات هذا القسم.

location

location / {
}

يعني أن القاعدة تنطبق على جميع المسارات التي تبدأ من /.

مثل:

/
 /login
 /dashboard
 /api/users

proxy_pass

proxy_pass http://127.0.0.1:3000;

يحدد عنوان التطبيق الخلفي والمنفذ الذي يعمل عليه.

proxy_http_version

proxy_http_version 1.1;

يجعل NGINX يستخدم HTTP/1.1 عند الاتصال بالتطبيق الخلفي، وهو مهم خصوصًا لتطبيقات WebSocket والاتصالات المستمرة.

تمرير اسم الدومين

proxy_set_header Host $host;

يمرر اسم الدومين الأصلي إلى التطبيق الخلفي بدلًا من إرسال عنوان الاتصال الداخلي فقط.

تمرير عنوان IP الحقيقي للزائر

proxy_set_header X-Real-IP $remote_addr;

يمرر عنوان IP الأصلي للمستخدم إلى التطبيق.

بدون هذا السطر، قد يرى التطبيق أن جميع الطلبات قادمة من NGINX أو من 127.0.0.1.

تمرير سلسلة عناوين الوكلاء

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

يحافظ على عنوان الزائر ويضيفه إلى سلسلة البروكسي، وهو مهم عند وجود Cloudflare أو Load Balancer أمام NGINX.

تمرير نوع الاتصال

proxy_set_header X-Forwarded-Proto $scheme;

يخبر التطبيق إن كان المستخدم قد اتصل عبر HTTP أو HTTPS.

هذا مهم لتجنب مشاكل التحويلات المتكررة أو إنشاء روابط HTTP داخل موقع يعمل عبر HTTPS.

ربط NGINX بتطبيق Node.js

لنفترض أن تطبيق Node.js يعمل على:

ولتشغيل تطبيقك كخدمة دائمة، راجع: شرح systemd في Linux: كيفية إنشاء Service تعمل تلقائيًا عند إقلاع السيرفر باستخدام systemctl (Enable وDisable) – الدليل الكامل 2026.

127.0.0.1:3000

يمكن التأكد من ذلك باستخدام:

ss -tlnp | grep 3000

أو اختبار التطبيق مباشرة من داخل السيرفر:

curl http://127.0.0.1:3000

ثم يكون إعداد NGINX:

server {
    listen 80;
    server_name app.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;
    }
}

يجب تشغيل التطبيق من خلال systemd أو PM2 لضمان عودته تلقائيًا بعد إعادة تشغيل السيرفر.

ربط NGINX بتطبيق Python وGunicorn

إذا كان تطبيق Python يعمل بواسطة Gunicorn على المنفذ 8000:

gunicorn --bind 127.0.0.1:8000 app:app

يكون إعداد NGINX:

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

    location / {
        proxy_pass http://127.0.0.1:8000;

        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;
    }
}

اختبر Gunicorn قبل فحص NGINX:

curl http://127.0.0.1:8000

إذا فشل الاتصال محليًا، فالمشكلة في Gunicorn أو التطبيق، وليست في NGINX.

ربط NGINX بحاوية Docker

لنفترض أن الحاوية تعرض تطبيقًا على المنفذ الداخلي 3000، وتم ربطه بالمنفذ المحلي 127.0.0.1:3000:

docker run -d 
  --name myapp 
  -p 127.0.0.1:3000:3000 
  myapp-image

يمكن لـ NGINX تمرير الطلبات إليها:

location / {
    proxy_pass http://127.0.0.1:3000;
}

ربط المنفذ بعنوان 127.0.0.1 بدلًا من 0.0.0.0 يمنع الوصول المباشر إلى التطبيق من الإنترنت، ويجعل NGINX هو نقطة الدخول الرئيسية.

ربط مسار محدد بتطبيق خلفي

ليس من الضروري تمرير الموقع بالكامل إلى التطبيق نفسه.

يمكن تمرير المسار /api/ إلى تطبيق API:

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/example.com;
        try_files $uri $uri/ /index.html;
    }

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

في هذا المثال:

NGINX يعرض الواجهة الأمامية.
الطلبات التي تبدأ بـ /api/ تذهب إلى التطبيق الخلفي.

انتبه إلى الشرطة المائلة في proxy_pass

الفرق بين وجود الشرطة المائلة / وعدم وجودها قد يغيّر المسار الذي يصل إلى التطبيق.

مثلاً:

location /api/ {
    proxy_pass http://127.0.0.1:8000;
}

عند طلب:

/api/users

يمرر NGINX المسار كاملًا غالبًا إلى:

http://127.0.0.1:8000/api/users

أما:

location /api/ {
    proxy_pass http://127.0.0.1:8000/;
}

فقد يزيل الجزء المطابق لـ /api/ ويمرر الطلب إلى:

http://127.0.0.1:8000/users

لذلك يجب تحديد المسار الذي يتوقعه التطبيق الخلفي بدقة، لأن الخطأ في الشرطة المائلة قد يؤدي إلى ظهور خطأ 404 Not Found رغم أن التطبيق يعمل.

إعداد NGINX لدعم WebSocket

تحتاج تطبيقات WebSocket إلى تمرير ترويسات إضافية:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    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;
}

بدون هذه الترويسات قد يعمل الموقع العادي، لكن تفشل الاتصالات الفورية أو لوحات التحكم أو تطبيقات المحادثة.

تفعيل HTTPS أمام التطبيق

يتولّى NGINX Reverse Proxy إنهاء اتصال HTTPS نيابةً عن التطبيق الخلفي، فيبقى التطبيق بسيطًا وسريعًا.

من أهم فوائد Reverse Proxy أن NGINX يستطيع إدارة شهادة SSL، بينما يستمر التطبيق بالعمل داخليًا عبر HTTP.

يكون المسار:

الزائر عبر HTTPS
        ↓
NGINX يفك تشفير SSL
        ↓
HTTP داخلي إلى 127.0.0.1:3000

يمكن تثبيت Certbot على Ubuntu أو Debian، ثم إصدار الشهادة:

certbot --nginx -d example.com -d www.example.com

بعد نجاح العملية، يضيف Certbot إعدادات HTTPS إلى NGINX.

مثال مبسط:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    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;
    }
}

ما معنى خطأ 502 Bad Gateway؟

يظهر خطأ 502 Bad Gateway عندما يعمل NGINX ويستقبل الطلب، لكنه لا يستطيع الحصول على استجابة صحيحة من التطبيق الخلفي.

ولحل 502 بعد إعادة التشغيل تحديدًا، راجع: حل مشكلة 502 Bad Gateway بعد إعادة تشغيل السيرفر (NGINX وPHP-FPM وNode.js): الدليل الكامل للتشخيص والإصلاح في 2026.

بمعنى آخر:

الزائر وصل إلى NGINX بنجاح
لكن NGINX لم يصل إلى Backend

من أشهر الأسباب:

التطبيق الخلفي متوقف.
المنفذ غير صحيح.
الخدمة لم تبدأ بعد إعادة تشغيل السيرفر.
NGINX يستخدم Socket غير موجود.
التطبيق انهار أثناء معالجة الطلب.
صلاحيات Socket غير صحيحة.
التطبيق يستمع على عنوان مختلف.
جدار الحماية يمنع الاتصال إذا كان Backend على خادم آخر.

إذا كان NGINX يستخدم:

proxy_pass http://127.0.0.1:3000;

لكن التطبيق يعمل على المنفذ 4000، فستظهر رسالة 502.

تشخيص خطأ 502 Bad Gateway

ابدأ بالتحقق من NGINX:

systemctl status nginx

ثم افحص التطبيق الخلفي:

systemctl status myapp

أو إذا كنت تستخدم PM2:

pm2 status

تحقق من المنفذ:

ss -tlnp | grep 3000

اختبر التطبيق مباشرة:

curl -I http://127.0.0.1:3000

راجع سجل NGINX:

tail -50 /var/log/nginx/error.log

قد تجد:

connect() failed (111: Connection refused) while connecting to upstream

وهذا يعني غالبًا أن التطبيق لا يستمع على العنوان أو المنفذ المحدد.

وقد تجد:

upstream prematurely closed connection

وهذا يعني أن التطبيق أغلق الاتصال قبل إرسال استجابة مكتملة.

ما معنى خطأ 504 Gateway Timeout؟

يظهر خطأ 504 Gateway Timeout عندما يتمكن NGINX من الاتصال بالتطبيق الخلفي، لكن التطبيق يستغرق وقتًا أطول من المهلة المحددة للرد.

الفرق الأساسي:

502: لا توجد استجابة صالحة من Backend أو تعذر الاتصال به.
504: تم الوصول إلى Backend، لكنه تأخر في الرد.

من أسباب خطأ 504:

استعلام قاعدة بيانات بطيء.
التطبيق ينفذ عملية ثقيلة.
API خارجي لا يستجيب.
موارد السيرفر غير كافية.
ارتفاع Load Average.
امتلاء الذاكرة واستخدام Swap بكثرة.
مهلة NGINX قصيرة مقارنة بطبيعة الطلب.

إعداد مهلات Reverse Proxy

ضبط المهلات جزء أساسي من تشغيل NGINX Reverse Proxy مستقر يتحمّل الطلبات الطويلة دون خطأ 504.

يمكن تعديل المهلات داخل location:

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_connect_timeout 10s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;

    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_connect_timeout

المدة التي ينتظرها NGINX لإنشاء اتصال مع التطبيق الخلفي.

proxy_send_timeout

المدة المسموحة لإرسال الطلب إلى Backend.

proxy_read_timeout

المدة التي ينتظرها NGINX بين عمليات قراءة البيانات من التطبيق الخلفي.

رفع proxy_read_timeout قد يخفي المشكلة مؤقتًا، لكنه لا يعالج السبب الحقيقي إذا كان التطبيق أو قاعدة البيانات بطيئين. يجب تحليل الأداء قبل زيادة المهلة بصورة كبيرة.

كيف تفرق عمليًا بين 502 و504؟

إذا نفذت:

خطآن مختلفان بسببين مختلفين

curl http://127.0.0.1:3000

وظهرت:

Connection refused

فالمشكلة أقرب إلى 502، لأن التطبيق غير متاح.

أما إذا بقي الأمر ينتظر وقتًا طويلًا قبل ظهور الاستجابة، فالمشكلة أقرب إلى 504 أو بطء التطبيق.

فحص إعدادات NGINX

قبل إعادة التحميل، تأكد دائمًا من صحة إعدادات NGINX Reverse Proxy لتفادي تعطّل الموقع.

بعد أي تعديل نفذ:

nginx -t

إذا كانت الإعدادات صحيحة ستظهر نتيجة مشابهة:

syntax is ok
test is successful

ثم أعد التحميل:

systemctl reload nginx

لا تعِد تشغيل NGINX قبل اختبار الإعدادات، لأن وجود خطأ نحوي قد يمنع الخدمة من العودة للعمل.

مراجعة سجلات الوصول والأخطاء

ملفات السجل الافتراضية غالبًا هي:

/var/log/nginx/access.log
/var/log/nginx/error.log

لمتابعة سجل الأخطاء مباشرة:

tail -f /var/log/nginx/error.log

ولمتابعة طلبات الزوار:

tail -f /var/log/nginx/access.log

يمكن أيضًا تحديد سجل منفصل لكل دومين:

access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;

وهذا يسهل تشخيص المشاكل عند استضافة عدة تطبيقات على السيرفر نفسه.

تأمين التطبيق الخلفي

من أهم فوائد NGINX Reverse Proxy إخفاء منفذ التطبيق الداخلي ومنع الوصول المباشر إليه من الإنترنت.

يفضل جعل التطبيق يستمع على 127.0.0.1 بدلًا من 0.0.0.0 عندما يكون NGINX موجودًا على السيرفر نفسه.

استخدم:

127.0.0.1:3000

بدلًا من:

0.0.0.0:3000

لأن 0.0.0.0 قد يجعل التطبيق متاحًا على جميع واجهات الشبكة، وقد يتم الوصول إليه مباشرة باستخدام IP والمنفذ.

إذا اضطررت إلى تشغيل Backend على خادم منفصل، استخدم شبكة خاصة أو قواعد Firewall تسمح بالاتصال من عنوان NGINX فقط.

تحديد حجم الطلبات

قد تحتاج تطبيقات رفع الملفات إلى زيادة الحد:

client_max_body_size 100M;

يمكن وضعه داخل server أو location.

إذا كان الحجم أكبر من الحد المسموح، يظهر غالبًا:

413 Request Entity Too Large

تمرير الطلبات إلى أكثر من خادم

يمكن استخدام NGINX Reverse Proxy كموازن أحمال يوزّع الطلبات على أكثر من خادم خلفي لزيادة الأداء والتوفّر.

يمكن استخدام NGINX أيضًا لتوزيع الحمل:

upstream backend_servers {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_servers;

        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;
    }
}

في هذا المثال يوزع NGINX الطلبات بين تطبيقين يعملان على منفذين مختلفين.

هذا مفيد عند تشغيل عدة نسخ من التطبيق لزيادة القدرة على استقبال الطلبات وتقليل الضغط على عملية واحدة.

أفضل الممارسات عند استخدام NGINX Reverse Proxy

اجعل التطبيق الخلفي يستمع على عنوان محلي أو شبكة خاصة.
استخدم systemd أو PM2 لضمان تشغيل التطبيق بعد إعادة تشغيل السيرفر.
مرر ترويسات Host وX-Real-IP وX-Forwarded-For.
استخدم HTTPS لحماية بيانات المستخدمين.
اختبر التطبيق مباشرة باستخدام curl قبل اتهام NGINX.
نفذ nginx -t قبل إعادة تحميل الإعدادات.
راقب سجلات NGINX وسجلات التطبيق معًا.
لا ترفع المهلات بشكل عشوائي لمعالجة خطأ 504.
اربط كل دومين بملف إعداد منفصل لتسهيل الإدارة.
احجب المنافذ الداخلية عن الوصول العام.
استخدم Health Check لمراقبة جاهزية التطبيق.
تأكد من تفعيل الخدمة باستخدام systemctl enable.

خطوات فحص سريعة عند توقف الموقع

عند أي توقف، ابدأ بفحص حالة NGINX Reverse Proxy والتطبيق الخلفي والمنافذ والسجلات بالترتيب.

نفذ الأوامر التالية بالترتيب:

وتوفّر مرام هوست خوادم VPS وDedicated مثالية لتشغيل NGINX Reverse Proxy أمام تطبيقات Node.js وPython وDocker بأداء وأمان عاليين.

وللفحص الشامل، راجع: الدليل الكامل لفحص صحة السيرفر (Server Health Check): أهم أوامر Linux لتشخيص الأعطال ومراقبة الأداء في 2026.

systemctl status nginx

ثم:

nginx -t

ثم افحص منفذ التطبيق:

ss -tlnp

اختبر Backend مباشرة:

curl -I http://127.0.0.1:3000

راجع سجل NGINX:

tail -50 /var/log/nginx/error.log

راجع سجل التطبيق:

journalctl -u myapp -n 50 --no-pager

تحقق من الموارد:

free -h
df -h
uptime

هذه الخطوات تكشف معظم مشاكل Reverse Proxy وأخطاء 502 و504 خلال وقت قصير.

الخلاصة

يعمل NGINX Reverse Proxy كحلقة وصل بين الدومين والتطبيق الخلفي. يستقبل طلبات الزوار على المنافذ القياسية 80 و443، ثم يستخدم proxy_pass لإرسالها إلى تطبيق يعمل على منفذ داخلي مثل 3000 أو 8000.

باختصار، يمنحك NGINX Reverse Proxy عبر proxy_pass طريقة نظيفة وآمنة لربط الدومين بتطبيقاتك الداخلية مع HTTPS وموازنة الأحمال. وإتقان NGINX Reverse Proxy ضروري لكل من ينشر تطبيقات Node.js وPython وDocker على خادمه.

يتيح هذا الأسلوب تشغيل تطبيقات Node.js وPython وLaravel وDocker خلف اسم نطاق احترافي، وإضافة HTTPS، وإخفاء المنافذ الداخلية، وتمرير عنوان IP الحقيقي للزائر، وإدارة عدة تطبيقات على عنوان IP واحد.

عند ظهور خطأ 502 Bad Gateway يجب التحقق من تشغيل Backend وصحة المنفذ وإعداد proxy_pass. أما خطأ 504 Gateway Timeout فيشير غالبًا إلى أن التطبيق الخلفي تأخر في إرسال الاستجابة.

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

هل تبحث عن استضافة موثوقة لموقعك؟

شركة مرام هوست تقدم أفضل حلول الاستضافة والسيرفرات بدعم فني عربي 24/7

اكتشف خدماتنا ←

شرح NGINX Reverse Proxy: كيف يربط الدومين بتطبيقك الداخلي باستخدام proxy_pass؟ الدليل الكامل 2026

ما هو NGINX؟

ما هو Reverse Proxy؟

ما الفرق بين Reverse Proxy وForward Proxy؟

Forward Proxy

Reverse Proxy

لماذا لا نربط الدومين بالتطبيق مباشرة؟

ما هو proxy_pass؟

كيف تربط الدومين بالسيرفر؟

إنشاء ملف NGINX لتطبيق داخلي

شرح إعدادات Reverse Proxy الأساسية

listen 80

server_name

location

proxy_pass

proxy_http_version

تمرير اسم الدومين

تمرير عنوان IP الحقيقي للزائر

تمرير سلسلة عناوين الوكلاء

تمرير نوع الاتصال

ربط NGINX بتطبيق Node.js

ربط NGINX بتطبيق Python وGunicorn

ربط NGINX بحاوية Docker

ربط مسار محدد بتطبيق خلفي

انتبه إلى الشرطة المائلة في proxy_pass

إعداد NGINX لدعم WebSocket

تفعيل HTTPS أمام التطبيق

ما معنى خطأ 502 Bad Gateway؟

تشخيص خطأ 502 Bad Gateway

ما معنى خطأ 504 Gateway Timeout؟

إعداد مهلات Reverse Proxy

proxy_connect_timeout

proxy_send_timeout

proxy_read_timeout

كيف تفرق عمليًا بين 502 و504؟

فحص إعدادات NGINX

مراجعة سجلات الوصول والأخطاء

تأمين التطبيق الخلفي

تحديد حجم الطلبات

تمرير الطلبات إلى أكثر من خادم

أفضل الممارسات عند استخدام NGINX Reverse Proxy

خطوات فحص سريعة عند توقف الموقع

الخلاصة