درخواست HTTP/3 به مسیر پروکسی با پشتیبانی UDP نیاز دارد
انتقال QUIC در HTTP/3 را از تونل‌های معمولی TCP در HTTP CONNECT و از پشتیبانی اختیاری UDP در سرویس SOCKS5 جدا کنید.
کاربری که با موفقیت از طریق پروکسی TCP به HTTPS می‌رسد، مسیری برای HTTP/3 برقرار نکرده است. HTTP/3 از QUIC استفاده می‌کند و QUIC از UDP.
یک تونل معمولی HTTP CONNECT جریان TCP را به مقصد خود می‌دهد. وقتی URL با HTTPS شروع شود یا مقصد روی پورت 443 گوش دهد، به بازپخش‌کننده UDP تبدیل نمی‌شود.
SOCKS5 هم به مسیر UDP نیاز دارد
SOCKS5 انجمن UDP را تعریف می‌کند، اما هم کارخواه و هم کارساز باید آن را پیاده‌سازی کنند و نقطه پایانی بازپخش باید قابل دسترسی باشد. کتابخانه‌ای که فقط یک dialer TCP برای SOCKS ارائه می‌دهد نمی‌تواند فقط به این دلیل که نام نوعش SOCKS5 است، انتقال داده‌گرام فراهم کند.
به همین ترتیب، مؤلفه‌ای از یک ابزار به نام proxy ممکن است شبیه‌ساز افت بسته در مرحله توسعه باشد، نه کارخواه عمومی پروکسی بالادست. رابط واقعی و انتقال پشتیبانی‌شده آن را بررسی کنید.
استانداردهایی مانند CONNECT-UDP راه دیگری برای حمل UDP از طریق سامانه پروکسی HTTP تعریف می‌کنند. آن‌ها به پشتیبانی در دو طرف نیاز دارند و نباید با CONNECT سنتی اشتباه شوند.
اگر کارخواه HTTP به HTTP/2 یا HTTP/1.1 روی TCP بازگردد، درخواست می‌تواند از طریق پروکسی معمولی موفق شود، در حالی که هیچ اتصال HTTP/3 استفاده نشده است. وقتی این تفاوت مهم است، پروتکل مذاکره‌شده را ثبت کنید.
بنابراین پرسش مفید سازگاری مشخص است: آیا این کارخواه می‌تواند داده‌گرام‌های QUIC خود را با این سازوکار پشتیبانی‌شده از این پروکسی عبور دهد؟ یک صفحه مرورگر کارآمد یا بررسی پورت TCP به پرسشی کوچک‌تر پاسخ می‌دهد.