בקשה מסוג HTTP/3 דורשת נתיב פרוקסי עם תמיכת UDP
הבחינו בין תעבורת ה-QUIC של HTTP/3 לבין מנהרות TCP רגילות של HTTP CONNECT ובין תמיכת UDP אופציונלית של שירות SOCKS5.
לקוח שמגיע בהצלחה ל-HTTPS דרך פרוקסי TCP לא הקים נתיב עבור HTTP/3. HTTP/3 משתמש ב-QUIC, ו-QUIC משתמש ב-UDP.
מנהרת HTTP CONNECT רגילה מספקת זרם TCP אל היעד שלה. היא אינה הופכת לממסר UDP כאשר הכתובת מתחילה ב-HTTPS או כאשר היעד מאזין בפורט 443.
גם SOCKS5 זקוק לנתיב UDP
SOCKS5 מגדיר שיוך UDP, אך גם הלקוח וגם השרת חייבים לממש אותו, ונקודת הקצה של הממסר חייבת להיות נגישה. ספרייה שחושפת רק דיאלר TCP של SOCKS אינה יכולה לספק תעבורת datagram רק משום ששם הטיפוס שלה הוא SOCKS5.
באופן דומה, רכיב בכלי בשם proxy עשוי להיות מדמה אובדן מנות לפיתוח ולא לקוח פרוקסי כללי במעלה הזרם. בדקו את הממשק בפועל ואת התעבורה הנתמכת.
תקנים כמו CONNECT-UDP מגדירים דרך אחרת להעביר UDP דרך מערכת פרוקסי HTTP. הם דורשים תמיכה בשני הקצוות ואין לבלבל אותם עם CONNECT המסורתי.
אם לקוח ה-HTTP נופל חזרה ל-HTTP/2 או HTTP/1.1 מעל TCP, בקשה עשויה להצליח דרך הפרוקסי הרגיל מבלי שנעשה שימוש בחיבור HTTP/3. תעדו את הפרוטוקול שנקבע כאשר ההבחנה הזו חשובה.
לכן שאלת התאימות השימושית היא ספציפית: האם הלקוח הזה יכול להעביר את חבילות ה-QUIC שלו דרך הפרוקסי הזה באמצעות המנגנון הנתמך הזה? דף דפדפן שפועל או בדיקת פורט TCP עונה על שאלה קטנה יותר.