الوكيل العكسي مقابل موازن التحميل: متى تستخدم كل منهما مع Nginx
ربما سمعت مصطلحي "الوكيل العكسي" و"موازن التحميل" يُستخدمان بالتبادل. لكن عند إعداد Nginx، معرفة الفرق مهمة—فهي تؤثر على كيفية تصميم البنية التحتية، والتعامل مع SSL، وتوسيع تطبيقك.
هذا الدليل يزيل الغموض. ستتعلم ما يفعله كل منهما، ومتى تستخدم أحدهما بدلاً من الآخر، وكيفية إعدادهما في Nginx بأمثلة واضحة وعملية.
ما هو الوكيل العكسي؟
الوكيل العكسي يقف بين العملاء وخوادم الواجهة الخلفية. يستقبل طلبات العملاء، يمررها إلى الواجهة الخلفية المناسبة، ويعيد الاستجابة. العميل لا يتحدث مع الواجهة الخلفية مباشرة أبداً.
الاستخدامات الشائعة:
- إنهاء SSL: التعامل مع HTTPS على الوكيل، بحيث تتعامل الواجهات الخلفية مع HTTP فقط.
- التخزين المؤقت: تخزين الأصول الثابتة أو استجابات API لتقليل الحمل على الواجهة الخلفية.
- الأمان: إخفاء تفاصيل الواجهة الخلفية، وتصفية الطلبات، وتخفيف هجمات DDoS.
- الضغط: ضغط الاستجابات بـ Gzip أو Brotli قبل إرسالها للعملاء.
غالباً ما يُستخدم Nginx كوكيل عكسي أمام خوادم التطبيقات مثل Node.js أو Python (Gunicorn/uWSGI) أو Java (Tomcat).
ما هو موازن التحميل؟
موازن التحميل يوزع حركة المرور الواردة عبر خوادم خلفية متعددة. هدفه الأساسي تحسين التوافر وقابلية التوسع وتحمل الأخطاء.
الميزات الرئيسية:
- توزيع الحركة: توزيع الطلبات باستخدام خوارزميات مثل round-robin أو least connections أو IP hash.
- فحوصات الصحة: إيقاف إرسال الحركة تلقائياً إلى الخوادم غير السليمة.
- استمرارية الجلسة: إبقاء المستخدم على نفس الواجهة الخلفية عند الحاجة.
يمكن أن يكون موازن التحميل عتادياً (F5، Citrix) أو برمجياً (Nginx، HAProxy، موازن سحابي). وحدة upstream في Nginx تجعله موازن تحميل برمجي قادر.
الوكيل العكسي مقابل موازن التحميل: الفروق الأساسية
| الجانب | الوكيل العكسي | موازن التحميل |
|---|---|---|
| الغرض الأساسي | تمرير الطلبات، إضافة ميزات (SSL، تخزين مؤقت) | توزيع الحمل عبر خوادم متعددة |
| عدد الواجهات الخلفية | عادةً واحد (أو قليل) | متعدد، غالباً كثير |
| التركيز | الوظائف، الأمان، الأداء | قابلية التوسع، التوافر العالي |
| فحوصات الصحة | اختيارية | أساسية |
عملياً، موازن التحميل هو وكيل عكسي متخصص. العديد من الأدوات، بما فيها Nginx، يمكنها أداء الدورين معاً.
متى تستخدم الوكيل العكسي
استخدم وكيلاً عكسياً عندما تحتاج إلى:
- خدمة خادم خلفي واحد لكن تريد SSL أو تخزيناً مؤقتاً أو ضغطاً.
- استضافة تطبيقات متعددة على مسارات أو نطاقات فرعية مختلفة خلف عنوان IP واحد.
- إضافة طبقة أمان إضافية بعدم كشف الواجهة الخلفية مباشرة.
مثال: واجهة API بـ Node.js تعمل على المنفذ 3000، مع Nginx يتعامل مع HTTPS ويخدم الملفات الثابتة.
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /etc/nginx/ssl/api.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
متى تستخدم موازن التحميل
استخدم موازن تحميل عندما يكون لديك:
- خوادم خلفية متعددة للتعامل مع حركة مرور عالية.
- حاجة لتوافر عالٍ—إذا فشل خادم، يتولى الآخرون المهمة.
- نشر تدريجي أو نشر أزرق-أخضر.
مثال: ثلاث نسخ من Node.js خلف Nginx باستخدام round-robin.
upstream backend {
server 10.0.0.1:3000;
server 10.0.0.2:3000;
server 10.0.0.3:3000;
}
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
سيوزع Nginx الطلبات بالتساوي. يمكنك إضافة فحوصات الصحة ومعاملات أخرى لضبط السلوك.
الجمع بين الدورين في Nginx
معظم الإعدادات الواقعية تستخدم Nginx كـ وكيل عكسي وموازن تحميل معاً. مثلاً:
upstream app_servers {
least_conn;
server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
server 10.0.0.3:3000 backup;
}
server {
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/nginx/ssl/app.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/app.example.com.key;
location /static/ {
root /var/www/static;
expires 30d;
}
location / {
proxy_pass http://app_servers;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
هنا، Nginx ينهي SSL، ويخدم الملفات الثابتة، ويوازن الحمل عبر ثلاثة خوادم تطبيقات مع فحوصات الصحة.
أفضل الممارسات لـ Nginx كوكيل عكسي / موازن تحميل
- تعيين الترويسات المناسبة: مرر دائماً
HostوX-Real-IPوX-Forwarded-Forحتى تعرف الواجهة الخلفية العميل الأصلي. - تفعيل HTTP/2: أضف
http2إلى توجيهlistenلأداء أفضل. - ضبط المخازن المؤقتة والمهلات: عدّل
proxy_buffer_sizeوproxy_read_timeoutبناءً على سلوك تطبيقك. - استخدام فحوصات الصحة: Nginx مفتوح المصدر لديه فحوصات سلبية؛ Nginx Plus يقدم فحوصات نشطة.
- تسجيل بحكمة: استخدم تنسيق سجل مخصص لالتقاط أوقات استجابة الواجهة الخلفية لأغراض التصحيح.
تحليل سجلات Nginx أمر بالغ الأهمية لاكتشاف الاختناقات. أدوات مثل محلل سجلات Nginx يمكن أن تساعدك في تحليل سجلات الوصول وتحديد الواجهات الخلفية البطيئة أو الأخطاء بسرعة.
الأسئلة الشائعة
هل يمكن أن يكون Nginx وكيلاً عكسياً وموازن تحميل معاً؟
نعم. يمكن لـ Nginx إنهاء SSL، وتخزين المحتوى مؤقتاً، وتوزيع الطلبات عبر واجهات خلفية متعددة في وقت واحد. كتلة upstream تحدد مجموعة الواجهات الخلفية، بينما توجيه proxy_pass يمرر الطلبات.
هل أحتاج موازن تحميل إذا كان لدي خادم خلفي واحد فقط؟
ليس بالضرورة. الوكيل العكسي وحده يمكنه التعامل مع SSL والتخزين المؤقت والأمان. لكن إضافة موازن تحميل مع واجهات خلفية متعددة يحسن التوافر—إذا فشل خادم، يمكن للآخرين خدمة الحركة.
كيف يختار Nginx الواجهة الخلفية لإرسال الطلب إليها؟
افتراضياً، يستخدم Nginx round-robin. يمكنك تغيير ذلك بتوجيهات مثل least_conn (أقل اتصالات)، ip_hash (جلسات ثابتة بناءً على IP العميل)، أو hash (مفتاح مخصص).
هل أنت مستعد لتحسين إعداد Nginx؟ ابدأ بتحليل سجلاتك باستخدام محلل سجلات Nginx المجاني لكشف مشكلات الأداء وضبط إعداداتك بدقة.