بروكسي nginx العكسي: دليل إعداد شامل

بروكسي nginx العكسي هو خادم nginx يقبل الطلبات الواردة نيابة عن تطبيق خلفي واحد أو أكثر، ثم يمرر كل طلب إلى الخلفية الصحيحة ويعيد الاستجابة إلى العميل. يقدم لك هذا الدليل إعداد nginx كبروكسي عكسي كاملا وجاهزا للنسخ: كتلة خادم كاملة تتضمن proxy_pass والرؤوس الممررة، وموازنة تحميل upstream، وإنهاء SSL، ودعم WebSocket، وضبط التخزين المؤقت والمهلات، وgzip، والتوجيه حسب location، وحلول أخطاء 502 و504 التي تربك معظم الناس.

في النهاية، سيكون لديك إعداد nginx عامل كبروكسي عكسي، وفهم واضح لكيفية ترابط الأجزاء، ورؤية واقعية للموضع الذي يتوقف فيه بروكسي nginx العكسي عن كونه الأداة المناسبة ويحل محله بروكسي أمامي أو سكني.

DataImpulse مزود أخلاقي لخدمات البروكسي، يتيح أكثر من 90 مليون عنوان IP سكني ومحمول ومركز بيانات في 195 دولة. يستخدم نموذجا للدفع حسب الاستخدام يبدأ من 1 دولار لكل GB مع حركة مرور لا تنتهي صلاحيتها، ويستخدم في تجريف الويب، والتحقق من الإعلانات، ومراقبة الأسعار، وأبحاث السوق، وإدارة حسابات متعددة.

هل nginx بروكسي عكسي، وكيف يعمل؟

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

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

• المستمع. تحدد توجيهات listen وserver_name الطلبات التي تملكها هذه الكتلة، أي المنفذ 80 والمنفذ 443 واسم المضيف.
• توجيه Location. تقسم كتل location المسارات الواردة كي يمكن أن يذهب كل من /api/ و/static/ و/ إلى وجهة مختلفة.
• Upstream. تسمي كتلة upstream مجموعة الخوادم الخلفية وطريقة موازنة التحميل.
• الرؤوس. تحافظ أسطر proxy_set_header على Host الأصلي وعنوان IP للعميل كي ترى الخلفية الطلب الحقيقي، لا nginx.
• TLS. ينهي ssl_certificate على listen 443 اتصال HTTPS في nginx كي تتواصل الخلفيات عبر HTTP عادي داخليا.

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

ما الذي تحتاجه قبل البدء؟

تحتاج إلى خادم Linux مثبت عليه nginx، وتطبيقا خلفيا واحدا على الأقل يستمع على منفذ محلي، ولـ HTTPS شهادة TLS. تستخدم الوكالة العكسية بنية nginx القياسية فقط، لذلك لا تحتاج إلى وحدات مخصصة أو إعادة تجميع.

تأكد من وجود nginx ومن صحة إعداداتك قبل تعديل أي شيء:

nginx -v
sudo nginx -t

يحلل اختبار nginx -t الإعداد كاملا ويبلغ عن أخطاء الصياغة مع الملف ورقم السطر. شغله بعد كل تغيير في هذا الدليل، لأن nginx سيرفض إعادة تحميل إعداد معيب ويترك الإعداد السابق عاملا. ضع كتل خادم البروكسي العكسي في /etc/nginx/conf.d/ أو /etc/nginx/sites-available/ بحسب توزيعتك، وأعد التحميل عبر sudo nginx -s reload بعد نجاح الاختبار. جهز عنوان الخلفية أيضا، مثل تطبيق Node أو Python على 127.0.0.1:3000، لأنه العنوان الذي سيشير إليه proxy_pass.

كيف تعد بروكسي nginx عكسيا خطوة بخطوة؟

ابدأ بكتلة خادم واحدة تستمع على المنفذ 80، وتمرر كل طلب إلى خلفية واحدة عبر proxy_pass، وتضبط الرؤوس الممررة. ثم أضف موازنة التحميل وTLS وWebSockets والتخزين المؤقت وgzip. هذه الكتلة الأولى هي الحد الأدنى العامل لإعداد 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 الأربعة هذه ليست اختيارية. من دونها ترى الخلفية nginx بوصفه العميل، وتسجل عنوان IP خاطئا، وقد تنشئ عناوين URL لإعادة التوجيه معيبة. يحافظ Host على اسم المضيف المطلوب، ويحمل X-Real-IP وX-Forwarded-For عنوان العميل الحقيقي، ويخبر X-Forwarded-Proto التطبيق إن كان الطلب الأصلي HTTP أو HTTPS.

