يتصل خيار --preproxy في curl بوكيل SOCKS قبل الوصول إلى وكيل HTTP أو HTTPS. يدعم هذه السلسلة المحددة، لا قائمة عشوائية من خوادم الوكلاء.

المسار هو العميل → نقطة SOCKS → وكيل HTTP → الوجهة. استبدل نقطتي النهاية التوثيقيتين في الأمر:

curl --preproxy socks5h://203.0.113.10:1080 --proxy http://203.0.113.20:8080 --noproxy '' --connect-timeout 5 --max-time 20 --verbose https://example.com/

يجب أن تتمكن خدمة SOCKS من الوصول إلى عنوان وكيل HTTP ومنفذه. ثم يجب أن يقبل وكيل HTTP طلب الوجهة. إذا كان الوكيل الثاني باسم مضيف، فإن وضع SOCKS الأول يحدد أين يُحل ذلك الاسم؛ وتجنب نقطة نهاية رقمية هذا البحث.

العثور على القفزة الفاشلة

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

اقرأ التتبع التفصيلي بترتيب الاتصال. يقع فشل SOCKS أثناء الوصول إلى الوكيل الثاني قبل قرار وكيل HTTP قبول CONNECT إلى الموقع أو رفضه. سجّل أي مصافحة فشلت.

متى تفيد القفزة الإضافية

قد يفيد هذا الترتيب عندما يكون وكيل HTTP مصرح به قابلًا للوصول عبر مسار SOCKS. لكنه يضيف خدمة ومسار شبكة آخرين قد يفشلان أو يزيدان التأخير. ربط نقاط من قائمة وكلاء عامة لا يضمن الموثوقية أو إخفاء الهوية، ويظل محتاجًا إلى الثقة في الأطراف التي تتعامل مع الاتصال.

يتطلب --preproxy الإصدار curl 7.52.0 أو أحدث؛ وقد لا تدعم التطبيقات الأخرى هذا الترتيب.

مقالات ذات صلة