HTTP أم SOCKS5: أي عنوان IP للوكيل تختار؟
اختر نوع الوكيل حسب تطبيقك وحركة البيانات المدعومة وحاجتك إلى DNS من جهة الوكيل.
افتح إعدادات الوكيل في تطبيقك أولًا. تحدد بروتوكولاته المدعومة إدخالات القائمة التي يمكنك استخدامها؛ فلا يضيف اسم مبهر أو رقم منفذ مألوف دعمًا إلى العميل.
| تطبيقك أو مهمتك | ما تختاره وتتحقق منه |
|---|---|
| يوفر حقل وكيل HTTP فقط | نقطة اتصال مناسبة من قائمة وكلاء HTTP. اختبر HTTPS CONNECT أيضًا إن احتجت إلى وجهات HTTPS. |
| يدعم SOCKS5 ويحتاج خيارات اتصال أو DNS | نقطة SOCKS5 تدعم الخيارات المطلوبة في الطرفين. |
| يحتاج UDP | تحقق من دعم UDP في العميل ونقطة الاتصال؛ لا تكفي تسمية SOCKS5 وحدها. |
| يتطلب SOCKS4 | نقطة SOCKS4 متوافقة ووضع عميل مطابق. |
| لا يدعم الوكلاء | عنوان IP من قائمة لا يضبط التطبيق تلقائيًا. |
غالبًا يكفي وكيل HTTP لطلبات الويب وواجهات API. فهو يمرر HTTP، ويحمل HTTPS عبر CONNECT عند السماح بذلك. نجاح صفحة HTTP عادية لا يثبت دعم النفق؛ فقد تتطلب الخدمة مصادقة النفق أو تقيّد الوجهات والمنافذ.
يعمل SOCKS تحت طبقة طلبات HTTP. يطلب منه تطبيق متوافق إنشاء اتصال دون تفسير طلب HTTP، مما يجعله مفيدًا لحركة أخرى مدعومة أيضًا. يحدد SOCKS5 عناوين IPv4 وIPv6 وأسماء النطاقات والمصادقة وارتباط UDP. وقد ينفذ تطبيق أو وكيل مجاني معين بعض هذه الميزات فقط. مسار TCP SOCKS للمتصفح لا يشمل تلقائيًا تطبيقًا آخر أو خدمة UDP.
أين يُحل اسم الوجهة؟
في curl، تحدد صياغة عنوان SOCKS5 URL مكان حل DNS للوجهة: يحل socks5:// محليًا؛ ويطلب socks5h:// من الوكيل الحل. قد تجعل رؤى DNS المختلفة خيارًا يعمل والآخر يفشل. وقد تستخدم عملاء أخرى مربع اختيار أو خيارًا مستقلًا. اختيار SOCKS5 وحده لا يثبت أن كل استعلام DNS يمر عبره.
إمكانات SOCKS4 أقل؛ ويضيف SOCKS4a التعامل مع أسماء المضيفين. إذا دعم العميل والخدمة SOCKS5 ولم يوجد سبب للبروتوكول الأقدم، فإدخال SOCKS5 مناسب خيار أول معقول. إدخال نقطة SOCKS4 مع إبقاء العميل بوضع SOCKS5 هو عدم تطابق بروتوكولي.
عند مطابقة البروتوكول، اختبر الوجهة الفعلية وحدد أول فشل. لا يقيس HTTP ولا SOCKS5 إخفاء الهوية؛ فالثقة بالمشغّل وTLS للوجهة والمسار الحقيقي للتطبيق ما زالت تحدد الحماية التي تحصل عليها.