لماذا يعمل البروكسي العكسي حسب النطاق لكنه يفشل عند استخدام عنوان IP المحلي؟
يعمل البروكسي العكسي بناءً على النطاق لأن قواعد التوجيه وTLS غالبًا ما تعتمد على اسم المضيف المطلوب، وليس فقط على عنوان IP الوجهة.
عندما يفتح عميل منزلي https://app.example.com، يوفر DNS عنوان IP لكن المتصفح لا يزال يرسل النطاق من خلال مصافحة TLS ورأس HTTP Host. فتح https://192.168.1.20 يغير هذه المعرفات، لذا قد يختار البروكسي موقعًا افتراضيًا، يرفض الشهادة، يفوت مسار التطبيق، أو يعيد التوجيه إلى عنوان URL العام المُكوَّن. الاختبار الصحيح يحافظ على اسم المضيف المقصود مع تغيير وجهة الشبكة فقط.
قارن طلب اسم المضيف مع طلب IP المباشر
أرسل طلبًا واحدًا إلى النطاق وآخر إلى IP المحلي، ثم قارن رمز الحالة، الشهادة، رؤوس الاستجابة، موقع إعادة التوجيه، وسجل وصول البروكسي العكسي. لا تفترض أن كلا الطلبين متكافئان لأنهما يصلان إلى نفس واجهة الإيثرنت.
تشرح جولة إرشادية للبروكسي العكسي في المختبر المنزلي أن البروكسي يفحص رأس HTTP Host لتوجيه عدة خدمات عبر عنوان IP ومنفذ واحد.
إذا تطابق طلب النطاق مع مسار تطبيق بينما طلب IP يصطدم بصفحة افتراضية أو 404، فإن البروكسي يعمل كما هو مُكوَّن. القرار التالي هو ما إذا كان الوصول المباشر إلى IP مطلوبًا فعلاً أو إذا كان يجب أن يحافظ DNS المحلي على النطاق.
اختبر IP المحلي مع الحفاظ على رأس المضيف المقصود
استخدم أداة عميل تتصل بعنوان IP المحلي للبروكسي مع إرسال نطاق التطبيق كرأس Host. بالنسبة لـ HTTPS، حافظ أيضًا على النطاق كاسم خادم TLS بدلاً من استبداله بالـ IP.
يصف موقع Server Fault كيف يمكن لبروكسي عكسي HTTP استخدام رأس Host لاختيار المسار بنفس طريقة المضيفين الافتراضيين المعتمدين على الاسم.
إذا نجح الطلب مع رأس المضيف المفروض، فإن مسار البروكسي والخلفية صحيحة؛ فشل الوصول المباشر إلى IP هو عدم تطابق في الهوية. إذا استمر الفشل، فافحص المستمع، جدار الحماية المحلي، نقطة دخول البروكسي، وأولوية المسار قبل تغيير DNS.
تحقق من مطابقة TLS SNI والشهادة
يضيف HTTPS قرار اسم المضيف قبل طلب HTTP. عادةً ما يرسل العميل مؤشر اسم الخادم (SNI) أثناء مصافحة TLS حتى يتمكن البروكسي من اختيار الشهادة الصحيحة والمضيف الافتراضي الآمن.
تشير تنفيذات البروكسي العكسي المعتمدة على SNI إلى أن الخلفيات HTTPS تُختار باستخدام اسم SNI الخاص بالعميل قبل فحص رؤوس HTTP العادية.
الوصول المباشر عبر IP قد يعرض شهادة افتراضية أو يفشل في التحقق من اسم المضيف حتى عندما يكون البروكسي متاحًا. استخدم النطاق مع DNS المحلي، أو قم بنشر شهادة مُدارة عمدًا تحتوي على IP فقط عندما يكون HTTPS عبر IP المباشر مطلبًا تشغيليًا حقيقيًا.
افحص الموقع الافتراضي وأولوية المسار
راجع أي مضيف افتراضي يتعامل مع الطلبات التي لا تطابق نطاقًا مُكوَّنًا. قد يعيد الموقع الافتراضي لوحة تحكم، يعيد التوجيه إلى اسم مضيف آخر، يغلق الاتصال، أو يعرض خطأً عامًا.
توضح مناقشة Caddy أن الطلب قد يصل إلى عنوان IP البروكسي الصحيح بينما رأس Host واسم TLS لا يزالان يحددان ما إذا كان سيتم اختيار المصدر المقصود.
اجعل المسار الافتراضي صريحًا وآمنًا. لا تضف بروكسي شاملًا واسع النطاق إلى خلفية واحدة فقط لجعل الوصول عبر IP يعمل، لأن ذلك قد يوجه أسماء مضيفين غير معروفة أو حركة مسح إلى تطبيق كان من المفترض أن يكون مقيدًا بالنطاق.
تحقق مما إذا كان التطبيق يعيد التوجيه إلى عنوانه الرسمي
حتى عندما يقبل البروكسي طلب IP، قد يفرض الخلفية عنوان URL أساسي عام مُكوَّن ويعيد توجيه المتصفح إلى النطاق. يمكن أن تعتمد ملفات تعريف الارتباط للمصادقة، ردود OAuth، أصول WebSocket، وفحوصات CSRF أيضًا على ذلك المضيف الرسمي.
قارن سجل البروكسي مع سجل التطبيق وافحص رأس Location. إعادة التوجيه إلى النطاق ليست فشلًا في التوجيه؛ إنها دليل على أن التطبيق يتوقع هوية عامة واحدة.
صحح رؤوس المضيف والبروتوكول المعاد توجيهها عندما يولد التطبيق عنوان URL خارجي خاطئ. لا تستبدل النطاق الرسمي بعنوان IP خاص فقط لتجاوز إعادة التوجيه، لأن ذلك قد يكسر الشهادات والوصول عن بُعد.
استخدم DNS المحلي عندما يكون النطاق هو الواجهة المقصودة
أنشئ سجل DNS داخلي يحل نطاق التطبيق إلى عنوان البروكسي العكسي المحلي. يستخدم المتصفح حينها مسار LAN الفعال مع الحفاظ على نفس رأس Host، واسم SNI، والشهادة، وملفات تعريف الارتباط، وعنوان URL للتطبيق.
تساعد مقارنة ZimaSpace بين البروكسيات العكسية ومسارات الوصول الخاصة في اتخاذ قرار ما إذا كان يجب أن يظل النطاق نقطة دخول محلية وعامة أو يبقى خلف شبكة خاصة.
يتم حل المشكلة عندما يعمل النطاق داخل وخارج الشبكة من خلال إجابات DNS مقصودة، بينما يصل IP المباشر إما إلى موقع افتراضي موثق أو يُرفض عمدًا. لا يحتاج البروكسي الموجه بالنطاق إلى التصرف كسيرفر موقع واحد معنون بعنوان IP.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...
How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.
How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.
