Trong thiết lập tách máy chủ phổ biến, OpenClaw Gateway chạy bên trong WSL2, Chrome chạy trên Windows, và việc điều khiển trình duyệt phải đi qua ranh giới giữa WSL2 và Windows. Mẫu lỗi nhiều lớp từ vấn đề #39369 nghĩa là nhiều sự cố độc lập có thể xuất hiện cùng lúc, khiến lớp sai trông như bị hỏng trước tiên.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Chọn đúng chế độ trình duyệt trước
Bạn có hai mẫu hợp lệ:Tùy chọn 1: CDP từ xa thô từ WSL2 đến Windows
Dùng hồ sơ trình duyệt từ xa trỏ từ WSL2 đến một điểm cuối Chrome CDP trên Windows. Chọn cách này khi:- Gateway vẫn ở bên trong WSL2
- Chrome chạy trên Windows
- bạn cần điều khiển trình duyệt đi qua ranh giới WSL2/Windows
Tùy chọn 2: Chrome MCP cục bộ trên máy chủ
Chỉ dùngexisting-session / user khi chính Gateway chạy trên cùng máy chủ với Chrome.
Chọn cách này khi:
- OpenClaw và Chrome ở trên cùng một máy
- bạn muốn trạng thái trình duyệt cục bộ đã đăng nhập
- bạn không cần truyền tải trình duyệt xuyên máy chủ
- bạn không cần các tuyến nâng cao chỉ dành cho quản lý/CDP thô như
responsebody, xuất PDF, chặn tải xuống, hoặc hành động hàng loạt
Kiến trúc hoạt động
Hình dạng tham chiếu:- WSL2 chạy Gateway trên
127.0.0.1:18789 - Windows mở Giao diện Điều khiển trong trình duyệt thông thường tại
http://127.0.0.1:18789/ - Windows Chrome phơi bày một điểm cuối CDP trên cổng
9222 - WSL2 có thể truy cập điểm cuối Windows CDP đó
- OpenClaw trỏ một hồ sơ trình duyệt đến địa chỉ có thể truy cập từ WSL2
Vì sao thiết lập này dễ gây nhầm lẫn
Nhiều lỗi có thể chồng lên nhau:- WSL2 không thể truy cập điểm cuối Windows CDP
- Giao diện Điều khiển được mở từ một nguồn gốc không an toàn
gateway.controlUi.allowedOriginskhông khớp với nguồn gốc của trang- thiếu token hoặc ghép đôi
- hồ sơ trình duyệt trỏ đến sai địa chỉ
Quy tắc quan trọng cho Giao diện Điều khiển
Khi UI được mở từ Windows, dùng localhost của Windows trừ khi bạn có thiết lập HTTPS có chủ đích. Dùng:http://127.0.0.1:18789/
Đừng mặc định dùng IP LAN cho Giao diện Điều khiển. HTTP thuần trên địa chỉ LAN hoặc tailnet có thể kích hoạt hành vi nguồn gốc không an toàn/xác thực thiết bị không liên quan đến chính CDP. Xem Giao diện Điều khiển.
Xác thực theo từng lớp
Làm từ trên xuống dưới. Đừng nhảy bước.Lớp 1: Xác minh Chrome đang phục vụ CDP trên Windows
Khởi động Chrome trên Windows với gỡ lỗi từ xa được bật:Lớp 2: Xác minh WSL2 có thể truy cập điểm cuối Windows đó
Từ WSL2, kiểm tra đúng địa chỉ bạn định dùng trongcdpUrl:
/json/versiontrả về JSON có siêu dữ liệu Browser / Protocol-Version/json/listtrả về JSON (mảng rỗng cũng được nếu không có trang nào đang mở)
- Windows chưa phơi bày cổng cho WSL2
- địa chỉ sai ở phía WSL2
- tường lửa / chuyển tiếp cổng / proxy cục bộ vẫn còn thiếu
Lớp 3: Cấu hình đúng hồ sơ trình duyệt
Với CDP từ xa thô, trỏ OpenClaw đến địa chỉ có thể truy cập từ WSL2:- dùng địa chỉ có thể truy cập từ WSL2, không phải địa chỉ chỉ hoạt động trên Windows
- giữ
attachOnly: truecho các trình duyệt được quản lý bên ngoài cdpUrlcó thể làhttp://,https://,ws://, hoặcwss://- dùng HTTP(S) khi bạn muốn OpenClaw khám phá
/json/version - chỉ dùng WS(S) khi nhà cung cấp trình duyệt cung cấp cho bạn URL socket DevTools trực tiếp
- kiểm tra cùng URL đó bằng
curltrước khi kỳ vọng OpenClaw thành công
Lớp 4: Xác minh riêng lớp Giao diện Điều khiển
Mở UI từ Windows:http://127.0.0.1:18789/
Sau đó xác minh:
- nguồn gốc trang khớp với điều mà
gateway.controlUi.allowedOriginsmong đợi - xác thực token hoặc ghép đôi được cấu hình đúng
- bạn không đang gỡ lỗi một vấn đề xác thực Giao diện Điều khiển như thể đó là vấn đề trình duyệt
Lớp 5: Xác minh điều khiển trình duyệt đầu-cuối
Từ WSL2:- tab mở trong Windows Chrome
openclaw browser tabstrả về đích- các hành động sau đó (
snapshot,screenshot,navigate) hoạt động từ cùng hồ sơ
Các lỗi dễ gây hiểu nhầm thường gặp
Xem mỗi thông báo như một manh mối theo lớp cụ thể:control-ui-insecure-auth- vấn đề nguồn gốc UI / ngữ cảnh an toàn, không phải vấn đề truyền tải CDP
token_missing- vấn đề cấu hình xác thực
pairing required- vấn đề phê duyệt thiết bị
Remote CDP for profile "remote" is not reachable- WSL2 không thể truy cập
cdpUrlđã cấu hình
- WSL2 không thể truy cập
Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable- điểm cuối HTTP đã phản hồi, nhưng DevTools WebSocket vẫn không thể được mở
- ghi đè khung nhìn / chế độ tối / ngôn ngữ / ngoại tuyến cũ sau một phiên từ xa
- chạy
openclaw browser stop --browser-profile remote - thao tác này đóng phiên điều khiển đang hoạt động và giải phóng trạng thái mô phỏng Playwright/CDP mà không khởi động lại gateway hoặc trình duyệt bên ngoài
- chạy
gateway timeout after 1500ms- thường vẫn là khả năng truy cập CDP hoặc điểm cuối từ xa chậm/không truy cập được
No Chrome tabs found for profile="user"- hồ sơ Chrome MCP cục bộ được chọn khi không có tab cục bộ trên máy chủ nào khả dụng
Danh sách kiểm tra phân loại nhanh
- Windows:
curl http://127.0.0.1:9222/json/versioncó hoạt động không? - WSL2:
curl http://WINDOWS_HOST_OR_IP:9222/json/versioncó hoạt động không? - Cấu hình OpenClaw:
browser.profiles.<name>.cdpUrlcó dùng đúng địa chỉ có thể truy cập từ WSL2 đó không? - Giao diện Điều khiển: bạn có đang mở
http://127.0.0.1:18789/thay vì IP LAN không? - Bạn có đang cố dùng
existing-sessionxuyên WSL2 và Windows thay vì CDP từ xa thô không?
Kết luận thực tế
Thiết lập này thường khả thi. Phần khó là truyền tải trình duyệt, bảo mật nguồn gốc Giao diện Điều khiển, và token/ghép đôi đều có thể lỗi độc lập trong khi trông giống nhau từ phía người dùng. Khi nghi ngờ:- xác minh cục bộ điểm cuối Windows Chrome trước
- xác minh cùng điểm cuối đó từ WSL2 sau
- chỉ sau đó mới gỡ lỗi cấu hình OpenClaw hoặc xác thực Giao diện Điều khiển