الصفحة التي تحتوي على مربع لعنوان URL هي تطبيق ويب. إدخال وجهة هناك يطلب من ذلك التطبيق أن يجلب المحتوى ويعرضه. هذا ترتيب مختلف عن إخبار المتصفح باستخدام وكيل HTTP أو SOCKS.

مع إعداد وكيل أصلي، لا يزال المتصفح يعتبر عنوان URL للوجهة هو الموقع. أما في وكيل النموذج على الويب التقليدي، فالصفحة الظاهرة تُقدَّم عبر نظام عناوين URL وأصل تطبيق الوكيل نفسه. وقد تعيد الخدمة كتابة الروابط أو النصوص البرمجية أو الترويسات أو الكوكيز لمواصلة التصفح.

السلوكلماذا يهم الفرق
فحوص الأصل نفسهيقيّم المتصفح الأصل الذي حمّله فعلاً
الكوكيز وإعادة التوجيهيجب أن يتوافق سلوك النطاق والمسار والسياق الآمن مع عناوين URL المعروضة
النصوص البرمجية التي تبني عناوين جديدةقد تفلت الطلبات من مخطط بسيط لإعادة كتابة الروابط
الاتصالات المستمرة أو WebSocketsيحتاج تطبيق الوكيل إلى معالجة متوافقة صريحة

هذا يفسر نتيجة مألوفة: مقال بسيط يُحمَّل، لكن محرر مستندات أو مسار تسجيل دخول يفشل. ولا يعني الفشل بالضرورة أن الوجهة ترفض عنوان IP الخارجي للخدمة. فقد يكون الوسيط غير قادر على الحفاظ على افتراضات التطبيق بشأن عناوين URL وأمان المتصفح.

وميّز أيضاً أين ينتهي TLS. فخدمة تجلب المحتوى وتعيد نشره تتعامل مع محتوى الوجهة، وهي في موقع ثقة مختلف عن مرحّل CONNECT عادي يحمل جلسة مشفرة. ورؤية HTTPS على عنوان موقع الوكيل نفسه لا تثبت وجود اتصال TLS من طرف إلى طرف بين المتصفح والموقع الأصلي.

إذا كان الهدف هو التصفح العادي عبر مخرج آخر، فاختر نقطة نهاية HTTP أو SOCKS من خدمتك أو من قائمة وكلاء واستخدم إعداد وكيل أصلي مدعوماً، مثل إعدادات اتصال فايرفوكس. وهذا يحافظ عادة على قدر أكبر من دلالات الوجهة الطبيعية في المتصفح. ويمكن أن يكون موقع إدخال URL تطبيقاً مختاراً عن قصد، لكن لا ينبغي تقديمه كالواجهة نفسها بإعداد أقل.

مقالات ذات صلة