---
read_when:
    - การเรียกใช้ OpenClaw Gateway ใน WSL2 ขณะที่ Chrome อยู่บน Windows
    - พบข้อผิดพลาดเกี่ยวกับเบราว์เซอร์/control-ui ที่ทับซ้อนกันทั้งใน WSL2 และ Windows
    - การตัดสินใจเลือกระหว่าง Chrome MCP ภายในโฮสต์กับ CDP ระยะไกลโดยตรงในการตั้งค่าแบบแยกโฮสต์
summary: แก้ไขปัญหา WSL2 Gateway + CDP ระยะไกลของ Chrome บน Windows แบบเป็นลำดับชั้น
title: การแก้ไขปัญหา WSL2 + Windows + Chrome CDP ระยะไกล
x-i18n:
    generated_at: "2026-04-30T10:18:33Z"
    model: gpt-5.5
    provider: openai
    source_hash: 7532c672f7e829b851d175d93354fc586baecea4af5f2555f57908780cedfd02
    source_path: tools/browser-wsl2-windows-remote-cdp-troubleshooting.md
    workflow: 16
---

ในการตั้งค่าแบบแยกโฮสต์ที่พบบ่อย OpenClaw Gateway ทำงานภายใน WSL2, Chrome ทำงานบน Windows และการควบคุมเบราว์เซอร์ต้องข้ามขอบเขตระหว่าง WSL2 กับ Windows รูปแบบความล้มเหลวแบบหลายชั้นจาก [issue #39369](https://github.com/openclaw/openclaw/issues/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 ควบคุม](/th/web/control-ui)

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

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

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

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

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

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

```powershell
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`:

```bash
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:

```json5
{
  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 ควบคุม](/th/web/control-ui)

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

จาก WSL2:

```bash
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 ควบคุม

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

- [เบราว์เซอร์](/th/tools/browser)
- [การเข้าสู่ระบบเบราว์เซอร์](/th/tools/browser-login)
- [การแก้ปัญหาเบราว์เซอร์บน Linux](/th/tools/browser-linux-troubleshooting)