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

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

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

คุณมีรูปแบบที่ใช้ได้สองแบบ:

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

ใช้โปรไฟล์เบราว์เซอร์ระยะไกลที่ชี้จาก WSL2 ไปยังปลายทาง CDP ของ Windows Chrome

เลือกตัวเลือกนี้เมื่อ:

• Gateway ยังคงอยู่ภายใน WSL2
• Chrome ทำงานบน Windows
• คุณต้องการให้การควบคุมเบราว์เซอร์ข้ามขอบเขต WSL2/Windows

# ตัวเลือก 2: Chrome MCP แบบโลคัลบนโฮสต์

ใช้ existing-session / user เฉพาะเมื่อ Gateway เองทำงานบนโฮสต์เดียวกับ Chrome

เลือกตัวเลือกนี้เมื่อ:

• OpenClaw และ Chrome อยู่บนเครื่องเดียวกัน
• คุณต้องการสถานะเบราว์เซอร์โลคัลที่ลงชื่อเข้าใช้แล้ว
• คุณไม่ต้องการการขนส่งเบราว์เซอร์ข้ามโฮสต์
• คุณไม่ต้องการเส้นทางขั้นสูงที่มีเฉพาะในแบบจัดการ/ดิบ-CDP เท่านั้น เช่น responsebody, การส่งออก PDF, การดักจับการดาวน์โหลด หรือการทำงานแบบกลุ่ม

สำหรับ WSL2 Gateway + Windows Chrome ให้เลือกใช้ CDP ระยะไกลแบบดิบ Chrome MCP เป็นแบบโลคัลบนโฮสต์ ไม่ใช่สะพานจาก WSL2 ไปยัง Windows

# สถาปัตยกรรมที่ทำงานได้

รูปทรงอ้างอิง:

• WSL2 รัน Gateway บน 127.0.0.1:18789
• Windows เปิด UI ควบคุมในเบราว์เซอร์ปกติที่ http://127.0.0.1:18789/
• Windows Chrome เปิดเผยปลายทาง CDP บนพอร์ต 9222
• WSL2 สามารถเข้าถึงปลายทาง CDP ของ Windows นั้นได้
• OpenClaw ชี้โปรไฟล์เบราว์เซอร์ไปยังที่อยู่ที่เข้าถึงได้จาก WSL2

# เหตุใดการตั้งค่านี้จึงทำให้สับสน

ความล้มเหลวหลายอย่างอาจซ้อนทับกันได้:

• WSL2 ไม่สามารถเข้าถึงปลายทาง CDP ของ Windows
• UI ควบคุมถูกเปิดจากต้นทางที่ไม่ปลอดภัย
• gateway.controlUi.allowedOrigins ไม่ตรงกับต้นทางของหน้า
• โทเค็นหรือการจับคู่หายไป
• โปรไฟล์เบราว์เซอร์ชี้ไปยังที่อยู่ผิด

ด้วยเหตุนี้ การแก้ไขชั้นหนึ่งแล้วอาจยังเหลือข้อผิดพลาดอื่นให้เห็นอยู่

# กฎสำคัญสำหรับ UI ควบคุม

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

ใช้:

http://127.0.0.1:18789/

อย่าใช้ IP บน LAN เป็นค่าเริ่มต้นสำหรับ UI ควบคุม HTTP แบบไม่เข้ารหัสบนที่อยู่ LAN หรือ tailnet อาจกระตุ้นพฤติกรรมต้นทางไม่ปลอดภัย/การยืนยันอุปกรณ์ที่ไม่เกี่ยวข้องกับ CDP เอง ดู UI ควบคุม

# ตรวจสอบเป็นชั้น ๆ

ทำงานจากบนลงล่าง อย่าข้ามขั้นตอน

# ชั้นที่ 1: ตรวจสอบว่า Chrome ให้บริการ CDP บน Windows

เริ่ม Chrome บน Windows โดยเปิดใช้การดีบักระยะไกล:

chrome.exe --remote-debugging-port=9222

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

curl http://127.0.0.1:9222/json/version
curl http://127.0.0.1:9222/json/list

หากขั้นตอนนี้ล้มเหลวบน Windows ตอนนี้ปัญหายังไม่ใช่ OpenClaw

# ชั้นที่ 2: ตรวจสอบว่า WSL2 เข้าถึงปลายทางของ Windows นั้นได้

จาก WSL2 ให้ทดสอบที่อยู่จริงที่คุณวางแผนจะใช้ใน cdpUrl:

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

ผลลัพธ์ที่ดี:

• /json/version ส่งคืน JSON ที่มีเมทาดาทา Browser / Protocol-Version
• /json/list ส่งคืน JSON (อาร์เรย์ว่างก็ใช้ได้หากไม่มีหน้าใดเปิดอยู่)

หากขั้นตอนนี้ล้มเหลว:

