عامل هوش مصنوعی که به طور خودکار در وبسایتها گشتزنی میکند — Claude با Playwright MCP، استفاده از مرورگر، 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 (whitelist). بهترین گزینه برای عاملها. شما آدرس ماشینی که عامل در آن اجرا میشود را به لیست سفید در پنل ارائهدهنده اضافه میکنید — و سپس بدون نام کاربری و رمز عبور، با خط ساده
host:portمتصل میشوید. پرچم--proxy-serverبه طور صحیح کار میکند، headless دیگر چیزی نمیپرسد. ProxyCove از هر دو روش — نام کاربری:رمز عبور و IP-whitelist پشتیبانی میکند، به طوری که میتوان برای عامل یک whitelist ایجاد کرد و برای وظایف دستی رمز عبور را نگه داشت. - انتقال اعتبارنامهها در سطح API، نه پرچم. Playwright، Puppeteer و browser-use میتوانند
usernameوpasswordرا به عنوان فیلدهای جداگانه دریافت کنند — این مکانیزم همانند پرچم خط فرمان نیست و کار میکند. این گزینه زمانی مناسب است که خودتان کد عامل را مینویسید. - رله محلی. شما پروکسی بدون رمز عبور را راهاندازی میکنید که درخواستها را به سمت upstream با رمز عبور فوروارد میکند و به عامل آدرس محلی را میدهید. این گزینه برای مواقعی است که لیست سفید در دسترس نیست: به عنوان مثال، IP ماشین متغیر است.
Playwright MCP: پیکربندی که واقعاً کار میکند
Playwright MCP از مایکروسافت — امروز استاندارد de facto برای عاملهایی است که به یک مرورگر واقعی نیاز دارند. پروکسی با آرگومانهای سرور مستقیماً در پیکربندی مشتری 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 در وسط زنجیره تغییر کند، وبسایت در بهترین حالت از شما میخواهد دوباره وارد شوید، و در بدترین حالت — جلسه را به عنوان مشکوک علامتگذاری میکند.
عامل تقریباً همیشه در حالت دوم کار میکند: او به طور تعریف شده یک دنباله از مراحل را انجام میدهد، نه یک شلیک واحد. جزئیات انتخاب فاصله و اشتباهات معمول در راهنمایی که چه زمانی به sticky-sessions نیاز دارید و چگونه آنها را تنظیم کنید بررسی شده است.
پنج مشکل پنهان
- SOCKS5 با احراز هویت در Chromium. سینتکس
socks5://در Playwright وجود دارد، اما ترکیب «SOCKS5 به علاوه نام کاربری و رمز عبور» در مرورگرهای مبتنی بر Chromium به طور تاریخی مشکلساز بوده است — درخواست مربوطه در پیگیری Playwright از نوامبر 2021 باز است. اگر انتخاب وجود داشته باشد، برای عاملها از کانال HTTP(S) استفاده کنید، زیرا پیشبینیپذیرتر است. - نشت DNS و WebRTC. ترافیک از طریق پروکسی میرود، اما نامها به طور مستقیم حل میشوند یا WebRTC آدرس واقعی را ارائه میدهد — و تمام پنهانسازی بیمعنا میشود. باید این را قبل از راهاندازی عامل بررسی کنید، نه بعد از آن: چگونه WebRTC را هنگام کار از طریق پروکسی پنهان کنیم.
- عدم همگامسازی جغرافیایی و محلی. IP در آلمان، منطقه زمانی ماشین مسکو، زبان رابط انگلیسی — مجموعهای که به خودی خود به عنوان اتوماسیون به نظر میرسد. در Playwright، محلی و منطقه زمانی با پارامترهای زمینه تعیین میشوند، آنها را با کشور پروکسی هماهنگ کنید.
- ترافیک غیرمطلوب. عامل صفحه را به طور کامل باز میکند، همراه با تصاویر، فونتها و اسکریپتهای تبلیغاتی. در کانال مقیم با پرداخت به ازای هر گیگابایت، این یک هزینه قابل توجه است — دامنههای اضافی را مسدود کنید و در جایی که ممکن است، بارگذاری رسانه را غیرفعال کنید.
- پروکسی در جایی که مرورگر راهاندازی میشود، تنظیم نشده است. هنگام کار از طریق
--cdp-endpoint، از طریق پوشش داکر یا از طریق خدمات ابری، پرچمهای MCP بر روی اتصال واقعی تأثیری ندارند. اولین کاری که باید بعد از تنظیم انجام دهید — مجبور کردن عامل به باز کردن هر سرویس بررسی IP و اطمینان از اینکه آدرس و کشور همان هستند.
چه نوع پروکسی برای عامل بگیریم
قاعده ساده است: هرچه وظیفه به کاربر زنده نزدیکتر باشد، آدرس باید «انسانیتر» باشد.
- پروکسیهای مقیم — پایه برای عاملها. اینها آدرسهای ارائهدهندگان خانگی هستند و برای وبسایت، عامل به عنوان یک بازدیدکننده معمولی به نظر میرسد. در هر جایی که Cloudflare، قیمتهای منطقهای و هر نشانهای از ضد ربات وجود دارد، نیاز است.
- پروکسیهای موبایل — توپخانه سنگین برای شبکههای اجتماعی و پلتفرمهایی که به حسابها به ویژه حساس هستند. پشت یک آدرس موبایل هزاران مشترک واقعی نشستهاند، بنابراین مسدود کردن آن به طور کامل برای پلتفرم هزینهبر است.
- پروکسیهای دیتاسنتر — برای APIهای داخلی، ایستگاههای آزمایشی و منابع باز بدون حفاظت. سریع و ارزان، اما در وبسایتهای محافظت شده، عامل تقریباً بلافاصله با چالش مواجه میشود.
جزئیات مفید برای سناریوهای عامل: تغییر پروتکل در ProxyCove با تغییر پیشوند در رشته اتصال انجام میشود — HTTP، HTTPS و SOCKS5 در همان پروکسی در دسترس هستند، نیازی به تنظیم مجدد پروکسی نیست. کشورها در مجموعه بیش از 195 هستند، بنابراین «نمایش نتایج محلی به عامل» با انتخاب کشور در زمان خرید حل میشود.
نتیجهگیری
اتصال پروکسی به عامل هوش مصنوعی — این یک خط نیست، بلکه سه راهحل متوالی است: چگونه احراز هویت کنید (برای عامل headless تقریباً همیشه لیست سفید IP، نه رمز عبور)، کجا پروکسی را تنظیم کنید (پرچمهای MCP، شیء تنظیمات یا پارامترهای جلسه ابری — اما حتماً در جایی که واقعاً مرورگر راهاندازی میشود) و در چه وضعیتی کار کنید (برای سناریوهای چند مرحلهای — آدرس ثابت، نه چرخش برای هر درخواست). به علاوه، بررسی الزامی برای نشتهای DNS و WebRTC قبل از راهاندازی عملی.
این را یک بار به دقت انجام دهید — و عامل دیگر توکنها را برای گفتگو با کپچا هدر نخواهد داد. پروکسیهای مقیم ProxyCove به سرعت به Playwright MCP و browser-use متصل میشوند و پرداخت بر اساس ترافیک است، IP-whitelist برای حالت headless در پنل فعال میشود.
```