WSS праз Squid — гэта не тое ж, што звычайнае павышэнне WebSocket
Аддзяліце зашыфраваныя WebSocket у CONNECT ад апрацоўкі звычайнага HTTP Upgrade у прамым праксі.
Ці бачыць Squid запыт HTTP Upgrade, ці толькі тунэль з зашыфраваным трафікам? Гэта вызначае, ці вырашаюць ягоныя налады HTTP Upgrade збой.
| Звычайны шлях праз явны праксі | Што бачыць Squid |
|---|---|
wss:// | Звычайна CONNECT, затым TLS прызначэння, які нясе рукапацісканне WebSocket |
ws:// | Звычайны запыт HTTP Upgrade, які праксі можа апрацаваць |
Кіраванне Upgrade у Squid датычыць запытаў, якія ён апрацоўвае. Яно не паказвае зашыфраваныя загалоўкі HTTP унутры звычайнага непразрыстага тунэлю WSS. Перахоп TLS ці іншая спецыяльная апрацоўка праксі змяняе бачнасць і можа дадаць уласныя патрабаванні сумяшчальнасці.
Для WSS знайдзіце, дзе паслядоўнасць спыняецца: злучэнне з праксі, прыняты CONNECT, правераны TLS, затым рукапацісканне прыкладання. Адмова да TLS — гэта іншы збой, чым адхілены звычайны запыт Upgrade.
Калі трэба змяніць палітыку Upgrade, выкарыстайце дырэктыву для ўсталяванай версіі Squid і дазвольце патрэбныя паводзіны канкрэтна. Дазвол усіх пратаколаў Upgrade пашырае палітыку за межы канкрэтнага прыкладання.
Паспяховы запыт старонкі HTTPS усталёўвае толькі частку шляху. Доўгае злучэнне WebSocket усё яшчэ можа збаяць на патрабаваннях прыкладання, часе жыцця злучэння або абмежаваннях пасрэдніка нават для таго ж імя хоста.