قم بتهيئة خادم وكيل عكسي باستخدام إنجن إكس أصبح استخدام خادم وكيل عكسي معيارًا شبه فعلي لتحسين أداء تطبيقات الويب وأمانها ومرونتها. سواء كنت تُنشئ مشروعًا شخصيًا بسيطًا، أو خادمًا تجريبيًا للدراسة، أو بنية تحتية لشركة، فستحتاج عاجلاً أم آجلاً إلى وضع خادم وكيل عكسي أمام خوادم تطبيقاتك.
سنرى في هذه المقالة بالضبط ما هو الخادم الوكيل العكسي، وكيف يختلف عن خادم الوكيل التوجيهي، وما هي المزايا التي يقدمها، وكيف يتناسب مع WordPress والمجموعات الأخرى (Apache، Gunicorn، Kubernetes، إلخ)، وقبل كل شيء، كيفية تكوين Nginx بشكل مثالي كخادم وكيل عكسي، بما في ذلك موازنة التحميل، والعناوين المخصصة، والتخزين المؤقت، وSSL، وأمثلة عملية معملية باستخدام جهازين Debian.
ما هو الخادم الوكيل وما الذي يميزه عن الخادم الوكيل العكسي؟
قبل تعديل أي ملف من ملفات التكوين، يُنصح بفهم واضح للمفاهيم ذات الصلة. ما هو دور الخادم الوكيل في بنية الشبكة الحديثة؟لأنه بخلاف ذلك، من السهل جدًا الخلط بين مصطلحات مثل الوكيل المباشر، والوكيل العكسي، وشبكة توصيل المحتوى (CDN)، وموازن الأحمال، وبوابة واجهة برمجة التطبيقات (API)، وما إلى ذلك.
- وكيل "عادي" (وكيل توجيهي) يُوضع خادم وسيط أمام مجموعة من العملاء (مثل أجهزة الكمبيوتر في مكتب أو فصل دراسي أو شبكة منزلية) ويعمل كوسيط عند اتصال هذه الأجهزة بالإنترنت. في اتصال نموذجي بدون خادم وسيط، يتصل الكمبيوتر (أ) (العميل) مباشرةً بالخادم (ج) (الخادم الأصلي). أما مع وجود خادم وسيط لإعادة التوجيه، فيتصل الكمبيوتر (أ) بالخادم (ب) (الخادم الوسيط)، ثم يتصل الخادم (ب) بالخادم (ج)، ويتلقى الرد، ويرسله مرة أخرى إلى الخادم (أ).
- يمثل الخادم الوكيل العكسي سيناريو معاكساًبدلاً من حماية هوية المستخدم، يحمي هذا النظام خادمًا أصليًا واحدًا أو أكثر ويُخفيه. نضعه "أمام" خادم الويب أو مجموعة الخوادم التي تستضيف التطبيق (مثل Apache، وNginx كخادم ويب، وLiteSpeed، وGunicorn، وNode.js، وPHP-FPM، إلخ)، ويصل كل تدفق بيانات المستخدم الوارد أولاً إلى هذا الخادم الوكيل العكسي.
إذا أطلقنا أسماءً على الآلات الفرق واضحيمثل D أجهزة المستخدمين، وE الخادم الوكيل العكسي، وF خادمًا أصليًا واحدًا أو أكثر. بدون خادم وكيل عكسي، يتواصل D مباشرةً مع F. أما مع وجود خادم وكيل عكسي، فلا يرى D سوى E، ويتولى E تحديد كيفية إرسال كل طلب إلى F، وكيفية إعادة الرد إلى D. والهدف هو منع أي عميل من الاتصال مباشرةً بالخوادم الأصلية.
لماذا يُنصح باستخدام خادم وكيل عكسي مع Nginx
إن استخدام Nginx كخادم وكيل عكسي ليس نزوة. إنه يتعلق بـ قطعة رئيسية لتوسيع نطاق الموقع، وتحسين أمانه، وتبسيط بنيته، خاصة عندما نجمع بين تقنيات مختلفة أو نريد نطاقًا واحدًا لخدمات متعددة.
إحدى أقوى المزايا هي موازنة الأحمال. إذا كان لديك موقع ويب ذو حركة مرور عالية، فقد لا يكون خادم خلفي واحد كافيًا. باستخدام خادم وكيل عكسي، يمكنك توزيع الطلبات على عدة خوادم أصلية تقدم المحتوى نفسه. إذا تعطل أحدها أو تعرض لحمل زائد، تستمر الخوادم الأخرى في خدمة الموقع، مما يقلل من نقاط الفشل الفردية.
يُعد الخادم الوكيل العكسي أيضًا درع أمان عالي الفعالية لأنه يخفي عنوان IP الحقيقي وتفاصيل أخرى لخوادم الواجهة الخلفية. لا يرى المستخدمون (والمهاجمون) سوى الخادم الوكيل. وهذا يجعل شنّ هجمات مُستهدفة أكثر صعوبة. علاوة على ذلك، يُمكنك تعزيز أمان الخادم الوكيل باستخدام قواعد جدار الحماية، ومصادقة HTTP الأساسية، وفلترة حركة المرور المتقدمة، أو التكامل مع جدار حماية تطبيقات الويب (WAF).
جانب رئيسي آخر هو التخزين المؤقت وتسريع الويب. تستطيع حلول Nginx وVarnish وغيرها من حلول الخوادم الوكيلة العكسية تخزين المحتوى الثابت وبعض المحتوى الديناميكي مؤقتًا، مما يوفر موارد الخوادم الأصلية ويُقدّم الاستجابات من الخادم الوكيل نفسه، غالبًا من موقع أقرب إلى المستخدم. هذا يُقلل زمن الاستجابة ويُحسّن أوقات التحميل بشكل كبير.
وأخيرًا، الخادم الوكيل العكسي يبسط تشفير وإنهاء بروتوكول SSL/TLS. لا يحتاج خادم المصدر إلى التعامل مع تشفير وفك تشفير جميع اتصالات HTTPS، حيث يمكن للوكيل العكسي أن يعمل كمنهي SSL، مما يؤدي إلى تخفيف حمل وحدة المعالجة المركزية وتمركز إدارة الشهادات، حتى أنه يعتمد على أجهزة تسريع SSL المتخصصة إذا لزم الأمر.
NGINX كخادم وكيل عكسي: الميزات والدور في البنى الحديثة
يُعد Nginx أحد أكثر خوادم الويب والخوادم الوكيلة العكسية استخدامًا في العالميُستخدم كل من إصداره مفتوح المصدر وNGINX Plus (الإصدار التجاري الذي يحتوي على ميزات مراقبة متقدمة وإدارة واجهة برمجة التطبيقات ودعم المؤسسات) كخادم ويب ثابت، ووكيل عكسي، وموازن تحميل، ومنهي SSL، ووحدة تحكم دخول Kubernetes، وبوابة واجهة برمجة التطبيقات.
كخادم وكيل عكسي، Nginx يقع بين العملاء وخوادم الواجهة الخلفية (Apache، LiteSpeed، Gunicorn، PHP-FPM، Node.js، إلخ) ويقوم بتحليل كل طلب وارد لتحديد ما يجب فعله به: تقديمه مباشرة من ذاكرة التخزين المؤقت إذا كان ثابتًا، أو إعادة توجيهه إلى الواجهة الخلفية المناسبة إذا كان ديناميكيًا، أو إرجاع خطأ معالج إذا حدث خطأ ما.
لتوزيع حركة المرور بين خوادم الواجهة الخلفية المتعددة، يقوم Nginx بتنفيذ العديد من خوارزميات الموازنة، مثل التوزيع الدوري (التناوب)، و"عدد أقل من الاتصالات" (يرسل كل طلب جديد إلى الخادم الذي يحتوي على أقل عدد من الاتصالات النشطة) أو تجزئة عنوان IP (التي تساعد في الحفاظ على جلسة العميل مرتبطة دائمًا بنفس الواجهة الخلفية).
NGINX Plus والحلول المشتقة الأخرى يتم تعزيز هذه القدرات من خلال المراقبة في الوقت الفعلي، ولوحات معلومات الحالة، وفحوصات الصحة المتقدمة، وواجهات برمجة التطبيقات للتكوين الديناميكي، وهو ما يتناسب بشكل جيد للغاية مع البنى الأصلية السحابية وعمليات النشر على Kubernetes حيث يعمل Nginx عادةً كوحدة تحكم Ingress.
إعداد المختبر: خادمان يعملان بنظام Debian مع Nginx وخادم وكيل عكسي
يتضمن التمرين المفيد للغاية لفهم Nginx كخادم وكيل عكسي ما يلي: العمل مع جهازين يعملان بنظام دبيانأحدهما يعمل كخادم ويب "نهائي" (خادم خلفي)، والآخر كخادم وكيل عكسي. ستتمكن دائمًا من الوصول إلى الخادم الوكيل من متصفح جهازك الفعلي، والذي سيعيد توجيه الطلبات إلى خادم الويب الأصلي.
الفكرة هي كالتالي: على الجهاز الأول، لديك موقعك التدريبي (على سبيل المثال، من تمرين سابق على Nginx). ستقوم بإعادة تسمية إعداداته بحيث يُسمى الموقع webserverقم بتغيير منفذ الاستماع إلى 8080 وتأكد من استمرار عرض الصفحة بشكل صحيح.
على وجه التحديد ، في خادم الويب الأصلي يجب عليك:
- أعد تسمية ملف التكوين في
/etc/nginx/sites-availableوأي إشارة داخلية إلى اسم الموقع بحيث يصبحwebserver. - قم بإزالة الرابط الرمزي القديم في
sites-enabledباستخدامunlinkثم أنشئ رابطًا رمزيًا جديدًا يشير إلى الملف الذي تمت إعادة تسميته. - غيّر التوجيه
listen 80;alisten 8080;في الكتلةserverبما يتوافق مع ذلك الموقع الإلكتروني. - أعد تشغيل Nginx حتى يتمكن من رصد التغييرات وللتأكد من إمكانية الوصول إلى الموقع في
http://webserver:8080أو عبر عنوان IP:8080.
على جهاز Debian الثاني، ستقوم قم بتهيئة Nginx كخادم وكيل عكسيالخطوات الأساسية:
- أنشئ ملف تكوين في
/etc/nginx/sites-availableباستخدام اسم نطاق الاختبار الخاص بك، على سبيل المثالejemplo-proxy. - حدد كتلة
serverبسيط مع تحديد المنفذ الذي سيستمع إليه الخادم الوكيل (80، أو منفذ آخر إذا كنت ترغب في تمييز الأدوار بشكل أكبر) وserver_nameباستخدام نطاق أو اسم مستعار للوكيل الخاص بك. - داخل الكتلة
location /، يثبتproxy_passعلى سبيل المثال، الإشارة إلى عنوان IP ومنفذ الخادم الخلفي.proxy_pass http://192.168.1.50:8080;ohttp://webserver:8080;إذا كان لديك نظام أسماء نطاقات داخلي. - أنشئ الرابط الرمزي في
sites-enabledواختبر التكوين باستخدامnginx -t.
إذا سارت الأمور على ما يرام، بعد إعادة تحميل Nginx ستتمكن من الوصول إلى موقعك باستخدام اسم الوكيل وسترى المحتوى الذي يتم تقديمه فعليًا من خادم الويب الخلفي، ولكنه يمر عبر الوكيل العكسي في جميع الأوقات.
أضف رؤوسًا مخصصة لتوضيح مسار الطلب
إحدى الطرق الواضحة جدًا للتحقق من أن الطلب يمر عبر الخادم الوكيل ويصل إلى الخادم الأصلي هي أضف رؤوس HTTP مخصصة على كلا الجانبين ثم اعرضها من أدوات مطوري المتصفح.
تتكون الممارسة من قم بتهيئة كل من الخادم الوكيل العكسي وخادم الويب بحيث تتضمن الاستجابات عنوانًا إضافيًا، على سبيل المثال باستخدام التوجيه add_header داخل الكتلة location / { ... }قد يكون العنوان شيئًا مثل X-Host: Proxy_inverso_tunombre في الوكيل و X-Host: Servidor_web_tunombre في الواجهة الخلفية.
El التدفق الموصى به مستخدم:
- أضف الترويسة أولاً، فقط في الخادم الوكيل العكسيأعد تشغيل Nginx وتأكد من أنه لا يزال بإمكانك الوصول إلى الموقع بشكل طبيعي.
- افتح أدوات مطوري المتصفح (F12) وتحقق من علامة تبويب الشبكةتحديد الطلب الرئيسي ومراجعة رؤوس الاستجابة لرؤية الرأس الجديد الذي أضافه الخادم الوكيل.
- أضف الآن الترويسة إلى إعدادات خادم الويب الأصلي، بقيمة مختلفة لتمييزها، ثم أعد تشغيل Nginx على ذلك الخادم.
- قم بتحديث الصفحة عن طريق تعطيل ذاكرة التخزين المؤقت للمتصفح أو في نافذة خاصة.، لضمان أن الإجابات تأتي بالفعل من الخادم.
إذا تم إعداد كل شيء بشكل صحيح، ستجد في استجابات HTTP رأسين، واحد تم إنشاؤه بواسطة الخادم الوكيل العكسي والآخر بواسطة خادم الويب، مما يؤكد أن الطلب قد اتبع مسار الرحلة ذهابًا وإيابًا بالكامل عبر الخادم الوكيل.

