คำขอ HTTP/3 ต้องมีเส้นทางพร็อกซีที่รองรับ UDP
แยกการขนส่ง QUIC ของ HTTP/3 ออกจากอุโมงค์ TCP ของ HTTP CONNECT ทั่วไป และจากการรองรับ UDP แบบเสริมของบริการ SOCKS5
ไคลเอนต์ที่เข้าถึง HTTPS สำเร็จผ่านพร็อกซี TCP ยังไม่ได้สร้างเส้นทางสำหรับ HTTP/3 HTTP/3 ใช้ QUIC และ QUIC ใช้ UDP
อุโมงค์ HTTP CONNECT ทั่วไปให้สตรีม TCP ไปยังปลายทาง ไม่ได้กลายเป็นตัวส่งต่อ UDP เมื่อ URL ขึ้นต้นด้วย HTTPS หรือเมื่อปลายทางฟังที่พอร์ต 443
SOCKS5 ก็ต้องมีเส้นทาง UDP เช่นกัน
SOCKS5 กำหนดความเชื่อมโยง UDP แต่ทั้งไคลเอนต์และเซิร์ฟเวอร์ต้องนำไปใช้ และจุดปลายทางการส่งต่อต้องเข้าถึงได้ ไลบรารีที่ให้เฉพาะไดอาเลอร์ TCP ของ SOCKS ไม่สามารถให้การขนส่งดาตาแกรมได้เพียงเพราะชื่อชนิดของมันบอกว่า SOCKS5
ในทำนองเดียวกัน คอมโพเนนต์ของเครื่องมือที่ชื่อ proxy อาจเป็นตัวจำลองการสูญหายของแพ็กเก็ตสำหรับการพัฒนา ไม่ใช่ไคลเอนต์พร็อกซีทั่วไป ตรวจสอบอินเทอร์เฟซจริงและการขนส่งที่รองรับ
มาตรฐานอย่าง CONNECT-UDP กำหนดวิธีอื่นในการพา UDP ผ่านระบบพร็อกซี HTTP ต้องมีการรองรับทั้งสองฝั่ง และไม่ควรสับสนกับ CONNECT แบบเดิม
หากไคลเอนต์ HTTP ถอยกลับไปใช้ HTTP/2 หรือ HTTP/1.1 บน TCP คำขออาจสำเร็จผ่านพร็อกซีทั่วไปโดยไม่มีการใช้การเชื่อมต่อ HTTP/3 บันทึกโปรโตคอลที่เจรจาเมื่อความแตกต่างนั้นสำคัญ
ดังนั้นคำถามด้านความเข้ากันได้ที่มีประโยชน์จึงเฉพาะเจาะจง: ไคลเอนต์นี้สามารถพาดาตาแกรม QUIC ของตนผ่านพร็อกซีนี้ด้วยกลไกที่รองรับนี้ได้หรือไม่ หน้าเบราว์เซอร์ที่ใช้งานได้หรือการตรวจพอร์ต TCP ตอบคำถามที่เล็กกว่า