يُفتح الوصول إلى خدمة بروكسي مدفوعة بإحدى طريقتين: إما أن ترسل مع كل طلب اسم المستخدم وكلمة المرور ، أو أن تعرّف عنوان IP العام الخاص بك في لوحة المزوّد وتنشئ whitelist (قائمة مسموح بها). وكلتاهما تحلان المشكلة نفسها — "هل هذا الاتصال فعلًا للمشترك؟" — لكنهما تؤديان إلى نتائج مختلفة جدًا في الاستخدام اليومي.
في هذا المقال نتناول كيف تعمل الطريقتان على مستوى البروتوكول، وأيهما الصحيحة في كل سيناريو، ورموز الأخطاء التي ستواجهها.
الطريقة 1: اسم المستخدم وكلمة المرور
في هذه الطريقة تُرسل بيانات الهوية إلى البروكسي مع كل اتصال. ويختلف الشكل بحسب البروتوكول:
- بروكسي HTTP:
Proxy-Authorization: Basic <base64(kullanici:sifre)>تُضاف الترويسة. - SOCKS5: تُجرى مفاوضة فرعية username/password المعرّفة في RFC 1929؛ ويُرسل اسم المستخدم وكلمة المرور بصيغة ثنائية.
أما التدفق في جانب HTTP فهو كالتالي: يرسل العميل الطلب دون بيانات هوية، فيرد البروكسي بـ 407 Proxy Authentication Required ، فيضيف العميل بيانات الهوية ويعيد الطلب.
تنفّذ معظم العملاء هاتين الجولتين تلقائيًا. فـ curl والمتصفحات تضيف بيانات الهوية وتعيد الطلب عند رؤية 407؛ أما مكتبات HTTP البسيطة فلا تعيد المحاولة أحيانًا وتعطي خطأً مباشرة.
Basic الطريقة لا تشفّربيانات الهوية، بل تقوم بترميزها بـ Base64 فقط. وBase64 ترميز قابل للعكس. ولهذا تعتمد سرية بيانات الهوية على أن يكون الاتصال المتجه إلى البروكسي نفسه آمنًا.
الطريقة 2: IP Whitelist
في نموذج whitelist لا توجد كلمة مرور. فتضيف عنوان IP العام الخاص بك إلى لوحة المزوّد؛ ولا يقبل البروكسي إلا الاتصالات القادمة من ذلك العنوان. وبما أنه لا تُنقل بيانات هوية، يصبح جانب العميل بالغ البساطة: curl -x http://proxy.example.com:8080 https://example.com يكفي.
والسؤال الحاسم في هذا النموذج هو: هل عنوان IP العام الخاص بك ثابت؟ في معظم اشتراكات الإنترنت المنزلي يكون IP ديناميكيًا ويتغير عند إعادة تشغيل المودم. وعندما يتغير تصبح whitelist غير صالحة وتُرفض جميع الاتصالات.
يتلخص الاختيار إلى حد كبير في سؤال "هل لديك IP ثابت". فبالنسبة إلى الأتمتة العاملة على خادم تكون whitelist أنسب، وللاستخدام المتنقل يكون اسم المستخدم/كلمة المرور أنسب.
أيهما في أي سيناريو؟
scraper أو بوت يعمل على خادم
عنوان IP الخاص بـ VPS الخاص بك ثابت؛ اختر whitelist. فلا تُضمَّن بيانات الهوية في الكود أو في متغيّر بيئة، ويتقلص سطح التسرّب. سيناريوهات الأتمتة هذا هو الخيار الافتراضي الذي نوصي به لأجل
الاستخدام اليدوي من حاسوب محمول
إذا كنت تتنقل بين المكتب والمنزل والمقهى فإن IP يتغير باستمرار. استخدم اسم المستخدم/كلمة المرور؛ فهو يعمل دون مشكلات من أي شبكة.
الاستخدام المشترك داخل فريق
إذا كنت بحاجة إلى معرفة من استهلك كم من حركة المرور فافتح مستخدمًا منفصلًا لكل شخص. ففي whitelist يظهر الفريق كله تحت هوية واحدة.
تعدد الملفات الشخصية مع متصفح antidetect
إذا كان سيُسنَد عنوان IP خروج مختلف لكل ملف شخصي فإن اسم المستخدم/كلمة المرور إلزامي؛ لأن اختيار الجلسة يُرمَّز في الغالب داخل اسم المستخدم (مثلًا user-session-a1).
تضمين معلومات الجلسة في اسم المستخدم
هناك نمط شائع في تجمّعات residential: إذ لا يكون اسم المستخدم هوية فحسب، بل يحمل في الوقت نفسه أمرًا . على سبيل المثال:
يختلف حرف الفاصل وأسماء المعاملات من مزوّد إلى آخر. اعتمد وثيقة لوحتك؛ فالصيغة هنا لبيان البنية فقط.
ميزة هذا التصميم أنه لا يتطلب أي استدعاء API في جانب العميل: فأنت تغيّر الدولة أو الجلسة بتغيير اسم المستخدم. أما عيبه فهو طول بيانات الهوية، وأن الأخطاء الإملائية تؤدي إلى تغيّرات صامتة في السلوك. منطق rotating proxy نتناول بالتفصيل في مقالنا الذي يشرحه تأثير هذا النموذج على إدارة الجلسات.
الأخطاء الشائعة
الفرق بين 407 و403 حاسم: فـ407 تقول "أظهر هويتك"، بينما 403 تعني "رأيت هويتك، ولا صلاحية لديك".
فخّ الأحرف الخاصة
عند كتابة بيانات الهوية بصيغة URL تختلط بعض أحرف كلمة المرور بالفاصل. http://user:p@ss@ip:8080 في هذا التعبير يُظن أن الثاني @ فاصل، فيتعذر إنشاء الاتصال. والحل هو ترميز النسبة المئوية:
| الحرف | الشكل المرمَّز | الحرف | الشكل المرمَّز |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
والنهج الأمتن هو تمرير بيانات الهوية إلى حقول منفصلة في العميل بدلًا من تضمينها في عنوان URL. ويدعم ذلك Python requests، وNode undici وخيار curl --proxy-user الخيار يدعم ذلك.
قراءة بيانات الهوية من متغيّر بيئة بدلًا من تضمينها في الكود يمنع تسرّبها إلى نظام التحكم في الإصدارات ويسهّل تدويرها في الوقت نفسه.
ما الذي يتغير من الناحية الأمنية؟
تحمل الطريقتان مخاطر مختلفة. ففي نموذج اسم المستخدم/كلمة المرور يمكن سرقة السر: يكفي سطر أوامر يقع في ملف سجل، أو ملف إعداد يتسرب إلى نظام التحكم في الإصدارات، أو لقطة شاشة. أما في نموذج whitelist فلا يوجد سر، لكن هناك خطر مشاركة IP : إذ يمكن لكل من في شبكة المكتب نفسها أن يستخدم بروكسيك دون أن يدري.
وأمتن إعداد هو الجمع بين الاثنين: ضيّق المصدر بـ whitelist، وأضف فوقه اسم المستخدم/كلمة المرور. ويدعم معظم المزوّدين المؤسسيين هذا النموذج الهجين. وإذا كنت تتساءل عما يراه البروكسي من ناحية الخصوصية فإن هل البروكسي آمن يقدم مقالنا إطارًا شاملًا؛ ولاختبارات التسرّب DNS leak و WebRTC leak يمكنك استخدام أدواتنا.
قواعد عملية لإدارة بيانات الهوية
- استخدم متغيّر بيئة، ولا تكتبها داخل الكود.
- افتح بيانات هوية منفصلة لكل بيئة: لا تتشارك بيئات التطوير والاختبار والإنتاج كلمة المرور نفسها.
- حدّد حصصًا وحدودًا؛ حتى لا تستهلك بيانات هوية مسرّبة حركة مرور بلا حدود.
- دوّرها بانتظام؛ وغيّرها حتمًا بعد مغادرة أحد أعضاء الفريق.
- أخفِها في السجلات؛ حتى لا يكتب مخرج التصحيح كلمة المرور بنص صريح.
الخلاصة
تُعد IP whitelist الحل الأنظف والأقل خطرًا من حيث التسرّب على الخوادم ذات IP الثابت. أما اسم المستخدم وكلمة المرور فلا غنى عنهما في الاستخدام المتنقل وفي السيناريوهات التي تتطلب جلسات متعددة. وعند اتخاذ القرار يكفي أن تجيب عن الأسئلة: "هل عنوان IP الخاص بي ثابت"، و"كم شخصًا سيستخدمه"، و"هل يلزمني إرسال معامل جلسة". ولاختبار إعدادك أداة فحص البروكسي يمكنك استخدامه، وعنوان IP الخروج الخاص بك عنوان IP الخاص بي يمكنك التحقق منه بواسطته.