تكوين Nginx "الكلاسيكي" كوكيل عكسي بسيط
الحد الأدنى من إعدادات Nginx المطلوبة للعمل كخادم وكيل عكسي بسيط للغايةلكن انطلاقاً من هذه القاعدة، يمكن إضافة العديد من التحسينات. تخيل أنك تريد أن تكون الطلبات /example إلى الأمام https://example.comيكفي ببساطة إضافة كتلة. location إلى المربع server ملائم:
location /example {
proxy_pass https://example.com;
}
تشير هذه المقتطفة إلى أن أي طلب يبدأ مساره بـ /example سيتم إرسالها إلى الوجهة المحددة في proxy_passغالباً ما يصاحب ذلك توجيهات أخرى لتعديل الرؤوس، والمهل الزمنية، وسلوك إعادة التوجيه.
يمكن أن تتضمن نسخة أكثر اكتمالاً لدليل فرعي من نوع المدونة ما يلي: من هنا:
server {
listen 80;
server_name example.com;
موقع / {
Try_files $uri $uri/ /index.php?$query_string;
}
location /blog {
proxy_pass http://blog.domain.com;
proxy_http_version 1.1 ؛
proxy_cache_bypass $http_upgrade;
proxy_set_header ترقية $ http_upgrade؛
proxy_set_header Connection «upgrade»;
proxy_set_header المضيف $ 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 $;
رأس مجموعة الوكيل X-Forwarded-Host $host؛
proxy_set_header X-Forwarded-Port $server_port;
proxy_connect_timeout 60s؛
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}
المفتاح هنا proxy_pass يشير إلى الواجهة الخلفية ومجموعة من الرؤوس التي تضمن أن الخادم الأصلي يعرف عنوان IP الحقيقي للعميل، والمخطط الأصلي (HTTP أو HTTPS)، وبيانات مهمة أخرى للسجلات وللتطبيقات التي تعتمد على تلك الرؤوس.
أفضل الممارسات في بنية ملفات Nginx وتكوينها
عند تثبيت Nginx على توزيعة مثل Ubuntu أو Debianيتم تنظيم بنية التكوين النموذجية في عدة أدلة يجب احترامها لتجنب إحداث فوضى مع ازدياد عدد المواقع.
النقاط الرئيسية لهذا الهيكل هي:
/etc/nginx/nginx.conf، ملف التكوين الرئيسي، حيث يتم تعريف التوجيهات العامة وتضمين الملفات الأخرى./etc/nginx/sites-available/، والذي يخزن ملفات التكوين لكل موقع افتراضي، سواء كان نشطًا أم لا./etc/nginx/sites-enabled/، والذي يحتوي على روابط رمزية لمواقع نشطة بالفعل./etc/nginx/conf.d/حيث يمكنك وضع إعدادات عامة إضافية في ملفات.confيتم تحصيل الرسوم تلقائيًا.
العمل مع sites-available y sites-enabled لديه عدة أفضلية. يمكنك إعداد تكوين الموقع دون تفعيله حتى تقوم بإنشاء الرابط الرمزي، وإلغاء تنشيط المواقع عن طريق إزالة الرابط الرمزي فقط، والاحتفاظ بتكوين كل خدمة مجمعة في ملف واحد يسهل تحديد موقعه.
ستجد عادةً داخل كل ملف موقع عدة مبانٍ serverولكل منها توجيهاتها الخاصة listen, server_name ومبانٍ مختلفة locationتحدد هذه الأخيرة كيفية التعامل مع المسارات المختلفة (الثابتة، والوكلاء، وواجهات برمجة التطبيقات، وما إلى ذلك)، على سبيل المثال عن طريق خدمة /static/ مباشرة من القرص وإرسالها /api/ إلى خادم خلفي يعمل بنظام Node.js.
التوصية العامة هي اختبر الإعدادات دائمًا قبل إعادة التحميل. باستخدام sudo nginx -tلتجنب إيقاف الخدمة بسبب خطأ بسيط في بناء الجملة، واستخدام systemctl reload nginx كلما أمكن ذلك، لأنه يعيد تحميل التكوين دون قطع الاتصالات النشطة.
تثبيت Nginx والخطوات الأولى لاستخدامه كخادم وكيل عكسي على Ubuntu/Debian
إذا كنت تقوم بإعداد خادم افتراضي خاص من الصفر أو جهاز تدريب، فإن خطوات تشغيل Nginx كخادم وكيل عكسي على Ubuntu 22.04 (أو ما شابه) واضحة تمامًا ويمكن أتمتتها بسهولة باستخدام البرامج النصية.
تسلسل التثبيت النموذجي:
- حزم التحديث مع
sudo apt updateysudo apt upgrade -yللتأكد من أن كل شيء محدّث. - قم بتثبيت Nginx مع
sudo apt install nginx -y، مما سيؤدي إلى بدء الخدمة تلقائيًا. - التحقق من حالة الخدمة باستخدام
sudo systemctl status nginxلرؤية ما يظهر كـ نشط (قيد التشغيل). - افتح جدار الحماية في حالة استخدام UFW، مع
sudo ufw allow 'Nginx Full'للسماح بمرور البيانات في المنفذين 80 و 443.
بمجرد تثبيت Nginx، يمكنك أنشئ مضيفك الافتراضي الأول en /etc/nginx/sites-available/ejemplo.com وقم بربطه في sites-enabledومن ثم، ما عليك سوى إضافة كتلة location / لكى يفعل proxy_pass إلى الواجهة الخلفية والعناوين الموصى بها حتى يتلقى التطبيق على الجانب الآخر جميع المعلومات الضرورية.
في البيئات الأكثر تطوراً، يكون ذلك شائعاً قم بدمج Nginx مع مكونات أخرى مثل Certbot للحصول على شهادات Let's Encrypt، أو Gunicorn لتطبيقات Python، أو حتى إعداد وكيل عكسي على Raspberry Pi يقوم بإعادة توجيه حركة المرور إلى الخدمات الداخلية (NAS، لوحات الإدارة، إلخ) مع عمليات إعادة توجيه المنافذ من جهاز التوجيه إلى الجهاز الذي يحتوي على Nginx.
خيارات متقدمة: موازنة الأحمال، والتخزين المؤقت، وبروتوكول SSL، والضبط الدقيق لسياسات الوكيل.
بمجرد إتقانك لإعداد الخادم الوكيل العكسي الأساسي، قد يغريك الأمر بالتوقف عند هذا الحد. لكن Nginx يوفر العديد من التوجيهات التي تتيح لك القيام بالمزيد. لتحقيق أقصى قدر من الأداء والتحكم.
إلى إنشاء موازن الأحمال أولاً، تقوم بتعريف كتلة upstream مع خوادم الواجهة الخلفية، ثم تستخدم proxy_pass يشير إلى ذلك في المنبع:
upstream myapp1 {
server backend1.example.com;
server backend2.example.com;
}
الخادم {
80 الاستماع.
اسم الخادم example.com؛
موقع / {
proxy_pass http://myapp1;
حدث خطأ في الخادم الوكيل التالي (proxy_next_upstream)؛
}
}
إلى قم بعرض المحتوى الثابت مباشرة من الخادم الوكيليمكنك تحديد كتلة موقع إضافية:
server {
listen 80;
server_name example.com;
موقع / {
proxy_pass http://backend.example.com;
}
الموقع / ثابت / {
root /path/to/static/files;
تنتهي 30 د؛
}
}
أما بالنسبة لل التوجيهات proxy_*من أكثرها استخداماً ما يلي:
proxy_set_headerلتعديل العناوين مثلHost,X-Real-IPoX-Forwarded-Protoأساسيات تطبيقات الويب الحديثة.proxy_cacheyproxy_cache_pathلتفعيل وتكوين ذاكرة التخزين المؤقت للوكيل العكسي التي تقلل الحمل على الواجهة الخلفية.proxy_bufferingلتحديد ما إذا كان Nginx يقوم بتخزين الاستجابات مؤقتًا أو بثها، مما قد يقلل من زمن الاستجابة في بعض واجهات برمجة التطبيقات.proxy_connect_timeout,proxy_read_timeoutyproxy_send_timeoutللتحكم في متى يعتبر النظام الخلفي غير مستجيب والانتقال إلى النظام التالي أو إرجاع خطأ.proxy_sslوالمعايير ذات الصلة إذا كانت حركة المرور بين Nginx والخادم الخلفي مشفرة باستخدام HTTPS.
عندما تجمع كل هذه العناصر معًا - الخادم الوكيل العكسي، وموازنة الأحمال، والتخزين المؤقت، وشهادة SSL، والمراقبة -يُصبح Nginx المحور المركزي الذي يمر عبره كل حركة مرور تطبيقاتك. إن معرفة كيفية تهيئته بشكل صحيح وفهم دوره في بنية النظام يُحدث فرقًا شاسعًا بين نظام هش ونظام قادر على التوسع ومقاومة الهجمات وتقديم أوقات استجابة منخفضة للغاية حتى في ظل الأحمال الثقيلة.

