Permintaan HTTP/3 memerlukan jalur proxy yang mendukung UDP
Bedakan transport QUIC pada HTTP/3 dari terowongan TCP HTTP CONNECT biasa dan dari dukungan UDP opsional layanan SOCKS5.
Klien yang berhasil mencapai HTTPS melalui proxy TCP belum membangun rute untuk HTTP/3. HTTP/3 memakai QUIC, dan QUIC memakai UDP.
Terowongan HTTP CONNECT biasa menyediakan aliran TCP ke tujuannya. Terowongan itu tidak berubah menjadi penerus UDP ketika URL diawali HTTPS atau tujuan mendengarkan pada port 443.
SOCKS5 juga memerlukan jalur UDP
SOCKS5 mendefinisikan asosiasi UDP, tetapi klien dan server sama-sama harus menerapkannya, dan titik akhir penerusan harus dapat dijangkau. Pustaka yang hanya menyediakan dialer TCP SOCKS tidak dapat menyediakan transport datagram hanya karena nama tipenya menyebut SOCKS5.
Demikian pula, komponen alat bernama proxy bisa jadi simulator kehilangan paket untuk pengembangan, bukan klien proxy hulu umum. Periksa antarmuka sebenarnya dan transport yang didukung.
Standar seperti CONNECT-UDP mendefinisikan cara lain membawa UDP melalui sistem proxy HTTP. Standar itu memerlukan dukungan di kedua ujung dan tidak boleh dikacaukan dengan CONNECT tradisional.
Jika klien HTTP mundur ke HTTP/2 atau HTTP/1.1 melalui TCP, permintaan dapat berhasil melalui proxy biasa tanpa ada koneksi HTTP/3 yang dipakai. Catat protokol yang dinegosiasikan ketika perbedaan itu penting.
Jadi pertanyaan kompatibilitas yang berguna bersifat spesifik: dapatkah klien ini membawa datagram QUIC-nya melalui proxy ini dengan mekanisme yang didukung ini? Halaman peramban yang berfungsi atau pemeriksaan port TCP menjawab pertanyaan yang lebih kecil.