Tools
استكشاف أخطاء WSL2 وWindows وChrome CDP البعيد وإصلاحها
في إعداد المضيفين المنفصلين الشائع، يعمل OpenClaw Gateway داخل WSL2، ويعمل Chrome على Windows، ويجب أن يعبر التحكم في المتصفح حدود WSL2/Windows. قد تظهر عدة مشكلات مستقلة في الوقت نفسه (راجع المشكلة رقم 39369): فقد يفشل كل من نقل CDP وأمان أصل Control UI والرمز المميز/الاقتران بشكل مستقل، مع إنتاج أخطاء متشابهة ظاهريًا. افحص الطبقات أدناه بالترتيب بدلًا من تخمين أيّها معطّل.
اختر وضع المتصفح الصحيح أولًا
الخيار 1: اتصال CDP خام عن بُعد من WSL2 إلى Windows
استخدم ملف تعريف لمتصفح بعيد يشير من WSL2 إلى نقطة نهاية CDP في Chrome على Windows. اختر هذا عندما يبقى Gateway داخل WSL2، ويعمل Chrome على Windows، ويحتاج التحكم في المتصفح إلى عبور حدود WSL2/Windows.
الخيار 2: Chrome MCP محلي على المضيف
استخدم برنامج التشغيل existing-session (ملف التعريف user) فقط عندما يعمل Gateway
على المضيف نفسه الذي يعمل عليه Chrome، وتريد حالة المتصفح المحلي المسجّل دخوله، ولا
تحتاج إلى نقل المتصفح عبر المضيفين، ولا تحتاج إلى responsebody،
أو تصدير PDF، أو اعتراض التنزيلات، أو الإجراءات الدفعية (ملفات تعريف Chrome MCP لا
تدعم هذه الميزات).
عند استخدام Gateway داخل WSL2 مع Chrome على Windows، استخدم CDP الخام عن بُعد. يعمل Chrome MCP محليًا على المضيف، وليس جسرًا من WSL2 إلى Windows.
البنية العاملة
- يشغّل WSL2 Gateway على
127.0.0.1:18789 - يفتح Windows Control UI في متصفح عادي على
http://127.0.0.1:18789/ - يعرض Chrome على Windows نقطة نهاية CDP على المنفذ
9222 - يستطيع WSL2 الوصول إلى نقطة نهاية CDP تلك على Windows
- يوجّه OpenClaw ملف تعريف للمتصفح إلى العنوان الذي يمكن الوصول إليه من WSL2
قاعدة بالغة الأهمية لـ Control UI
عند فتح واجهة المستخدم من Windows، استخدم المضيف المحلي لـ Windows ما لم يكن لديك إعداد HTTPS مقصود:
http://127.0.0.1:18789/لا تستخدم عنوان IP للشبكة المحلية افتراضيًا. قد يؤدي HTTP العادي على عنوان شبكة محلية أو عنوان tailnet إلى سلوك متعلق بأصل غير آمن/مصادقة الجهاز لا علاقة له بـ CDP نفسه. راجع Control UI.
التحقق حسب الطبقات
اعمل من الأعلى إلى الأسفل؛ ولا تتجاوز أي طبقة. قد يؤدي إصلاح طبقة واحدة إلى بقاء خطأ مختلف ظاهرًا من طبقة أدنى.
الطبقة 1: تحقق من أن Chrome يقدّم CDP على Windows
chrome.exe --remote-debugging-port=9222 --user-data-dir="$env:LOCALAPPDATA\OpenClaw\ChromeCDP"يتجاهل Chrome 136 والإصدارات الأحدث مفاتيح سطر أوامر تصحيح الأخطاء عن بُعد عند استخدام دليل بيانات Chrome الافتراضي. استخدم دليل بيانات منفصلًا وغير افتراضي كما هو موضح أعلاه. راجع تغيير أمان تصحيح الأخطاء عن بُعد في Chrome. لا يجعل هذا ملف تعريف Chrome العادي المسجّل دخوله قابلًا للتحكم عن بُعد.
تحقق أولًا من Chrome نفسه من Windows:
curl.exe http://127.0.0.1:9222/json/versioncurl.exe http://127.0.0.1:9222/json/listإذا فشل ذلك، فشخّص مستمعي Windows أدناه. لا تكمن المشكلة في OpenClaw حتى الآن.
شخّص IPv4 وIPv6 قبل تغيير portproxy
يحاول Chromium ربط تصحيح الأخطاء عن بُعد بـ 127.0.0.1 أولًا، ثم ينتقل إلى
[::1] فقط إذا فشل ربط IPv4. يمكن لقاعدة v4tov4 دائمة تستمع على
127.0.0.1:9222 أن تشغل نقطة النهاية تلك قبل بدء Chrome. عندئذٍ ينتقل Chrome
إلى [::1]:9222، بينما تعيد القاعدة القديمة توجيه حركة مرور IPv4 إلى
مستمعها نفسه وتعيد ردًا فارغًا.
تحقق من المستمعين الفعليين وقواعد الوكيل من Windows بدلًا من استنتاجها من إصدار Chrome:
netstat -ano | findstr :9222netsh interface portproxy show allcurl.exe http://127.0.0.1:9222/json/versioncurl.exe http://[::1]:9222/json/versionاستخدم tasklist /fi "PID eq <PID>" لكل PID من netstat.
-
إذا استجاب
chrome.exeعلى127.0.0.1، فأزل أي قاعدة portproxy تستمع أيضًا على127.0.0.1:9222. وجّه فقط عنوان محوّل Windows الذي يمكن لـ WSL2 الوصول إليه إلى127.0.0.1. -
إذا استجاب
chrome.exeعلى[::1]فقط، فوجّه المستمع الذي يمكن لـ WSL2 الوصول إليه نحو::1باستخدامv4tov6بدلًا من التوجيه إلى عنوان IPv4 غير مستخدم:powershell netsh interface portproxy add v4tov6 listenaddress=WINDOWS_HOST_OR_IP listenport=9222 connectaddress=::1 connectport=9222
اربط المستمع بعنوان المحوّل الذي يحتاج إليه WSL2. لا تعرض منفذ CDP
على 0.0.0.0 أو عنوان شبكة محلية أو عنوان 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بيانات JSON تتضمن بيانات Browser / Protocol-Version الوصفية - يعيد
/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:// - استخدم HTTP(S) عندما تريد من OpenClaw اكتشاف
/json/version - استخدم WS(S) فقط عندما يزوّدك موفّر المتصفح بعنوان URL مباشر لمقبس DevTools
- اختبر عنوان URL نفسه باستخدام
curlقبل توقع نجاح OpenClaw
الطبقة 4: تحقق من طبقة Control UI بصورة منفصلة
افتح http://127.0.0.1:18789/ من Windows، ثم تحقق مما يلي:
- تطابق أصل الصفحة مع ما يتوقعه
gateway.controlUi.allowedOrigins - ضبط مصادقة الرمز المميز أو الاقتران بصورة صحيحة
- أنك لا تشخّص مشكلة مصادقة في Control UI وكأنها مشكلة في المتصفح
صفحة مفيدة: Control UI.
الطبقة 5: تحقق من التحكم في المتصفح من البداية إلى النهاية
من WSL2:
openclaw browser --browser-profile remote open https://example.comopenclaw browser --browser-profile remote tabsالنتيجة السليمة:
- تُفتح علامة التبويب في Chrome على Windows
- يعيد
browser tabsالهدف - تعمل الإجراءات اللاحقة (
snapshotوscreenshotوnavigate) من ملف التعريف نفسه
أخطاء شائعة مضللة
| الرسالة | المعنى |
|---|---|
control-ui-insecure-auth |
مشكلة في أصل واجهة المستخدم/السياق الآمن، وليست مشكلة في نقل CDP |
token_missing |
مشكلة في إعداد المصادقة |
pairing required |
مشكلة في الموافقة على الجهاز |
Remote CDP for profile "remote" is not reachable |
لا يستطيع WSL2 الوصول إلى cdpUrl المضبوط |
رد CDP فارغ / other side closed عبر portproxy |
عدم تطابق في مستمع Windows أو حلقة ذاتية؛ افحص كلتا عائلتي الاسترجاع الحلقي وnetsh interface portproxy show all |
Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable |
استجابت نقطة نهاية HTTP، لكن تعذر فتح WebSocket الخاص بـ DevTools |
| بقاء إعدادات قديمة لإطار العرض/الوضع الداكن/اللغة/وضع عدم الاتصال بعد جلسة بعيدة | شغّل openclaw browser --browser-profile remote stop لإغلاق الجلسة وتحرير اتصال Playwright/CDP المخزّن مؤقتًا دون إعادة تشغيل Gateway أو المتصفح الخارجي |
انتهاء المهلة حول remoteCdpTimeoutMs (القيمة الافتراضية 1500ms) |
غالبًا ما تزال المشكلة في إمكانية الوصول إلى CDP، أو في نقطة نهاية بعيدة بطيئة/يتعذر الوصول إليها |
Playwright page enumeration timed out after 3000ms |
اتصل CDP البعيد، لكن قراءة علامات التبويب الدائمة توقفت؛ تكون المهلة هي القيمة الأكبر بين remoteCdpTimeoutMs وremoteCdpHandshakeTimeoutMs |
No Chrome tabs found for profile="user" |
تم اختيار ملف تعريف Chrome MCP محلي حيث لا تتوفر علامات تبويب محلية على المضيف |
قائمة تحقق سريعة للتشخيص
- على Windows: أيٌّ من
127.0.0.1أو[::1]يستجيب على/json/version، وهل ينتمي ذلك المستمع إلىchrome.exe؟ - على WSL2: هل يعمل
curl http://WINDOWS_HOST_OR_IP:9222/json/version؟ - إعداد OpenClaw: هل يستخدم
browser.profiles.<name>.cdpUrlذلك العنوان نفسه الذي يمكن لـ WSL2 الوصول إليه؟ - Control UI: هل تفتح
http://127.0.0.1:18789/بدلًا من عنوان IP للشبكة المحلية؟ - هل تحاول استخدام
existing-sessionعبر WSL2 وWindows بدلًا من CDP الخام عن بُعد؟
تحقق أولًا من نقطة نهاية Chrome على Windows محليًا، ثم تحقق من نقطة النهاية نفسها من WSL2، وبعد ذلك فقط شخّص إعداد OpenClaw أو مصادقة Control UI.