AI-एजेंट्स के लिए प्रॉक्सी: Playwright MCP और browser-use 2026

```html

AI-एजेंट, जो खुद वेबसाइटों पर जाता है — Claude के साथ Playwright MCP, browser-use, क्लाउड Browserbase — उसी दीवार से टकराता है जो सामान्य पार्सर के लिए होती है: एक पते से दर्जनों अनुरोध, और फिर पृष्ठ के बजाय Cloudflare का चैलेंज आता है। अंतर यह है कि एजेंट नाराज नहीं होता और बस लूप में चला जाता है, "जिस बटन को दबाना है वह नहीं है" प्रयासों में टोकन बर्बाद करता है।

इसका इलाज प्रॉक्सी है। लेकिन एजेंट से प्रॉक्सी को कनेक्ट करना अप्रत्याशित रूप से स्पष्ट नहीं होता: इंटरनेट पर आधी निर्देशाएं ऐसे सिंटैक्स की पेशकश करती हैं, जिसे Chromium चुपचाप अनदेखा करता है। नीचे 2026 के तीन सबसे सामान्य स्टैक्स के लिए कार्यशील कॉन्फ़िग्स और उन जालों का विश्लेषण है, जिन पर सभी ठोकर खाते हैं।

किसे इसकी आवश्यकता है

उन लोगों के लिए गाइड, जिन्होंने पहले ही एजेंट को चालू किया है और एक लक्षण प्राप्त किया है:

एजेंट 10–20 चरणों को पूरा करता है, और फिर हर अगला कदम कैप्चा या "Verify you are human" पृष्ठ लौटाता है;
एजेंट वही सामग्री नहीं देखता जो आप: कीमतें, परिणाम और उत्पाद की उपलब्धता साइट आपके सर्वर के IP के तहत दिखाती है, न कि आवश्यक देश के तहत;
एजेंट क्लाउड में चल रहा है (VPS, GitHub Actions, कंटेनर), और होस्टर का डेटा सेंटर पता पहले से ही बॉट के रूप में चिह्नित है;
आपने लॉगिन और पासवर्ड के साथ प्रॉक्सी को निर्दिष्ट किया है, और ब्राउज़र इस तरह से शुरू होता है जैसे प्रॉक्सी बिल्कुल नहीं है।

यदि आप अभी भी "एजेंटों को क्यों ब्लॉक किया जाता है" के चरण पर हैं — पहले उस विश्लेषण को पढ़ें कि कैसे एंटी-बॉट सिस्टम एजेंट ब्राउज़र को मानव से अलग करते हैं: वहां डिटेक्शन संकेतों के बारे में है, और यहां — कनेक्शन की शुद्ध प्रैक्टिस।

जाल संख्या 1: Chromium प्रॉक्सी स्ट्रिंग में लॉगिन और पासवर्ड स्वीकार नहीं करता

सबसे सामान्य गलती, और यह लोगों को घंटों की डिबगिंग में डाल देती है। प्रदाता से क्लासिक स्ट्रिंग का रूप — user:pass@host:port। आप इसे ब्राउज़र के लॉन्च फ्लैग में डालते हैं:

--proxy-server="http://user:[email protected]:8080"

और कुछ भी काम नहीं करता। Chromium फ्लैग --proxy-server के भीतर क्रेडेंशियल्स को पास करने का समर्थन नहीं करता: कंसोल में एक असमर्थित प्रॉक्सी की त्रुटि आती है, और ट्रैफिक बाईपास हो जाता है। यदि क्रेडेंशियल्स को हटा दिया जाए और केवल host:port रखा जाए, तो ब्राउज़र सामान्य मोड में लॉगिन और पासवर्ड के अनुरोध के साथ सिस्टम विंडो दिखाएगा — और यहीं सब रुक जाएगा, क्योंकि हेडलेस मोड में कोई विंडो नहीं होती और उसमें क्लिक करने के लिए कोई नहीं होता।

इससे तीन कार्यशील रास्ते निकलते हैं, और चयन सावधानी से करना चाहिए:

IP द्वारा प्रमाणीकरण (whitelist). एजेंटों के लिए सबसे साफ विकल्प। आप उस मशीन का पता, जहां एजेंट चल रहा है, प्रदाता के डैशबोर्ड में व्हाइटलिस्ट में जोड़ते हैं — और फिर बिना लॉगिन और पासवर्ड के, सरल स्ट्रिंग host:port के साथ कनेक्ट करते हैं। फ्लैग --proxy-server जैसा कि सोचा गया था काम करना शुरू करता है, हेडलेस और कुछ नहीं पूछता। ProxyCove दोनों विधियों का समर्थन करता है — और लॉगिन:पासवर्ड, और IP-whitelist, और दोनों को एक साथ, इसलिए एजेंट के लिए व्हाइटलिस्ट बनाई जा सकती है, और मैनुअल कार्यों के लिए पासवर्ड रखा जा सकता है।
API स्तर पर क्रेडेंशियल्स पास करना, न कि फ्लैग पर। Playwright, Puppeteer और browser-use username और password को अलग-अलग फ़ील्ड के रूप में स्वीकार करते हैं — यह वही तंत्र नहीं है जो कमांड लाइन फ्लैग है, और यह काम करता है। यह तब उपयुक्त है जब आप स्वयं एजेंट का कोड लिख रहे हैं।
स्थानीय रिले। आप बिना पासवर्ड के प्रॉक्सी सेट करते हैं, जो पासवर्ड के साथ अपस्ट्रीम पर अनुरोधों को फॉरवर्ड करता है, और एजेंट को स्थानीय पता निर्दिष्ट करते हैं। यह उन मामलों के लिए विकल्प है जब व्हाइटलिस्ट उपलब्ध नहीं है: उदाहरण के लिए, मशीन का IP बदलता रहता है।

Playwright MCP: कॉन्फ़िग, जो वास्तव में काम करता है

Microsoft का Playwright MCP — आज एजेंटों के लिए वास्तविक ब्राउज़र की आवश्यकता है। प्रॉक्सी को 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 को स्थिर करना सुनिश्चित करें (नीचे स्थिर अनुभाग को देखें)।
--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 श्रृंखला के बीच में बदलता है, तो साइट सबसे अच्छे मामले में पुनः प्रमाणीकरण के लिए कहेगी, सबसे खराब स्थिति में — सत्र को संदिग्ध के रूप में चिह्नित करेगी।

एजेंट लगभग हमेशा दूसरे मोड में काम करता है: वह परिभाषा के अनुसार चरणों की एक श्रृंखला बनाता है, न कि एक ही शॉट। अंतराल के चयन के विवरण और सामान्य गलतियों को उस गाइड में विश्लेषित किया गया है, जब स्थिर सत्र आवश्यक होते हैं और उन्हें कैसे सेट करना है.

पाँच जलजमाव

Chromium में प्रमाणीकरण के साथ SOCKS5. Playwright में socks5:// का सिंटैक्स है, लेकिन "SOCKS5 और लॉगिन और पासवर्ड" का संयोजन Chromium ब्राउज़रों में ऐतिहासिक रूप से समस्याग्रस्त है — Playwright ट्रैकर में संबंधित अनुरोध नवंबर 2021 से खुला है। यदि विकल्प है, तो एजेंटों के लिए HTTP(S) चैनल लें, यह अधिक पूर्वानुमानित है।
DNS और WebRTC का रिसाव. ट्रैफिक प्रॉक्सी के माध्यम से जाता है, और नाम सीधे या WebRTC वास्तविक पते को देते हैं — और पूरी छिपाने की प्रक्रिया का कोई अर्थ नहीं रह जाता। इसे एजेंट को लॉन्च करने से पहले जांचना चाहिए: प्रॉक्सी के माध्यम से काम करते समय WebRTC को कैसे बंद करें.
भौगोलिक और स्थानीयता का असंगति. जर्मनी में IP, मशीन का समय क्षेत्र मास्को का, इंटरफ़ेस की भाषा अंग्रेजी — यह सेट अपने आप में स्वचालन की तरह दिखता है। Playwright में स्थानीयता और समय क्षेत्र संदर्भ के पैरामीटर द्वारा निर्धारित होते हैं, उन्हें प्रॉक्सी के देश के साथ मेल करें।
आपके द्वारा आदेशित ट्रैफिक. एजेंट पूरी पृष्ठ को खोलता है, चित्रों, फ़ॉन्टों और विज्ञापन स्क्रिप्टों के साथ। निवासी चैनल पर प्रति गीगाबाइट भुगतान करने पर यह एक महत्वपूर्ण खर्च है — अनावश्यक डोमेनों को ब्लॉक करें और जहां संभव हो, मीडिया लोडिंग बंद करें।
प्रॉक्सी वहां निर्दिष्ट नहीं है, जहां ब्राउज़र शुरू होता है. --cdp-endpoint, डॉकर रैपर के माध्यम से या क्लाउड सेवा के माध्यम से काम करते समय, MCP के फ्लैग वास्तविक कनेक्शन पर प्रभाव नहीं डालते। सेटिंग्स के बाद पहला काम यह करना चाहिए कि एजेंट को किसी भी IP जांच सेवा को खोलने के लिए मजबूर करें और सुनिश्चित करें कि पता और देश वही हैं।

एजेंट के लिए किस प्रकार की प्रॉक्सी लेनी चाहिए

नियम सरल है: जितना अधिक कार्य जीवित उपयोगकर्ता के करीब होता है, उतना ही "मानव" पता होना चाहिए।

निवासी प्रॉक्सी — एजेंटों के लिए आधार। ये घरेलू प्रदाताओं के पते हैं, और साइट के लिए एजेंट एक सामान्य आगंतुक के रूप में दिखता है। जहां भी Cloudflare, क्षेत्रीय कीमतें और किसी भी एंटी-बॉट का संकेत होता है, वहां आवश्यक हैं।
मोबाइल प्रॉक्सी — सोशल मीडिया और प्लेटफार्मों के लिए भारी तोपें, जहां खातों के प्रति विशेष रूप से संवेदनशील होते हैं। एक मोबाइल पते के पीछे हजारों वास्तविक ग्राहक होते हैं, इसलिए इसे पूरी तरह से बैन करना प्लेटफॉर्म के लिए महंगा होता है।
डेटा सेंटर प्रॉक्सी — आंतरिक API, परीक्षण स्टैंड और बिना सुरक्षा के ओपन सोर्स के लिए। तेज और सस्ते, लेकिन सुरक्षित साइटों पर एजेंट लगभग तुरंत चैलेंज में टकरा जाता है।

एजेंट परिदृश्यों के लिए एक उपयोगी विवरण: ProxyCove पर प्रोटोकॉल को बदलना कनेक्शन स्ट्रिंग में प्रीफिक्स को बदलने से किया जाता है — HTTP, HTTPS और SOCKS5 एक ही प्रॉक्सी पर उपलब्ध हैं, प्रॉक्सी को फिर से कॉन्फ़िगर करने की आवश्यकता नहीं है। पूल में 195 से अधिक देश हैं, इसलिए "एजेंट को स्थानीय परिणाम दिखाना" खरीदते समय देश के चयन से हल किया जाता है।

निष्कर्ष

AI-एजेंट से प्रॉक्सी को कनेक्ट करना एक पंक्ति नहीं है, बल्कि तीन समाधान हैं: कैसे प्रमाणीकरण करना है (हेडलेस एजेंट के लिए लगभग हमेशा IP का व्हाइटलिस्ट, न कि पासवर्ड), कहां प्रॉक्सी निर्दिष्ट करना है (MCP के फ्लैग, सेटिंग्स ऑब्जेक्ट या क्लाउड सत्र के पैरामीटर — लेकिन निश्चित रूप से वहां, जहां वास्तव में ब्राउज़र शुरू होता है) और किस मोड में काम करना है (कई चरणों वाले परिदृश्यों के लिए — स्थिर पता, न कि प्रत्येक अनुरोध पर रोटेशन)। इसके अलावा, युद्ध संचालन से पहले DNS और WebRTC के रिसाव की अनिवार्य जांच।

इसे एक बार सावधानी से करें — और एजेंट कैप्चा के साथ बातचीत पर टोकन बर्बाद करना बंद कर देगा। ProxyCove के निवासीय प्रॉक्सी Playwright MCP और browser-use के साथ कुछ मिनटों में कनेक्ट होते हैं, ट्रैफिक के लिए भुगतान, हेडलेस मोड के लिए IP-whitelist डैशबोर्ड में सक्षम होता है।