وكيل الذكاء الاصطناعي الذي يتصفح المواقع بنفسه - Claude مع Playwright MCP، browser-use، وBrowserbase السحابية - يواجه نفس الجدار الذي يواجهه المحلل العادي: بضع عشرات من الطلبات من عنوان واحد، وبعد ذلك بدلاً من الصفحة، يظهر تحدي Cloudflare. الفرق هو أن الوكيل لا يعرف كيف يشعر بالإهانة ويستمر في الدوران، محرقًا الرموز في محاولات "الضغط على الزر الذي لا يوجد".
يمكن علاج ذلك باستخدام بروكسي. لكن توصيل البروكسي بالوكيل يتبين أنه غير واضح بشكل غير متوقع: نصف التعليمات على الإنترنت تقترح بناء جملة يتجاهله Chromium بصمت. أدناه - تكوينات عملية لأكثر ثلاث مجموعات شيوعًا في عام 2026 وتحليل للفخاخ التي يتعثر فيها الجميع.
من يحتاج إلى ذلك
دليل لأولئك الذين قاموا بالفعل بتشغيل الوكيل وواجهوا أحد الأعراض:
- الوكيل ينفذ 10-20 خطوة، ثم كل خطوة تالية تعيد كابتشا أو صفحة "تحقق أنك إنسان"؛
- الوكيل يرى محتوى مختلف عن الذي تراه: الأسعار، النتائج وتوافر المنتج يظهرها الموقع تحت عنوان IP الخادم الخاص بك، وليس تحت الدولة المطلوبة؛
- الوكيل يعمل في السحابة (VPS، GitHub Actions، حاوية)، وعنوان مركز البيانات للمضيف قد تم وضع علامة عليه بالفعل كعنوان بوت؛
- لقد قمت بتحديد بروكسي مع اسم مستخدم وكلمة مرور، لكن المتصفح يبدأ كما لو لم يكن هناك بروكسي على الإطلاق.
إذا كنت لا تزال في مرحلة "لماذا يتم حظر الوكلاء على الإطلاق" - اقرأ أولاً التحليل حول كيف تميز أنظمة مكافحة البوتات بين متصفح الوكيل والإنسان: هناك إشارات الكشف، وهنا - ممارسة توصيل البروكسي.
الفخ رقم 1: Chromium لا يقبل اسم المستخدم وكلمة المرور في سلسلة البروكسي
أكثر الأخطاء شيوعًا، وتكلف الناس ساعات من التصحيح. الشكل الكلاسيكي للسلسلة من المزود هو user:pass@host:port. تقوم بإدخالها في علم تشغيل المتصفح:
--proxy-server="http://user:[email protected]:8080"
ولا يعمل شيء. Chromium لا يدعم تمرير بيانات الاعتماد داخل علم --proxy-server: تظهر رسالة خطأ في وحدة التحكم حول بروكسي غير مدعوم، بينما يمر الترافيك. إذا قمت بإزالة بيانات الاعتماد وترك فقط host:port، سيظهر المتصفح في الوضع العادي نافذة النظام لطلب اسم المستخدم وكلمة المرور - وفي هذه النقطة سيتوقف كل شيء، لأن الوضع headless ليس لديه نافذة ولا يوجد من يضغط فيها.
من هنا، تتبع ثلاث طرق عملية، ويجب اختيارها بوعي:
- المصادقة عبر IP (قائمة بيضاء). الخيار الأنظف للوكلاء. تضيف عنوان الجهاز الذي يعمل عليه الوكيل إلى القائمة البيضاء في لوحة التحكم الخاصة بالمزود - ومن ثم تتصل بدون اسم مستخدم وكلمة مرور، باستخدام سلسلة بسيطة
host:port. يبدأ علم--proxy-serverفي العمل كما هو مقصود، ولا يسأل headless عن أي شيء آخر. يدعم ProxyCove كلا الطريقتين - اسم المستخدم:كلمة المرور، وIP-whitelist، في نفس الوقت، لذا يمكنك إنشاء قائمة بيضاء للوكيل، وترك كلمة المرور للمهام اليدوية. - تمرير بيانات الاعتماد على مستوى API، وليس العلم. Playwright، Puppeteer وbrowser-use يمكنهم قبول
usernameوpasswordكحقول منفصلة - هذه ليست نفس الآلية التي يستخدمها علم سطر الأوامر، وهي تعمل. مناسبة عندما تكتب كود الوكيل بنفسك. - Relay محلي. تقوم بإعداد بروكسي بدون كلمة مرور، يقوم بإعادة توجيه الطلبات إلى upstream بكلمة مرور، وتحدد للوكيل عنوان محلي. خيار للحالات التي لا تتوفر فيها القائمة البيضاء: على سبيل المثال، عنوان IP للجهاز يتغير.
Playwright MCP: تكوين يعمل حقًا
Playwright MCP من Microsoft - هو اليوم المعيار الفعلي للوكلاء الذين يحتاجون إلى متصفح حقيقي. يتم تعيين البروكسي بواسطة معلمات الخادم مباشرة في تكوين عميل MCP:
{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}
ما هو مهم هنا بالنقاط:
--proxy-serverيقبل كل من HTTP و SOCKS5 كعنوان في شكلsocks5://host:port. بدون بيانات اعتماد - انظر الفخ أعلاه.--proxy-bypass- قائمة بالنطاقات مفصولة بفواصل، التي تمر دون بروكسي. ليست خيارًا زخرفيًا: إذا كان لدى الوكيل خدمات داخلية أو API محلي، فإن تمريرها عبر قناة سكنية يعني زيادة الترافيك بتكلفة لكل غيغابايت.--isolatedيحتفظ بالملف الشخصي في الذاكرة ولا يكتب على القرص. مفيد عندما يجب أن تبدأ كل مهمة من صفحة نظيفة. الجانب السلبي - الكوكيز لا تبقى بعد إعادة التشغيل، وكل جلسة لموقع تبدو زائرًا جديدًا.--user-data-dir- على العكس، ملف شخصي دائم. للسيناريوهات التي تتطلب تسجيل دخول، استخدمه بدلاً من العزل، وتأكد من تثبيت IP (انظر القسم عن sticky أدناه).--storage-stateيسمح بتمرير الكوكيز المحفوظة و localStorage في جلسة معزولة - تسوية بين الخيارين السابقين.--allowed-originsو--blocked-originsتحددان إلى أين يمكن للوكيل الذهاب. توفير غير مقدر: الوكيل، الذي ينجذب إلى التحليلات والنطاقات الإعلانية، يمكن أن يضاعف استهلاك الترافيك بسهولة.--device(على سبيل المثال،"iPhone 15") و--user-agentتغيران كيف يظهر الوكيل كمتصفح. تأكد من توافقها مع نوع البروكسي: User-Agent المحمول فوق IP مركز البيانات - هذا تناقض تقرأه نظام مكافحة البوتات على الفور.
بشكل منفصل عن --cdp-endpoint: يربط MCP بمتصفح تم تشغيله بالفعل. عندها يتم إعداد البروكسي ليس بواسطة أعلام MCP، بل عند بدء ذلك المتصفح - سبب نموذجي لسبب "تم تسجيل البروكسي، لكن IP هو نفسه".
browser-use: بروكسي عبر ProxySettings
إذا تم تجميع الوكيل على browser-use، فإن التكوين يذهب إلى كائن الإعدادات، وهنا يمكن تمرير اسم المستخدم وكلمة المرور - يتم تمريرها عبر API، وليس عبر سطر الأوامر:
from browser_use import Browser, ProxySettings
proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1')
browser = Browser(proxy=proxy)
حقل server إلزامي، والبقية اختيارية. نفس المبدأ ينطبق أيضًا على Playwright النقي: يتم تعيين البروكسي إما عالميًا عند بدء تشغيل المتصفح، أو بشكل منفصل لكل سياق عبر browser.newContext({ proxy: { server: ... } }). الثاني هو المفتاح للوكلاء المتوازيين: يحصل كل سياق على عنوان الخروج الخاص به، ولا تتشارك عشر مهام عنوان IP واحد.
المتصفحات السحابية: بروكسي على مستوى الجلسة
في Browserbase وخدمات مماثلة، يعيش المتصفح في سحابة شخص آخر، لذلك أعلام التشغيل غير متاحة لك - يتم تسجيل البروكسي في معلمات الجلسة، عادة كسلسلة من النوع http://اسم المستخدم:كلمة المرور@البوابة:المنفذ في متغير البيئة لخادم MCP. لا تعيق قيود Chromium هنا: يقوم مزود السحابة بتحليل السلسلة وإعداد المتصفح من الداخل.
تفصيل عملي: لدى المتصفحات السحابية مجموعة بروكسي خاصة بها، وهي مشتركة بين جميع العملاء. إذا كانت المهمة حساسة لسمعة العنوان - الدخول إلى الحساب، العمل مع منصة حيث كنت قد ظهرت بالفعل - فإن قناتك الخاصة أكثر توقعًا من العامة.
التدوير أو التثبيت: اختر حسب نوع المهمة
خطأ المبتدئين - تشغيل التدوير في كل طلب والتعجب من سبب تسجيل خروج الوكيل. لدى سيناريوهات الوكيل وضعان، وهما غير قابلين للتبادل:
- التدوير في كل طلب (في ProxyCove، هذا المنفذ 824) - للاستطلاع: تجاوز مائة بطاقة منتج، جمع النتائج، تحقق من الأسعار في مناطق مختلفة. كل طلب يخرج من عنوان جديد، من الصعب ربطها معًا.
- جلسة مثبتة (المنافذ 10000+، فترة التغيير من 1 إلى 120 دقيقة) - لكل ما يتكون من خطوات: تسجيل الدخول، سلة التسوق، نموذج متعدد الصفحات، حوار طويل مع الواجهة. إذا تغير IP في منتصف السلسلة، سيطلب الموقع في أفضل الأحوال إعادة تسجيل الدخول، وفي أسوأ الأحوال - سيضع علامة على الجلسة كاشتباه.
يعمل الوكيل تقريبًا دائمًا في الوضع الثاني: فهو بطبيعته يقوم بتسلسل من الخطوات، وليس مجرد طلقة واحدة. تم تحليل تفاصيل اختيار الفترة والأخطاء الشائعة في الدليل حول متى تحتاج إلى جلسات ثابتة وكيفية إعدادها.
خمسة فخاخ تحت الماء
- SOCKS5 مع المصادقة في Chromium. بناء الجملة
socks5://موجود في Playwright، لكن الربط بين "SOCKS5 واسم المستخدم وكلمة المرور" في المتصفحات المبنية على Chromium تاريخيًا مشكلة - الطلب المقابل في متتبع Playwright مفتوح منذ نوفمبر 2021. إذا كان هناك خيار، اختر قناة HTTP(S) للوكلاء، فهي أكثر توقعًا. - تسرب DNS وWebRTC. يمر الترافيك عبر البروكسي، بينما يتم حل الأسماء مباشرة أو WebRTC يعطي العنوان الحقيقي - وتفقد كل التمويه معناه. يجب التحقق من ذلك قبل، وليس بعد، تشغيل الوكيل: كيفية إخفاء WebRTC عند العمل عبر البروكسي.
- عدم التزامن بين الجغرافيا واللغة المحلية. IP في ألمانيا، المنطقة الزمنية للجهاز موسكو، لغة الواجهة إنجليزية - مجموعة تبدو تلقائيًا كأتمتة. في Playwright، يتم تعيين اللغة المحلية والمنطقة الزمنية بواسطة معلمات السياق، اجعلها تتوافق مع بلد البروكسي.
- الترافيك الذي لم تطلبه. يفتح الوكيل الصفحة بالكامل، مع الصور والخطوط والبرامج الإعلانية. على قناة سكنية مع الدفع لكل غيغابايت، هذه تكلفة ملحوظة - قم بحظر النطاقات الزائدة، وحيثما أمكن، قم بإيقاف تحميل الوسائط.
- البروكسي مسجل في مكان غير حيث يبدأ المتصفح. عند العمل عبر
--cdp-endpoint، عبر غلاف Docker أو عبر خدمة سحابية، لا تؤثر أعلام MCP على الاتصال الفعلي. أول شيء يجب القيام به بعد الإعداد هو جعل الوكيل يفتح أي خدمة للتحقق من IP والتأكد من أن العنوان والدولة هما نفسهما.
أي نوع من البروكسي يجب أن تأخذ للوكيل
القاعدة بسيطة: كلما كانت المهمة أقرب إلى المستخدم الحقيقي، يجب أن يكون العنوان "أكثر إنسانية".
- بروكسي سكنية - قاعدة للوكالات. هذه عناوين لمزودي الخدمة المنزلية، ولذا يبدو الوكيل للمنصة زائرًا عاديًا. مطلوبة في كل مكان يوجد فيه Cloudflare، والأسعار الإقليمية وأي تلميح لمكافحة البوت.
- بروكسي موبايل - المدفعية الثقيلة لوسائل التواصل الاجتماعي والمنصات التي تتعامل مع الحسابات بشكل خاص. خلف عنوان موبايل واحد يجلس الآلاف من المشتركين الحقيقيين، لذا فإن حظره بالكامل يكلف المنصة الكثير.
- بروكسي مركز البيانات - لواجهات برمجة التطبيقات الداخلية، منصات الاختبار والمصادر المفتوحة بدون حماية. سريع ورخيص، لكن على المواقع المحمية، سيواجه الوكيل تحديًا تقريبًا على الفور.
تفصيل مفيد لسيناريوهات الوكيل: تغيير البروتوكول في ProxyCove يتم عن طريق استبدال البادئة في سلسلة الاتصال - HTTP وHTTPS وSOCKS5 متاحة على نفس البروكسي، ولا حاجة لإعادة تكوين البروكسي نفسه. هناك أكثر من 195 دولة في المجموعة، لذا فإن "إظهار النتائج المحلية للوكيل" يتم حله باختيار الدولة عند الشراء.
الاستنتاج
توصيل البروكسي بالوكيل الذكي ليس سطرًا واحدًا، بل ثلاث حلول متتالية: كيفية المصادقة (للوكيل headless، غالبًا ما تكون القائمة البيضاء لـ IP، وليس كلمة المرور)، أين تعيين البروكسي (أعلام MCP، كائن الإعدادات أو معلمات الجلسة السحابية - لكن بالتأكيد حيث يبدأ المتصفح فعليًا) وفي أي وضع تعمل (للسيناريوهات متعددة الخطوات - عنوان مثبت، وليس تدوير في كل طلب). بالإضافة إلى التحقق الإلزامي من تسرب DNS وWebRTC قبل الإطلاق الفعلي.
قم بذلك مرة واحدة بعناية - وسيتوقف الوكيل عن إهدار الرموز في المحادثات مع الكابتشا. بروكسي سكنية من ProxyCove تتصل بـ Playwright MCP وbrowser-use في بضع دقائق، والدفع حسب الترافيك، وقائمة بيضاء لـ IP لوضع headless يتم تفعيلها في لوحة التحكم.