การแก้ไขปัญหา WSL2 + Windows + Chrome CDP ระยะไกล

ในการตั้งค่าแบบแยกโฮสต์ที่ใช้กันทั่วไป OpenClaw Gateway จะทำงานภายใน WSL2 ส่วน Chrome ทำงาน บน Windows และการควบคุมเบราว์เซอร์ต้องข้ามขอบเขตระหว่าง WSL2/Windows ปัญหาอิสระหลายอย่าง อาจเกิดขึ้นพร้อมกันได้ (ดู ปัญหา #39369): การรับส่งข้อมูล CDP, ความปลอดภัยของต้นทาง Control UI และโทเค็น/การจับคู่ อาจล้มเหลวแยกจากกัน แต่แสดงข้อผิดพลาดที่ดูคล้ายกัน ให้ตรวจสอบแต่ละชั้น ด้านล่างตามลำดับ แทนที่จะคาดเดาว่าส่วนใดเสียหาย

เลือกโหมดเบราว์เซอร์ที่ถูกต้องก่อน

ตัวเลือก 1: CDP ระยะไกลโดยตรงจาก WSL2 ไปยัง Windows

ใช้โปรไฟล์เบราว์เซอร์ระยะไกลที่ชี้จาก WSL2 ไปยังปลายทาง Chrome CDP บน 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

เมื่อเปิด UI จาก Windows ให้ใช้ localhost ของ Windows เว้นแต่คุณตั้งค่า HTTPS ไว้โดยเจตนา:

http://127.0.0.1:18789/

อย่าใช้ IP ของ LAN เป็นค่าเริ่มต้น HTTP แบบไม่เข้ารหัสบนที่อยู่ LAN หรือ 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 ปกติที่ลงชื่อเข้าใช้แล้วสามารถควบคุมจากระยะไกลได้

จาก Windows ให้ตรวจสอบ Chrome โดยตรงก่อน:

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 ที่ไม่ได้ใช้งาน:

  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 ส่งคืน 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) ทำงานจากโปรไฟล์ เดียวกัน

ข้อผิดพลาดที่มักทำให้เข้าใจผิด

รายการตรวจสอบเพื่อคัดแยกปัญหาอย่างรวดเร็ว

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: คุณกำลังเปิด http://127.0.0.1:18789/ แทน IP ของ LAN หรือไม่?
5. คุณกำลังพยายามใช้ existing-session ข้ามระหว่าง WSL2 และ Windows แทน CDP ระยะไกลโดยตรงหรือไม่?

ตรวจสอบปลายทาง Chrome บน Windows ภายในเครื่องก่อน จากนั้นตรวจสอบปลายทางเดียวกัน จาก WSL2 และหลังจากนั้นจึงค่อยแก้ไขข้อบกพร่องการกำหนดค่า OpenClaw หรือการยืนยันตัวตนของ Control UI

ที่เกี่ยวข้อง

• เบราว์เซอร์
• การเข้าสู่ระบบเบราว์เซอร์
• การแก้ไขปัญหาเบราว์เซอร์บน Linux