إعدادات النظام وإضافة المتصفح تتيحان ربط البروكسي يدويًا ومرة واحدة، لكنهما لا تصلحان للسكربت أو لأداة جمع البيانات: فهناك يجب ربطه برمجيًا، في عميل HTTP وفي الجلسة وفي برنامج تشغيل المتصفح، مع معالجة الانقطاعات والتحقق من أن الحركة خرجت فعلًا عبر العنوان المطلوب.
صيغة سلسلة الاتصال مع المصادقة
يُبنى عنوان البروكسي للاتصال من الكود وفق مخطط موحّد: protocol://login:password@host:port. يحدد البروتوكول نمط العمل (http أو https أو socks5)، ويأتي اسم المستخدم وكلمة المرور مفصولين بنقطتين رأسيتين قبل الرمز @، ثم المضيف والمنفذ. تقبل مكتبات عملاء HTTP ومعظم برامج تشغيل المتصفحات هذه السلسلة كاملة، دون تمرير اسم المستخدم وكلمة المرور على حدة.
يجب ألا تحتوي كلمة المرور على الرمز @ ولا على غيره من الرموز المحجوزة في عناوين URL دون ترميزها بالنسبة المئوية، وإلا فسيقطع المحلّل السلسلة عند أول رمز خاص، وسيُرسل الاتصال ببيانات اعتماد خاطئة. ينبغي ترميز اسم المستخدم وكلمة المرور المولَّدين تلقائيًا بدالة ترميز URL قبل إدراجهما.
الفرق بين نمطي HTTP وSOCKS
يعمل نمط HTTP على مستوى البروتوكول: يفهم الخادم طلب HTTP ويستطيع قراءة الترويسات. أما حركة HTTPS فلا يفك تشفيرها، بل يمرّر اتصال TLS المشفّر بطريقة CONNECT، ولذلك يصلح نمط HTTP لعناوين http وhttps على حد سواء، رغم اسمه.
يعمل نمط SOCKS (غالبًا SOCKS5) على مستوى أدنى: فهو لا يحلل بروتوكول التطبيق، بل ينقل البايتات بين العميل والوجهة. يتعامل SOCKS5 بشفافية مع HTTP ومع أي اتصالات TCP عشوائية، وعلى عكس نمط HTTP يدعم UDP، وهذا مهم لـ DNS ولبعض مكتبات الشبكة. ويمكن إسناد تحليل الأسماء إلى الخادم نفسه، وعندئذ لا يخرج اسم المضيف بصورة مكشوفة عبر DNS المحلي، وهو أمر حاسم للمواقع الحساسة للموقع الجغرافي. في أعمال الاستخلاص من الويب يكفي عادةً نمط HTTP، أما أدوات الشبكة والتطبيقات ذات البروتوكول الخاص فتحتاج إلى SOCKS5.
الإعداد على مستوى العميل والجلسة وبرنامج تشغيل المتصفح
يمكن تحديد العنوان على ثلاثة مستويات، وهي غير قابلة للاستبدال فيما بينها. مستوى الطلب: يُمرَّر المعامل من جديد في كل استدعاء للعميل؛ ويناسب الحالة التي يمر فيها كل طلب عبر عنوان مختلف، كما في تدوير IP عند كل صفحة. مستوى الجلسة: يُحدَّد العنوان مرة واحدة عند إنشاء الجلسة أو مجمّع الاتصالات، وتستخدم كل الطلبات داخلها مخرجًا واحدًا واتصال keep-alive. وهذا يقلل تكلفة مصافحة TLS ويُبقي IP متسقًا طوال السيناريو، وهو مهم للمواقع التي تتحقق من تطابق العنوان بين خطوات تسجيل الدخول.
أما مستوى برنامج تشغيل المتصفح فهو أكثر تعقيدًا: فوسيط التشغيل القياسي للمتصفح يقبل عادةً المضيف والمنفذ فقط، دون اسم مستخدم وكلمة مرور في السلسلة نفسها. وللقناة التي تتطلب مصادقة تُستخدم إحدى الطرق التالية: إضافة تعترض مربع حوار المصادقة وتُدخل بيانات الاعتماد، أو خادم محلي بلا كلمة مرور ينشئ نفقًا إلى عقدة خارجية تتطلب مصادقة، أو برنامج تشغيل يعترض أحداث الشبكة ويردّ على طلب المتصفح. الشرح خطوة بخطوة في مقال بروكسي لمتصفح مكافحة الكشف (antidetect).
معالجة أخطاء الاتصال
تختلف أخطاء العقدة الوسيطة عن أخطاء الموقع المستهدف، ويجب التمييز بينها بحسب الرمز ونوع الاستثناء، لا بمجرد فشل الطلب. رفض المصادقة: يُرجع الخادم الرمز 407 بدلًا من ردّ الموقع؛ أي أن اسم المستخدم أو كلمة المرور أو سلسلة الاتصال مبنية بشكل خاطئ، أو أن صلاحية الوصول قد انتهت، ولا جدوى من تكرار الطلب دون تغيير. انتهاء المهلة وانقطاع الاتصال: العقدة لا تستجيب أو تقطع الجلسة قبل الرد؛ ويفيد هنا ضبط مهلة معقولة وعدد محدود من المحاولات مع فاصل زمني، لا إعادة المحاولة الفورية.
رفض الموقع المستهدف عبر البروكسي: يُرجع الموقع الرمز 403 أو كابتشا أو إعادة توجيه إلى صفحة تحقق. وهذا ليس خطأ اتصال، بل إشارة إلى أن العنوان استُهلك بالفعل أو أنه لا يناسب المنصة من حيث السمعة، ولا جدوى من تكرار الطلب بالـ IP نفسه، بل يلزم استبداله. ويساعد على التمييز المسبق بين العنوان الصالح والمشكل مقاييس جودة البروكسي.
التحقق من أن الطلب خرج فعلًا عبر البروكسي
قبل السيناريو الرئيسي ينبغي التوجه إلى أي خدمة تُرجع IP الطلب ومقارنته بالعنوان الحقيقي للعميل؛ طلب واحد يستبعد حالة يكون فيها الاتصال مُعدًّا شكليًا بينما يتجه العميل مباشرةً إلى الوجهة بسبب خطأ مطبعي.
النقطة الثانية هي ترويسات العقدة الشفافة: X-Forwarded-For أو Via وفيهما عنوان العميل الأصلي. يقبل مثل هذا الخادم الاتصال لكنه يكشف الـ IP الحقيقي، ولذلك تحتاج المهام التي تشترط إخفاء الهوية إلى نمط غير شفاف بلا هذه الترويسات. وعند تغيير العنوان في كل جلسة ينبغي تضمين التحقق في السيناريو نفسه؛ والتفاصيل في مقال عن تدوير IP عبر API.
أما في برنامج تشغيل المتصفح فالتحقق أعقد: إذ قد يتجاوز المتصفح العقدة المضبوطة عبر WebRTC، الذي ينشئ اتصال P2P مباشرًا ويكشف الـ IP المحلي، وأحيانًا العام أيضًا. وإذا كان السيناريو حساسًا للتسريب فيجب تعطيل WebRTC بمعامل تشغيل مستقل، لا الاعتماد على المسار عبر الخادم.
الأسئلة الشائعة
هل يمكن استخدام البروكسي نفسه في وقت واحد لعميل HTTP ولبرنامج تشغيل المتصفح؟
من الناحية التقنية نعم، إذا كان نوع العنوان يدعم النمطين، لكن عمليًا يُنشأ اتصالان منفصلان: فللعميل والبرنامج منطق مختلف في إعادة المحاولة ومدة بقاء الاتصال، ويزيد المخرج المشترك لعمليتين احتمال الحظر بسبب تطابق نمط الطلبات.
لماذا يعمل البروكسي في عميل HTTP ولا يعمل في آخر مع سلسلة الاتصال نفسها؟
تحلل المكتبات سلسلة الاتصال بطرق مختلفة، وتتعامل بطرق مختلفة مع متغيرات البيئة: فأحد العملاء يقرؤها تلقائيًا، وآخر يتطلب تمرير المعامل صراحةً، وثالث يتجاهل إعدادات النظام. ينبغي تمرير السلسلة صراحةً دون الاعتماد على سلوك ضمني.
هل يجب إغلاق الاتصال بالبروكسي يدويًا بعد كل طلب؟
في نمط الجلسة لا؛ فالاتصال يُعاد استخدامه من المجمّع ويُغلق عند انتهاء مهلة الخمول أو عند إغلاق الجلسة. ولا يُغلق صراحةً إلا إذا كان السيناريو يُبقي الاتصالات مفتوحة لمدة أطول من المهمة، وإلا فمن السهل بلوغ حد الجلسات المتزامنة في القناة ذات التزويد بالعنوان لكل جلسة.
بروكسيات جاهزة باسم مستخدم وكلمة مرور لنمطي HTTP وSOCKS5 مع وثائق الاتصال — في قسم البروكسي. وصيغة الطلبات والحدود للتكامل البرمجي — في API البروكسي.