كلمة التحقق (الكابتشا) عبر البروكسي ليست عقاباً على استخدام البروكسي نفسه، بل هي سؤال يطرحه نظام الحماية: «هل أنت إنسان؟». وهي تظهر عبر البروكسي أكثر لثلاثة أسباب: العنوان مشترك مع أشخاص وبرامج أخرى، وله سجل استخدامات سابق، وبقية إشارات المتصفح غالباً ما تتناقض معه. لا يمكن التخلص من الكابتشا تماماً — فهي مصممة لهذا الغرض تحديداً — لكن يمكن جعلها تظهر بشكل أقل بكثير. لنستعرض ما تقوله Google وYandex وCloudflare نفسها عن هذا الأمر، ولماذا ترفع البروكسيات احتمال التحقق، وما الإجراءات التي تساعد فعلاً وأيها تزيد الوضع سوءاً.
ما تقوله الخدمات نفسها
Google: «حركة مرور غير معتادة من شبكتك»
تعرض Google هذه الصفحة عندما تصل طلبات آلية إلى محرك البحث من الشبكة. وتذكر في صفحة المساعدة الأسباب: برامج ضارة على الحاسوب، شبكة مشتركة في مدرسة أو مكتب يرسل فيها أحدهم طلبات آلية، VPN يقوم مستخدمون آخرون فيه بالأمر ذاته، أنفاق IPv6، ومزود خدمة يتشارك مشتركوه العناوين. وتقدم التوصيات نفسها: حل reCAPTCHA، فحص الحاسوب من البرامج الضارة، التواصل مع مسؤول الشبكة، إزالة VPN أو استبداله — إذ تقول Google إن بعض خدمات VPN لا تسمح بالتمييز بين حركة المرور الشرعية وإساءة الاستخدام — والتواصل مع مزود الخدمة.
لم يُذكر البروكسي صراحة في صفحة المساعدة، لكن الآلية ذاتها: أنت تتشارك العنوان مع آخرين، وGoogle لا تراك أنت بل ترى كل حركة المرور الصادرة من هذا العنوان.
Yandex: «طلبات كثيرة متشابهة»
في صفحة مساعدة Yandex السبب واحد للكابتشا: الخدمة تتلقى طلبات كثيرة متشابهة وتريد التأكد من أن إنساناً يرسلها وليس روبوتاً. وبالنسبة للبروكسي، هذا يعني أن الأمر لا يتعلق بوتيرتك أنت فقط، بل بوتيرة كل من يستخدم العنوان نفسه.
reCAPTCHA v3: تقييم بدلاً من الصور
النسخة الثالثة من reCAPTCHA لا تعرض أي مهام على الإطلاق: وفقاً لوثائق Google، فهي لا تقاطع المستخدم أبداً، بل تمنح تقييماً من 0.0 إلى 1.0، حيث 1.0 تعني على الأرجح تفاعلاً شرعياً، و0.0 تعني على الأرجح روبوتاً. وتقترح Google افتراضياً على المواقع عتبة 0.5. أما ما يُفعل بالتقييم المنخفض — عرض التحقق، أو طلب تأكيد تسجيل الدخول، أو الحجب — فقراره يعود إلى الموقع نفسه.
Cloudflare: تقييم وثلاثة أنواع من التحقق
تقيّم Cloudflare كل طلب على مقياس من 1 إلى 99: 1 يعني طلباً آلياً، و99 يعني طلباً من إنسان. ويشمل التقييم استدلالات (مقارنة بقاعدة البصمات المعروفة)، وتعلماً آلياً يمنح معظم التقييمات، وفحوصات JavaScript تلتقط المتصفحات بلا واجهة وأدوات الأتمتة الأخرى. ويحصل الزائر على التحقق عندما يُفعَّل أحد قواعد جدار الحماية أو وحدة الحماية من الروبوتات أو تحديد المعدل. وأنواع التحقق ثلاثة:
- غير تفاعلي — ينفذ المتصفح JavaScript، عادة في أقل من خمس ثوانٍ، دون أي مطلوب من الإنسان؛
- مُدار — يختار Cloudflare نوع التحقق بنفسه؛ ومعظم الناس يجتازونه تلقائياً ويرون «تم بنجاح»؛
- تفاعلي — يتطلب إجراءً؛ ويوصي Cloudflare نفسه المواقع باستخدام المُدار بدلاً منه.
بعد اجتياز التحقق بنجاح يحصل المتصفح على ملف تعريف الارتباط cf_clearance، ولا يُعاد التحقق منه لفترة ما. وهذا مهم بالنسبة للبروكسي، وسيتضح السبب أدناه.
لماذا تظهر الكابتشا أكثر عبر البروكسي
- العنوان مشترك وله سجل استخدامات. الآلية ذاتها المذكورة مع VPN في مساعدة Google: إذا أُرسلت طلبات آلية من العنوان قبلك، فإن الشك يقع على كل من يستخدمه. والبروكسيات المشتركة الرخيصة تعاني من هذا أكثر من غيرها.
- نوع العنوان. تعرف أنظمة الحماية أي العناوين تنتمي إلى شركات الاستضافة. فعنوان IP لخادم، بالنسبة لمحرك بحث أو شبكة اجتماعية، هو بحد ذاته سبب للتدقيق: فالناس لا يجلسون في مراكز البيانات. وتشرح مقالة البروكسيات السكنية والخادمية والجوالة كيفية تركيب أنواع العناوين.
- المعدل. «طلبات كثيرة متشابهة» هي الصياغة المباشرة لـ Yandex. والبرنامج الذي يفتح الصفحات أسرع من الإنسان سيحصل على كابتشا من أي عنوان.
- التناقض بين الإشارات. عنوان IP من ألمانيا، بينما المنطقة الزمنية ولغة المتصفح من موسكو؛ عنوان جوال، بينما البصمة لمتصفح حاسوب. وكل تناقض من هذا القبيل يخفض التقييم. ولمعرفة الإشارات التي تجمعها أنظمة الحماية — راجع مقالتي كيف تعمل أنظمة مكافحة الروبوتات وما هي بصمة TLS.
- لا سجل ولا ملفات تعريف ارتباط. المتصفح الذي يأتي في كل مرة «من صفحة بيضاء» ومن عنوان جديد يبدو كزائر جديد في كل زيارة. وهو يفقد
cf_clearanceوالثقة المتراكمة معاً. - الأتمتة. المتصفحات بلا واجهة والمتصفحات المُدارة برمجياً تفضح نفسها عبر JavaScript — ويسمي Cloudflare هذا صراحة آلية كشف مستقلة.
ما يساعد فعلاً
- اختيار نوع العنوان المناسب. بالنسبة للمواقع ذات الحماية الصارمة — استخدم بروكسيات سكنية أو جوالة أو سكنية ثابتة (ISP) بدلاً من الخادمية. فعناوين مشغلي الجوال يتشاركها آلاف المشتركين، وليس من مصلحة المواقع حجبها.
- عدم استخدام البروكسيات المشتركة. العنوان المخصص مسؤول عن سلوكك أنت فقط، لا عن سلوك الآخرين.
- الإبقاء على العنوان بدلاً من تغييره مع كل طلب. تحافظ الجلسة الثابتة (sticky) على العنوان وملفات تعريف الارتباط بعد اجتياز التحقق. أما التبديل مع كل طلب على المواقع التي تستخدم Cloudflare فيعني تحققاً جديداً مع كل طلب (تبديل IP والجلسات الثابتة).
- خفض الوتيرة. الفواصل بين الطلبات والتوازي المعقول يزيلان السبب الرئيسي بحسب Yandex. والقواعد العامة في مقالة robots.txt والحدود والجمع المهذب للبيانات.
- مواءمة الإشارات. يجب أن تتوافق المنطقة الزمنية ولغة المتصفح وموقعه الجغرافي مع بلد عنوان IP، وألا يكشف WebRTC عنوانك الحقيقي. وتقوم المتصفحات المضادة للكشف بذلك تلقائياً (ما هو المتصفح المضاد للكشف).
- حفظ ملفات تعريف الارتباط بين الجلسات. ملف تعريف المتصفح الذي يحمل سجلاً يجتاز التحققات أسهل من ملف جديد في كل مرة.
- فحص العنوان قبل العمل. القوائم السوداء، ونوع IP في القواعد، والتسريبات — وترتيب الفحص موصوف في مقالة كيف تفحص البروكسي.
ما لا يساعد
- تغيير العنوان بعد كل كابتشا. العنوان الجديد من المجموعة نفسها عادة ما يحمل السمعة ذاتها، والتغيير المستمر بحد ذاته يبدو مريباً.
- شراء أرخص البروكسيات «بكميات كبيرة». ألف عنوان خادمي مشترك ستمنحك ألف كابتشا.
- حل الكابتشا آلياً بالالتفاف على الحماية. توجد خدمات كهذه، لكنها التفاف مباشر على حماية الموقع وغالباً مخالفة لقواعده: فGoogle مثلاً تصنف الطلبات الآلية إلى محرك البحث ضمن الممنوع دون إذن. وإذا كان الموقع مصرّاً على التمييز بين البشر والبرامج، فالأفضل لل مهام الآلية البحث عن API رسمي.
إذا ظهرت الكابتشا بدون بروكسي
تشير مساعدة Google إلى أين تبحث: برنامج ضار على الحاسوب، شبكة مشتركة في العمل أو الدراسة، VPN، أو مزود خدمة يُخرج كثيراً من المشتركين عبر عنوان واحد. كما أن الإنترنت الجوال يُخرج آلاف الأشخاص عبر عناوين مشتركة، لذا قد تحصل الكابتشا أحياناً بسبب نشاط الآخرين. افحص حاسوبك، وأوقف VPN والإضافات التي ترسل طلبات باسمك، وجرّب شبكة أخرى.
باختصار: العَرَض، السبب، ما العمل
| العَرَض | السبب المحتمل | ما العمل |
|---|---|---|
| Google تعرض فوراً «حركة مرور غير معتادة» | عنوان مشترك بسجل سيئ | عنوان مخصص؛ نوع بروكسي آخر |
| Yandex تعرض كابتشا بعد عدة طلبات | طلبات كثيرة متشابهة | خفض الوتيرة؛ توزيع الطلبات |
| Cloudflare تتحقق في كل زيارة | العنوان يتغير أو ملفات تعريف الارتباط لا تُحفظ | جلسة ثابتة (sticky)؛ حفظ ملفات تعريف الارتباط |
| التحقق لا يُجتاز تلقائياً | تناقض في الإشارات أو مؤشرات أتمتة | مواءمة المنطقة الزمنية واللغة مع IP؛ متصفح عادي |
| كابتشا على كل عناوين المجموعة دفعة واحدة | المجموعة موسومة بالكامل (شبكة فرعية واحدة مثلاً) | مزود آخر أو عناوين من شبكات فرعية مختلفة |
وللحالة الخاصة بالشبكات الفرعية IPv6 التي تقيدها المواقع بالكامل — راجع مقالة بروكسيات IPv6.
أسئلة شائعة
لماذا تعرض Google كابتشا رغم أنني أرسل طلبين فقط؟
لأن Google تقيّم كل حركة المرور من عنوانك، لا حركتك أنت فقط. وإذا كان العنوان مشتركاً — VPN أو بروكسي أو شبكة مكتب أو مزود خدمة — فإن الطلبات الآلية للآخرين تقع عليك أيضاً. وهذا ما تقوله مساعدة Google صراحة.
هل يساعد تغيير IP في التخلص من الكابتشا؟
مرة واحدة قد يساعد أحياناً، لكن إذا كان العنوان الجديد من المجموعة نفسها فعادة ما يحمل السمعة ذاتها. كما أن التغيير المستمر للعنوان على المواقع التي تستخدم Cloudflare يُبطل التحقق المُجتاز.
أي البروكسيات تلتقط الكابتشا أقل من غيرها؟
العناوين السكنية المخصصة، والجوالة، والسكنية الثابتة مع جلسة دائمة. أما البروكسيات الخادمية والمشتركة فهي الأكثر التقاطاً للكابتشا.
لماذا يتحقق مني Cloudflare مراراً وتكراراً؟
بعد التحقق يمنح Cloudflare ملف تعريف الارتباط cf_clearance. وإذا تغيّر العنوان مع كل طلب أو لم يحفظ المتصفح ملفات تعريف الارتباط، تضيع هذه العلامة ويتكرر التحقق.
ماذا يعني تقييم reCAPTCHA v3؟
هو رقم من 0.0 إلى 1.0: كلما اقترب من 1.0 زاد الشبه بالإنسان. وتنصح Google المواقع افتراضياً بعتبة 0.5، أما ما يُفعل بالتقييم المنخفض فقراره يعود إلى الموقع نفسه.