• Windows ยังไม่ได้เปิดพอร์ตให้ WSL2
• ที่อยู่ไม่ถูกต้องสำหรับฝั่ง WSL2
• ไฟร์วอลล์ / การส่งต่อพอร์ต / การพร็อกซีโลคัลยังขาดอยู่

แก้ไขสิ่งนั้นก่อนแตะการกำหนดค่า OpenClaw

# ชั้นที่ 3: กำหนดค่าโปรไฟล์เบราว์เซอร์ที่ถูกต้อง

สำหรับ CDP ระยะไกลแบบดิบ ให้ชี้ 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: ตรวจสอบชั้น UI ควบคุมแยกต่างหาก

เปิด UI จาก Windows:

http://127.0.0.1:18789/

จากนั้นตรวจสอบว่า:

• ต้นทางของหน้าตรงกับที่ gateway.controlUi.allowedOrigins คาดไว้
• การยืนยันตัวตนด้วยโทเค็นหรือการจับคู่ถูกกำหนดค่าอย่างถูกต้อง
• คุณไม่ได้ดีบักปัญหาการยืนยันตัวตนของ UI ควบคุมราวกับเป็นปัญหาเบราว์เซอร์

หน้าที่เป็นประโยชน์:

• UI ควบคุม

# ชั้นที่ 5: ตรวจสอบการควบคุมเบราว์เซอร์แบบครบวงจร

จาก WSL2:

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

ผลลัพธ์ที่ดี:

• แท็บเปิดใน Windows Chrome
• openclaw browser tabs ส่งคืนเป้าหมาย
• การทำงานภายหลัง (snapshot, screenshot, navigate) ทำงานจากโปรไฟล์เดียวกัน

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

ให้ถือว่าแต่ละข้อความเป็นเบาะแสเฉพาะชั้น:

• control-ui-insecure-auth
  • ปัญหาต้นทาง UI / บริบทปลอดภัย ไม่ใช่ปัญหาการขนส่ง CDP
• token_missing
  • ปัญหาการกำหนดค่าการยืนยันตัวตน
• pairing required
  • ปัญหาการอนุมัติอุปกรณ์
• Remote CDP for profile "remote" is not reachable
  • WSL2 ไม่สามารถเข้าถึง cdpUrl ที่กำหนดค่าไว้
• Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable
  • ปลายทาง HTTP ตอบกลับแล้ว แต่ยังไม่สามารถเปิด DevTools WebSocket ได้
• การแทนที่ viewport / dark-mode / locale / offline ที่ค้างหลังจากเซสชันระยะไกล
  • รัน openclaw browser stop --browser-profile remote
  • คำสั่งนี้ปิดเซสชันควบคุมที่ใช้งานอยู่และปล่อยสถานะการจำลอง Playwright/CDP โดยไม่ต้องรีสตาร์ท Gateway หรือเบราว์เซอร์ภายนอก
• gateway timeout after 1500ms
  • มักยังเป็นเรื่องการเข้าถึง CDP หรือปลายทางระยะไกลที่ช้า/เข้าถึงไม่ได้
• No Chrome tabs found for profile="user"
  • เลือกโปรไฟล์ Chrome MCP โลคัลไว้ในจุดที่ไม่มีแท็บแบบโลคัลบนโฮสต์ให้ใช้

# รายการตรวจสอบการคัดแยกอย่างรวดเร็ว

1. Windows: curl http://127.0.0.1:9222/json/version ทำงานหรือไม่?
2. WSL2: curl http://WINDOWS_HOST_OR_IP:9222/json/version ทำงานหรือไม่?
3. การกำหนดค่า OpenClaw: browser.profiles.<name>.cdpUrl ใช้ที่อยู่เดียวกันที่ WSL2 เข้าถึงได้นั้นจริงหรือไม่?
4. UI ควบคุม: คุณกำลังเปิด http://127.0.0.1:18789/ แทน IP บน LAN อยู่หรือไม่?
5. คุณกำลังพยายามใช้ existing-session ข้าม WSL2 กับ Windows แทน CDP ระยะไกลแบบดิบอยู่หรือไม่?

# ข้อสรุปเชิงปฏิบัติ

การตั้งค่านี้มักทำได้จริง ส่วนที่ยากคือการขนส่งเบราว์เซอร์ ความปลอดภัยของต้นทาง UI ควบคุม และโทเค็น/การจับคู่ สามารถล้มเหลวแยกกันได้โดยดูคล้ายกันจากฝั่งผู้ใช้

เมื่อไม่แน่ใจ:

• ตรวจสอบปลายทาง Windows Chrome แบบโลคัลก่อน
• ตรวจสอบปลายทางเดียวกันจาก WSL2 เป็นลำดับที่สอง
• จากนั้นจึงดีบักการกำหนดค่า OpenClaw หรือการยืนยันตัวตนของ UI ควบคุม

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

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