Una richiesta HTTP/3 richiede un percorso proxy compatibile UDP
Distinguere il trasporto QUIC di HTTP/3 dai tunnel TCP HTTP CONNECT ordinari e dal supporto UDP opzionale di un servizio SOCKS5.
Un client che raggiunge HTTPS con successo tramite un proxy TCP non ha stabilito un percorso per HTTP/3. HTTP/3 usa QUIC e QUIC usa UDP.
Un tunnel HTTP CONNECT ordinario fornisce un flusso TCP verso la sua destinazione. Non diventa un ripetitore UDP quando l'URL inizia con HTTPS o quando la destinazione ascolta sulla porta 443.
Anche SOCKS5 ha bisogno del percorso UDP
SOCKS5 definisce un'associazione UDP, ma sia il client sia il server devono implementarla, e l'endpoint di ripetizione deve essere raggiungibile. Una libreria che espone solo un dialer TCP SOCKS non può fornire un trasporto a datagrammi solo perché il nome del suo tipo dice SOCKS5.
Allo stesso modo, un componente di uno strumento chiamato proxy può essere un simulatore di perdita di pacchetti per lo sviluppo e non un client proxy upstream generico. Esaminate la sua interfaccia reale e il trasporto supportato.
Standard come CONNECT-UDP definiscono un altro modo per trasportare UDP attraverso un sistema proxy HTTP. Richiedono supporto su entrambe le estremità e non vanno confusi con il CONNECT tradizionale.
Se il client HTTP ripiega su HTTP/2 o HTTP/1.1 su TCP, una richiesta può riuscire tramite il proxy ordinario senza che sia stata usata alcuna connessione HTTP/3. Registrate il protocollo negoziato quando questa distinzione conta.
La domanda utile di compatibilità è quindi specifica: questo client può trasportare i suoi datagrammi QUIC attraverso questo proxy con questo meccanismo supportato? Una pagina del browser funzionante o un controllo della porta TCP risponde a una domanda più piccola.