Permintaan HTTP/3 memerlukan laluan proksi yang menyokong UDP
Bezakan pengangkutan QUIC HTTP/3 daripada terowong TCP HTTP CONNECT biasa dan daripada sokongan UDP pilihan perkhidmatan SOCKS5.
Klien yang berjaya mencapai HTTPS melalui proksi TCP belum mewujudkan laluan untuk HTTP/3. HTTP/3 menggunakan QUIC, dan QUIC menggunakan UDP.
Terowong HTTP CONNECT biasa menyediakan aliran TCP ke destinasinya. Ia tidak bertukar menjadi penyampai UDP apabila URL bermula dengan HTTPS atau destinasi mendengar pada port 443.
SOCKS5 juga memerlukan laluan UDP
SOCKS5 mentakrifkan persatuan UDP, tetapi klien dan pelayan kedua-duanya mesti melaksanakannya, dan titik akhir penyampaian mesti boleh dicapai. Pustaka yang hanya menyediakan pendail TCP SOCKS tidak boleh menyediakan pengangkutan datagram semata-mata kerana nama jenisnya ialah SOCKS5.
Begitu juga, komponen alat bernama proxy mungkin merupakan simulator kehilangan paket pembangunan dan bukan klien proksi huluan umum. Periksa antara muka sebenar dan pengangkutan yang disokongnya.
Piawaian seperti CONNECT-UDP mentakrifkan cara lain untuk membawa UDP melalui sistem proksi HTTP. Ia memerlukan sokongan pada kedua-dua hujung dan tidak boleh dikelirukan dengan CONNECT tradisional.
Jika klien HTTP kembali kepada HTTP/2 atau HTTP/1.1 melalui TCP, permintaan boleh berjaya melalui proksi biasa tanpa sebarang sambungan HTTP/3 digunakan. Rekod protokol yang dirundingkan apabila perbezaan itu penting.
Jadi soalan keserasian yang berguna adalah khusus: bolehkah klien ini membawa datagram QUIC-nya melalui proksi ini dengan mekanisme yang disokong ini? Halaman pelayar yang berfungsi atau pemeriksaan port TCP menjawab soalan yang lebih kecil.