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 पोर्ट जाँच छोटे प्रश्न का उत्तर देते हैं।