أضف موازنة تحميل upstream. للوقوف أمام عدة مثيلات خلفية، عرف كتلة upstream واجعل proxy_pass يشير إلى اسمها. ترسل طريقة least_conn كل طلب إلى المثيل ذي أقل عدد من الاتصالات النشطة:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

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

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

لا يتلقى خادم backup حركة المرور إلا عند تعطل الخوادم الأساسية. استبدل least_conn بـ ip_hash إذا احتجت إلى تثبيت العميل نفسه على الخلفية ذاتها للجلسات الثابتة.

أنه SSL على المنفذ 443. ينبغي للبروكسيات العكسية الإنتاجية أن تقدم HTTPS وأن تعيد توجيه HTTP العادي. يدير nginx TLS كي تبقى خلفياتك على HTTP عادي داخليا:

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

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

ادعم WebSockets. تبدأ اتصالات WebSocket بصيغة HTTP ثم تترقى، لذا يحتاج nginx إلى تمرير رأسي Upgrade وConnection واستخدام HTTP/1.1. امنح المسارات الفورية location خاصا بها:

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

يبقي proxy_read_timeout الطويل المقابس الخاملة من الإغلاق أثناء الجلسة، وهو سبب شائع لانقطاع الاتصالات الحية.

اضبط التخزين المؤقت والمهلات. القيم الافتراضية متحفظة، وتستفيد الخلفيات البطيئة من قيم صريحة كي لا يغلق nginx الاتصال قبل استجابة التطبيق:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

فعل gzip. يؤدي ضغط الاستجابات الممررة إلى خفض النطاق الترددي للأصول النصية. ضع هذا في كتلة http كي ينطبق على الموقع كله:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

وجه حسب المسار. يمكن لبروكسي عكسي واحد أن يقف أمام عدة خدمات بمطابقة بادئات location مختلفة مع upstream مختلفة، وأن يقدم الملفات الثابتة مباشرة من القرص من دون لمس خلفية:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

كيف تتحقق من عمل بروكسي nginx العكسي؟

أعد تحميل nginx، ثم أرسل طلبا إلى اسم المضيف العام وتأكد من أن الاستجابة تأتي من الخلفية بدلا من صفحة nginx الافتراضية. اختبر الإعداد أولا كي لا يؤدي خطأ مطبعي إلى توقف الموقع:

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

تعني استجابة 200 أو إعادة توجيه متوقعة في رؤوس الاستجابة أن التوجيه يعمل. وللتأكد من أن الخلفية تتلقى الرؤوس الممررة، افحص سجل الوصول الخاص بها أو نقطة نهاية صدى وتحقق من أنها ترى عنوان IP الحقيقي للعميل من X-Forwarded-For، لا 127.0.0.1. يمكنك أيضا تجاوز DNS واستهداف البروكسي مباشرة مع انتحال اسم المضيف:

curl -H "Host: app.example.com" http://127.0.0.1

بالنسبة إلى HTTPS، شغل curl -I https://app.example.com وتحقق من قبول الشهادة ومن عدم تخفيض مستوى الطلب. إذا عرضت الخلفية الروابط أو إعادات التوجيه بمخطط خاطئ، فذلك يكاد يكون دائما بسبب غياب رأس X-Forwarded-Proto لا بسبب عطل TLS.

كيف تعالج أخطاء 502 و504؟

يعني خطأ 502 بوابة غير صالحة أن nginx وصل إلى upstream لكنه تلقى استجابة غير صالحة أو مرفوضة، بينما يعني خطأ 504 انتهاء مهلة البوابة أن upstream قبل الاتصال لكنه لم يجب في الوقت المحدد. كلتاهما مشكلتان في upstream وليستا أخطاء nginx، ويسمي سجل الأخطاء السبب الدقيق. راقبه مباشرة أثناء إعادة إنتاج الطلب:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

اعمل على الأسباب المعتادة بالترتيب:

• 502، اتصال مرفوض. الخلفية لا تعمل أو تستمع على عنوان أو منفذ مختلف عن هدف proxy_pass. تحقق عبر curl http://127.0.0.1:3000 على الخادم نفسه.
• 502، SELinux أو جدار الحماية. في أنظمة عائلة RHEL، يمنع SELinux nginx من فتح الاتصالات الخارجية إلى أن تشغل setsebool -P httpd_can_network_connect 1.
• 504، خلفية بطيئة. يستغرق التطبيق وقتا أطول من proxy_read_timeout للاستجابة. زد المهلة لذلك location، أو أصلح الاستعلام البطيء، بدلا من إخفاء المشكلة عالميا.
• 502، رؤوس كبيرة. قد تؤدي الخلفية التي ترسل رؤوس استجابة كبيرة إلى تجاوز مخازن البروكسي. زد proxy_buffer_size وproxy_buffers.
• اختيار upstream خاطئ. إذا تعطل خادم في مجموعة upstream، يضع nginx علامة عدم الصحة عليه ويعيد المحاولة مع التالي، لذا تشير أخطاء 502 المتقطعة غالبا إلى خلفية واحدة غير سليمة.

