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 ที่มีอายุยาวยังอาจล้มเหลวได้จากข้อกำหนดของแอปพลิเคชัน อายุการเชื่อมต่อ หรือข้อจำกัดของตัวกลาง แม้จะเป็นชื่อโฮสต์เดียวกัน