Yêu cầu HTTP/3 cần một đường proxy hỗ trợ UDP
Phân biệt phương thức vận chuyển QUIC của HTTP/3 với các đường hầm TCP HTTP CONNECT thông thường và với hỗ trợ UDP tùy chọn của dịch vụ SOCKS5.
Một máy khách truy cập HTTPS thành công qua proxy TCP chưa hề thiết lập tuyến đường cho HTTP/3. HTTP/3 dùng QUIC, và QUIC dùng UDP.
Một đường hầm HTTP CONNECT thông thường cung cấp luồng TCP tới đích của nó. Nó không trở thành bộ chuyển tiếp UDP khi URL bắt đầu bằng HTTPS hoặc khi đích lắng nghe trên cổng 443.
SOCKS5 cũng cần tuyến UDP
SOCKS5 định nghĩa kết giao UDP, nhưng cả máy khách lẫn máy chủ đều phải triển khai nó, và điểm cuối chuyển tiếp phải truy cập được. Một thư viện chỉ cung cấp dialer TCP của SOCKS không thể cung cấp vận chuyển datagram chỉ vì tên kiểu của nó ghi SOCKS5.
Tương tự, một thành phần của công cụ có tên proxy có thể là bộ mô phỏng mất gói cho phát triển chứ không phải máy khách proxy thượng nguồn tổng quát. Hãy kiểm tra giao diện thực tế và phương thức vận chuyển được hỗ trợ.
Các tiêu chuẩn như CONNECT-UDP định nghĩa một cách khác để mang UDP qua hệ thống proxy HTTP. Chúng đòi hỏi hỗ trợ ở cả hai đầu và không nên nhầm với CONNECT truyền thống.
Nếu máy khách HTTP quay về HTTP/2 hoặc HTTP/1.1 trên TCP, yêu cầu có thể thành công qua proxy thông thường mà không hề dùng kết nối HTTP/3. Hãy ghi lại giao thức đã thương lượng khi sự khác biệt đó quan trọng.
Vì vậy câu hỏi tương thích hữu ích rất cụ thể: máy khách này có thể mang các datagram QUIC của nó qua proxy này bằng cơ chế được hỗ trợ này không? Một trang trình duyệt hoạt động hay một lần kiểm tra cổng TCP chỉ trả lời câu hỏi nhỏ hơn.