أي بروكسي عكسي يناسبك، ومتى تحتاج إلى بروكسي مختلف؟

استخدم بروكسي nginx العكسي عند إنهاء TLS أو موازنة التحميل أو توجيه المسارات أمام خوادمك الخاصة، واختر بروكسي أماميا أو سكنيا عندما تتطلب المهمة إرسال طلبات خارجية من عناوين IP كثيرة. يتفوق nginx في المهمة الواردة وليس مصمما للمهمة الخارجية. هذه مصفوفة القرار:

• استخدم بروكسي nginx عكسيا عندما تستضيف الخلفية، وتريد نقطة نهاية HTTPS عامة واحدة أمام عدة خدمات داخلية، أو تحتاج إلى موازنة تحميل بين المثيلات، أو تريد التخزين المؤقت وgzip عند الحافة.
• تجنب nginx كبروكسي عندما يكون الهدف طلبات خارجية يجب أن تبدو صادرة من عناوين IP أو دول عديدة، لأن البروكسي العكسي يخرج من عنوان IP لخادمك الواحد ولا يستطيع تدوير العناوين.

ضمن البروكسيات العكسية تحديدا، تقدم nginx وCaddy وHAProxy مفاضلات مختلفة:

للأتمتة الخارجية المكثفة، يغطي دليلنا عن أفضل ممارسات تجريف الويب التدوير والتحكم في المعدل، وتناسب بروكسيات مركز البيانات أو البروكسيات المحمولة المهام التي تهم فيها التكلفة أو عناوين IP لشركات الاتصالات أكثر من موثوقية الطابع السكني.

ما قيود ومخاطر بروكسي nginx العكسي؟

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

• عنوان IP واحد للخروج. يغادر كل طلب خارجي من البروكسي عبر عنوان IP الخاص بالخادم، لذا لا يفيد البروكسي العكسي في المهام التي تحتاج إلى عناوين مصدر كثيرة.
• أخطاء الرؤوس صامتة. يؤدي نسيان X-Forwarded-For إلى إخفاء عنوان IP الحقيقي للعميل عن تطبيقك وتحديد معدل الطلبات فيه، ويؤدي نسيان X-Forwarded-Proto إلى كسر إعادات توجيه HTTPS. لن يحذرك nginx.
• صيانة TLS والشهادات. تنتهي صلاحية الشهادات، لذا تتولى التجديد وإعادة التحميل، عادة عبر certbot ومهمة cron أو مؤقت systemd.
• نقطة فشل جديدة. أصبح البروكسي الآن في المسار الحرج، فإذا تعطل صار كل ما خلفه من خلفيات غير قابل للوصول، ولذلك تهم فحوصات الصحة والمراقبة.
• ليس أداة لإخفاء الهوية خارجيا. لم يبن البروكسي العكسي لإخفاء مصدر الطلبات. تلك وظيفة البروكسي الأمامي.

nginx ليس منتجا من DataImpulse، ولا تبيع DataImpulse API مدارة للتجريف أو بروكسي ويب مجانيا. شغل nginx بنفسك حيث يناسبك، وحيث تحتاج إلى نطاق خارجي، تحصل DataImpulse على عناوين IP الخاصة بها بوصفها بروكسيات أخلاقية من مستخدمين يختارون المشاركة ويحصلون على مقابل. آخر تحديث: 2026-07-22.

الأسئلة الشائعة

أدلة ذات صلة

• بروكسي NGINX الأمامي
• بروكسي Cloudflare العكسي
• بروكسي Docker العكسي

هل تحتاج إلى عناوين IP خارجية لا يستطيع nginx تدويرها؟

يعالج البروكسي العكسي حركة المرور الواردة، لكن عندما تتطلب مهمتك طلبات خارجية من عناوين IP حقيقية كثيرة، توفر DataImpulse أكثر من 90M عنوان IP سكني ومحمول ومركز بيانات دوار في 195 دولة، مع الدفع حسب الاستخدام بدءا من 1 دولار لكل GB وحركة مرور لا تنتهي صلاحيتها. أنشئ حسابا للحصول على بيانات اعتماد البوابة وتوجيه عميلك إلى المجموعة.