WSL2 + Windows + रिमोट Chrome CDP समस्या निवारण

सामान्य स्प्लिट-होस्ट सेटअप में, OpenClaw Gateway WSL2 के अंदर चलता है, Chrome Windows पर चलता है, और ब्राउज़र नियंत्रण को WSL2/Windows सीमा पार करनी होती है। कई स्वतंत्र समस्याएँ एक साथ सामने आ सकती हैं (देखें इश्यू #39369): CDP ट्रांसपोर्ट, Control UI ओरिजिन सुरक्षा, और टोकन/पेयरिंग में से प्रत्येक स्वतंत्र रूप से विफल हो सकता है, जबकि उनसे एक जैसे दिखने वाले त्रुटि संदेश उत्पन्न होते हैं। यह अनुमान लगाने के बजाय कि कौन-सा भाग खराब है, नीचे दी गई परतों पर क्रम से काम करें।

पहले सही ब्राउज़र मोड चुनें

विकल्प 1: WSL2 से Windows तक रॉ रिमोट CDP

WSL2 से Windows Chrome CDP एंडपॉइंट की ओर इंगित करने वाली रिमोट ब्राउज़र प्रोफ़ाइल का उपयोग करें। इसे तब चुनें जब Gateway WSL2 के अंदर रहता है, Chrome Windows पर चलता है, और ब्राउज़र नियंत्रण को WSL2/Windows सीमा पार करनी होती है।

विकल्प 2: होस्ट-लोकल Chrome MCP

existing-session ड्राइवर (user प्रोफ़ाइल) का उपयोग केवल तब करें जब Gateway Chrome वाले होस्ट पर ही चलता हो, आपको स्थानीय साइन-इन की गई ब्राउज़र स्थिति चाहिए, आपको क्रॉस-होस्ट ब्राउज़र ट्रांसपोर्ट की आवश्यकता न हो, और आपको responsebody, PDF एक्सपोर्ट, डाउनलोड इंटरसेप्शन, या बैच कार्रवाइयों की आवश्यकता न हो (Chrome MCP प्रोफ़ाइल इनका समर्थन नहीं करतीं)।

WSL2 Gateway + Windows Chrome के लिए, रॉ रिमोट CDP का उपयोग करें। Chrome MCP होस्ट-लोकल है, WSL2-से-Windows ब्रिज नहीं।

कार्यशील आर्किटेक्चर

• WSL2, Gateway को 127.0.0.1:18789 पर चलाता है
• Windows सामान्य ब्राउज़र में http://127.0.0.1:18789/ पर Control UI खोलता है
• Windows Chrome, पोर्ट 9222 पर CDP एंडपॉइंट उपलब्ध कराता है
• WSL2 उस Windows CDP एंडपॉइंट तक पहुँच सकता है
• OpenClaw किसी ब्राउज़र प्रोफ़ाइल को WSL2 से पहुँच योग्य पते की ओर इंगित करता है

Control UI के लिए महत्वपूर्ण नियम

जब UI को Windows से खोला जाए, तो किसी सुविचारित HTTPS सेटअप के अभाव में Windows localhost का उपयोग करें:

http://127.0.0.1:18789/

डिफ़ॉल्ट रूप से LAN IP का उपयोग न करें। LAN या tailnet पते पर सादा HTTP, CDP से असंबंधित असुरक्षित-ओरिजिन/डिवाइस-प्रमाणीकरण व्यवहार ट्रिगर कर सकता है। देखें Control UI।

परत-दर-परत सत्यापन करें

ऊपर से नीचे की ओर काम करें; बीच की परतें न छोड़ें। एक परत ठीक करने के बाद भी नीचे की किसी दूसरी परत की अलग त्रुटि दिखाई दे सकती है।

परत 1: सत्यापित करें कि Chrome Windows पर CDP उपलब्ध करा रहा है

chrome.exe --remote-debugging-port=9222 --user-data-dir="$env:LOCALAPPDATA\OpenClaw\ChromeCDP"

Chrome 136 और उसके बाद के संस्करण, डिफ़ॉल्ट Chrome डेटा डायरेक्टरी के लिए रिमोट-डीबगिंग कमांड-लाइन स्विच को अनदेखा करते हैं। ऊपर दिखाए अनुसार एक अलग, गैर-डिफ़ॉल्ट डेटा डायरेक्टरी का उपयोग करें। Chrome का रिमोट-डीबगिंग सुरक्षा परिवर्तन देखें। इससे सामान्य साइन-इन की गई Chrome प्रोफ़ाइल रिमोट रूप से नियंत्रित करने योग्य नहीं बनती।

Windows से पहले स्वयं Chrome को सत्यापित करें:

curl.exe http://127.0.0.1:9222/json/versioncurl.exe http://127.0.0.1:9222/json/list

यदि यह विफल होता है, तो नीचे दिए गए Windows लिसनर का निदान करें। अभी OpenClaw समस्या नहीं है।

portproxy बदलने से पहले IPv4 और IPv6 का निदान करें

Chromium पहले रिमोट डीबगिंग को 127.0.0.1 से बाइंड करने का प्रयास करता है और केवल IPv4 बाइंड विफल होने पर [::1] पर फ़ॉलबैक करता है। 127.0.0.1:9222 पर सुनने वाला स्थायी v4tov4 नियम, Chrome शुरू होने से पहले उस एंडपॉइंट को घेर सकता है। इसके बाद Chrome [::1]:9222 पर फ़ॉलबैक करता है, जबकि पुराना नियम IPv4 ट्रैफ़िक को वापस अपने ही लिसनर पर फ़ॉरवर्ड करता है और खाली उत्तर लौटाता है।

Chrome संस्करण से अनुमान लगाने के बजाय Windows से वास्तविक लिसनर और प्रॉक्सी नियम जाँचें:

netstat -ano | findstr :9222netsh interface portproxy show allcurl.exe http://127.0.0.1:9222/json/versioncurl.exe http://[::1]:9222/json/version

netstat से प्रत्येक PID के लिए tasklist /fi "PID eq <PID>" का उपयोग करें।

• यदि chrome.exe, 127.0.0.1 पर उत्तर देता है, तो उस portproxy नियम को हटाएँ जो 127.0.0.1:9222 पर भी सुनता है। केवल WSL2 से पहुँच योग्य Windows अडैप्टर पते को 127.0.0.1 पर फ़ॉरवर्ड करें।

• यदि chrome.exe केवल [::1] पर उत्तर देता है, तो किसी अप्रयुक्त IPv4 पते पर फ़ॉरवर्ड करने के बजाय v4tov6 के साथ WSL2 से पहुँच योग्य लिसनर को ::1 की ओर इंगित करें:

  netsh interface portproxy add v4tov6 listenaddress=WINDOWS_HOST_OR_IP listenport=9222 connectaddress=::1 connectport=9222

लिसनर को उस अडैप्टर पते से बाइंड करें जिसकी WSL2 को आवश्यकता है। CDP पोर्ट को 0.0.0.0, LAN पते, या tailnet पते पर उपलब्ध न कराएँ: CDP ब्राउज़र सत्र का नियंत्रण प्रदान करता है।

परत 2: सत्यापित करें कि WSL2 उस Windows एंडपॉइंट तक पहुँच सकता है

WSL2 से, उस सटीक पते का परीक्षण करें जिसका आप cdpUrl में उपयोग करने वाले हैं:

curl http://WINDOWS_HOST_OR_IP:9222/json/versioncurl http://WINDOWS_HOST_OR_IP:9222/json/list

सही परिणाम:

• /json/version, Browser / Protocol-Version मेटाडेटा वाला JSON लौटाता है
• /json/list, JSON लौटाता है (यदि कोई पृष्ठ खुला नहीं है, तो खाली ऐरे भी ठीक है)

यदि यह विफल होता है, तो Windows अभी पोर्ट को WSL2 के लिए उपलब्ध नहीं करा रहा है, पता WSL2 पक्ष के लिए गलत है, या फ़ायरवॉल/पोर्ट-फ़ॉरवर्डिंग/प्रॉक्सीइंग मौजूद नहीं है। OpenClaw कॉन्फ़िगरेशन को छूने से पहले इसे ठीक करें।

परत 3: सही ब्राउज़र प्रोफ़ाइल कॉन्फ़िगर करें

OpenClaw को WSL2 से पहुँच योग्य पते की ओर इंगित करें:

{  browser: {    enabled: true,    defaultProfile: "remote",    profiles: {      remote: {        cdpUrl: "http://WINDOWS_HOST_OR_IP:9222",        attachOnly: true,        color: "#00AA00",      },    },  },}

टिप्पणियाँ:

• WSL2 से पहुँच योग्य पते का उपयोग करें, न कि उसका जो केवल Windows पर काम करता है
• बाहरी रूप से प्रबंधित ब्राउज़र के लिए attachOnly: true बनाए रखें
• cdpUrl, http://, https://, ws://, या wss:// हो सकता है
• जब आप चाहते हैं कि OpenClaw /json/version खोजे, तब HTTP(S) का उपयोग करें
• WS(S) का उपयोग केवल तब करें जब ब्राउज़र प्रदाता आपको सीधा DevTools सॉकेट URL देता हो
• OpenClaw की सफलता की अपेक्षा करने से पहले उसी URL का curl से परीक्षण करें

परत 4: Control UI परत को अलग से सत्यापित करें

Windows से http://127.0.0.1:18789/ खोलें, फिर सत्यापित करें:

• पृष्ठ का ओरिजिन, gateway.controlUi.allowedOrigins की अपेक्षा से मेल खाता है
• टोकन प्रमाणीकरण या पेयरिंग सही ढंग से कॉन्फ़िगर है
• आप Control UI प्रमाणीकरण समस्या को ब्राउज़र समस्या मानकर डीबग नहीं कर रहे हैं

सहायक पृष्ठ: Control UI।

परत 5: एंड-टू-एंड ब्राउज़र नियंत्रण सत्यापित करें

WSL2 से:

openclaw browser --browser-profile remote open https://example.comopenclaw browser --browser-profile remote tabs

सही परिणाम:

• टैब Windows Chrome में खुलता है
• browser tabs लक्ष्य लौटाता है
• बाद की कार्रवाइयाँ (snapshot, screenshot, navigate) उसी प्रोफ़ाइल से काम करती हैं

सामान्य भ्रामक त्रुटियाँ

त्वरित ट्राइएज चेकलिस्ट

1. Windows: 127.0.0.1 या [::1] में से कौन /json/version पर उत्तर देता है, और क्या वह लिसनर chrome.exe का है?
2. WSL2: क्या curl http://WINDOWS_HOST_OR_IP:9222/json/version काम करता है?
3. OpenClaw कॉन्फ़िगरेशन: क्या browser.profiles.<name>.cdpUrl उसी सटीक WSL2-से-पहुँच योग्य पते का उपयोग करता है?
4. Control UI: क्या आप LAN IP के बजाय http://127.0.0.1:18789/ खोल रहे हैं?
5. क्या आप रॉ रिमोट CDP के बजाय WSL2 और Windows के आर-पार existing-session का उपयोग करने का प्रयास कर रहे हैं?

पहले Windows Chrome एंडपॉइंट को स्थानीय रूप से सत्यापित करें, फिर उसी एंडपॉइंट को WSL2 से सत्यापित करें, और उसके बाद ही OpenClaw कॉन्फ़िगरेशन या Control UI प्रमाणीकरण डीबग करें।

संबंधित

• ब्राउज़र
• ब्राउज़र लॉगिन
• ब्राउज़र Linux समस्या निवारण