WSS عبر Squid ليس مثل ترقية WebSocket العادية
افصل WebSocket المشفّرة داخل CONNECT عن معالجة ترقية HTTP النصية في الوكيل الأمامي.
هل يرى Squid طلب ترقية HTTP، أم نفقًا فقط يحمل حركة مشفّرة؟ هذا يحدد ما إذا كانت أدوات التحكم في ترقية HTTP لديه تعالج الإخفاق.
| مسار الوكيل الصريح العادي | ما يواجهه Squid |
|---|---|
wss:// | عادةً CONNECT، يتبعه TLS الخاص بالوجهة الذي يحمل مصافحة WebSocket |
ws:// | طلب ترقية HTTP نصي يستطيع الوكيل معالجته |
تتعلق أدوات التحكم في الترقية لدى Squid بالطلبات التي يعالجها. وهي لا تكشف ترويسات HTTP المشفّرة داخل نفق WSS معتم عادي. اعتراض TLS أو أي معالجة خاصة أخرى للوكيل يغيّر الرؤية وقد يفرض متطلبات توافق خاصة به.
بالنسبة إلى WSS، حدّد أين يتوقف التسلسل: الاتصال بالوكيل، CONNECT المقبول، TLS المتحقق منه، ثم مصافحة التطبيق. الرفض قبل TLS إخفاق مختلف عن رفض طلب ترقية نصي.
إذا كان تغيير سياسة الترقية مطلوبًا، فاستخدم التوجيه الخاص بإصدار Squid المثبّت واسمح بالسلوك المطلوب تحديدًا. السماح بكل بروتوكولات الترقية يوسّع السياسة خارج التطبيق المعني.
طلب صفحة HTTPS ناجح لا يثبت إلا جزءًا من المسار. يمكن لحركة WebSocket طويلة العمر أن تفشل بسبب متطلبات التطبيق أو عمر الاتصال أو قيود الوسيط حتى مع اسم المضيف نفسه.