طلب HTTP/3 يحتاج مسار وكيل يدعم UDP

العميل الذي يصل بنجاح إلى HTTPS عبر وكيل TCP لم يُنشئ مسارًا لـ HTTP/3. يستخدم HTTP/3 بروتوكول QUIC، ويستخدم QUIC بروتوكول UDP.

نفق HTTP CONNECT العادي يوفّر تدفق TCP إلى وجهته. ولا يتحول إلى مُرحّل UDP عندما يبدأ عنوان URL بـ HTTPS أو عندما تستمع الوجهة على المنفذ 443.

SOCKS5 يحتاج أيضًا مسار UDP

يُعرّف SOCKS5 ارتباط UDP، لكن يجب أن ينفّذه كل من العميل والخادم، ويجب أن تكون نقطة الترحيل قابلة للوصول. المكتبة التي تعرض فقط مُتصل TCP عبر SOCKS لا يمكنها توفير نقل حزم بيانات لمجرد أن اسم نوعها يقول SOCKS5.

وبالمثل، قد يكون المكوّن المسمّى proxy في أداة ما محاكي فقدان حزم تطويريًا وليس عميل وكيل أعلى عامًا. افحص واجهته الفعلية والنقل المدعوم.

تعرّف معايير مثل CONNECT-UDP طريقة أخرى لحمل UDP عبر نظام وكيل HTTP. وهي تتطلب دعمًا في الطرفين ولا ينبغي الخلط بينها وبين CONNECT التقليدي.

إذا رجع عميل HTTP إلى HTTP/2 أو HTTP/1.1 عبر TCP، فقد ينجح الطلب عبر الوكيل العادي بينما لم يُستخدم أي اتصال HTTP/3. سجّل البروتوكول المتفاوض عليه عندما يكون هذا التمييز مهمًا.

لذا فإن سؤال التوافق المفيد محدد: هل يستطيع هذا العميل حمل حزم QUIC الخاصة به عبر هذا الوكيل باستخدام هذه الآلية المدعومة؟ صفحة متصفح تعمل أو فحص منفذ TCP يجيب عن سؤال أصغر.