WSS از طریق Squid با یک ارتقای سادهٔ WebSocket یکسان نیست
WebSocketهای رمزنگاری‌شده در CONNECT را از پردازش HTTP Upgrade ساده در یک پراکسی پیشین جدا کنید.
آیا Squid یک درخواست HTTP Upgrade می‌بیند یا فقط تونلی که ترافیک رمزنگاری‌شده را حمل می‌کند؟ این تعیین می‌کند که کنترل‌های HTTP Upgrade آن به خطا رسیدگی می‌کنند یا نه.
| مسیر معمول پراکسی صریح | آنچه Squid با آن روبه‌رو می‌شود |
|---|---|
wss:// | معمولاً CONNECT و سپس TLS مقصد که دست‌دادن WebSocket را حمل می‌کند |
ws:// | یک درخواست HTTP Upgrade ساده که پراکسی می‌تواند پردازش کند |
کنترل ارتقای Squid به درخواست‌هایی مربوط است که خودش پردازش می‌کند. سرآیندهای HTTP رمزنگاری‌شده را درون یک تونل WSS مات معمول آشکار نمی‌کند. رهگیری TLS یا پردازش ویژهٔ دیگر پراکسی دید را تغییر می‌دهد و می‌تواند الزامات سازگاری خودش را تحمیل کند.
برای WSS پیدا کنید زنجیره کجا متوقف می‌شود: اتصال به پراکسی، CONNECT پذیرفته‌شده، TLS تأییدشده، سپس دست‌دادن برنامه. رد شدن پیش از TLS خطایی متفاوت از رد یک درخواست Upgrade ساده است.
اگر تغییر سیاست ارتقا لازم است، از دستور مربوط به نسخهٔ نصب‌شدهٔ Squid استفاده کنید و رفتار لازم را به‌طور مشخص مجاز کنید. مجاز کردن همهٔ پروتکل‌های ارتقا سیاست را فراتر از برنامهٔ خاص گسترش می‌دهد.
یک درخواست موفق صفحهٔ HTTPS تنها بخشی از مسیر را برقرار می‌کند. ترافیک طولانی‌مدت WebSocket می‌تواند حتی برای همان نام میزبان نیز به‌دلیل الزامات برنامه، عمر اتصال یا محدودیت‌های واسطه شکست بخورد.