HTTP/3 요청에는 UDP 지원 프록시 경로가 필요합니다
HTTP/3의 QUIC 전송을 일반 HTTP CONNECT TCP 터널 및 SOCKS5 서비스의 선택적 UDP 지원과 구분하십시오.
TCP 프록시를 통해 HTTPS에 성공적으로 도달한 클라이언트가 HTTP/3 경로를 확립한 것은 아닙니다. HTTP/3은 QUIC을 사용하고, QUIC은 UDP를 사용합니다.
일반 HTTP CONNECT 터널은 목적지까지 TCP 스트림을 제공합니다. URL이 HTTPS로 시작하거나 목적지가 443 포트에서 수신한다고 해서 UDP 릴레이로 바뀌지는 않습니다.
SOCKS5도 UDP 경로가 필요합니다
SOCKS5는 UDP 연결을 정의하지만 클라이언트와 서버 모두 이를 구현해야 하고, 릴레이 엔드포인트에 도달할 수 있어야 합니다. SOCKS TCP 다이얼러만 노출하는 라이브러리는 타입 이름이 SOCKS5라는 이유만으로 데이터그램 전송을 제공할 수 없습니다.
마찬가지로 proxy라는 이름의 도구 구성 요소가 범용 업스트림 프록시 클라이언트가 아니라 개발용 패킷 손실 시뮬레이터일 수 있습니다. 실제 인터페이스와 지원되는 전송을 확인하십시오.
CONNECT-UDP 같은 표준은 HTTP 프록시 시스템을 통해 UDP를 전달하는 다른 방법을 정의합니다. 양쪽 끝의 지원이 필요하며 기존 CONNECT와 혼동해서는 안 됩니다.
HTTP 클라이언트가 TCP 위의 HTTP/2 또는 HTTP/1.1로 폴백하면 HTTP/3 연결을 사용하지 않고도 일반 프록시를 통해 요청이 성공할 수 있습니다. 이 구분이 중요할 때는 협상된 프로토콜을 기록하십시오.
따라서 유용한 호환성 질문은 구체적입니다. 이 클라이언트가 이 지원되는 메커니즘으로 이 프록시를 통해 QUIC 데이터그램을 전달할 수 있는가? 작동하는 브라우저 페이지나 TCP 포트 검사는 더 작은 질문에 답할 뿐입니다.