Ang kahilingang HTTP/3 ay nangangailangan ng proxy path na may UDP
Ihiwalay ang QUIC transport ng HTTP/3 sa mga karaniwang HTTP CONNECT TCP tunnel at sa opsyonal na suporta sa UDP ng isang serbisyong SOCKS5.
Ang kliyenteng matagumpay na nakakaabot sa HTTPS sa pamamagitan ng TCP proxy ay hindi pa nakapagtatag ng ruta para sa HTTP/3. Gumagamit ang HTTP/3 ng QUIC, at ang QUIC ay gumagamit ng UDP.
Ang karaniwang HTTP CONNECT tunnel ay nagbibigay ng TCP stream patungo sa destinasyon nito. Hindi ito nagiging UDP relay kapag nagsisimula sa HTTPS ang URL o nakikinig ang destinasyon sa port 443.
Kailangan din ng SOCKS5 ang UDP path
Tinutukoy ng SOCKS5 ang UDP association, ngunit dapat itong ipatupad ng kliyente at ng server, at ang relay endpoint ay dapat maabot. Ang isang library na nag-aalok lamang ng SOCKS TCP dialer ay hindi makapagbibigay ng datagram transport dahil lamang sinasabi ng pangalan ng uri nito na SOCKS5.
Gayundin, ang isang bahagi ng tool na tinatawag na proxy ay maaaring isang development packet-loss simulator sa halip na isang pangkalahatang upstream-proxy client. Suriin ang aktwal na interface at ang sinusuportahang transport.
Ang mga pamantayan tulad ng CONNECT-UDP ay tumutukoy ng ibang paraan upang magdala ng UDP sa isang HTTP proxy system. Nangangailangan sila ng suporta sa magkabilang dulo at hindi dapat ipagkamali sa tradisyonal na CONNECT.
Kung ang HTTP client ay bumalik sa HTTP/2 o HTTP/1.1 sa TCP, maaaring magtagumpay ang kahilingan sa karaniwang proxy nang walang ginamit na koneksyong HTTP/3. Itala ang napagkasunduang protocol kapag mahalaga ang pagkakaibang iyon.
Kaya ang kapaki-pakinabang na tanong sa pagiging tugma ay tiyak: maidaan ba ng kliyenteng ito ang mga datagram nitong QUIC sa proxy na ito gamit ang sinusuportahang mekanismong ito? Ang gumaganang pahina ng browser o pagsusuri ng TCP port ay sumasagot sa mas maliit na tanong.