Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Chrome 147+ binds CDP to IPv6 only; v4tov4 portproxy breaks WSL2 remote debugging [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#68666•Fetched 2026-04-19 15:08:51
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
lumienlumien
Participants
lumienlumien

Chrome 147+ binds --remote-debugging-port to IPv6 [::1] only, not IPv4 127.0.0.1. The existing WSL2 troubleshooting docs recommend v4tov4 portproxy which forwards to IPv4 — this no longer works with Chrome 147.

Root Cause

Chrome 147+ binds --remote-debugging-port to IPv6 [::1] only, not IPv4 127.0.0.1. The existing WSL2 troubleshooting docs recommend v4tov4 portproxy which forwards to IPv4 — this no longer works with Chrome 147.

Fix Action

Fix

Use v4tov6 portproxy instead of v4tov4:

netsh interface portproxy delete v4tov4 listenport=9222 listenaddress=0.0.0.0
netsh interface portproxy add v4tov6 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=::1

Additionally, Chrome 147 requires --user-data-dir to be a non-default directory for CDP HTTP endpoints to respond:

chrome.exe --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --user-data-dir="C:\ChromeDebug" --no-first-run --remote-allow-origins="*"

Without --user-data-dir, Chrome shows LISTENING on port 9222 but returns empty replies to all HTTP requests.

Code Example

netsh interface portproxy delete v4tov4 listenport=9222 listenaddress=0.0.0.0
netsh interface portproxy add v4tov6 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=::1

---

chrome.exe --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --user-data-dir="C:\ChromeDebug" --no-first-run --remote-allow-origins="*"
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug / Documentation gap

Summary

Chrome 147+ binds --remote-debugging-port to IPv6 [::1] only, not IPv4 127.0.0.1. The existing WSL2 troubleshooting docs recommend v4tov4 portproxy which forwards to IPv4 — this no longer works with Chrome 147.

Steps to reproduce

  1. Run Chrome 147 on Windows with --remote-debugging-port=9222
  2. Configure v4tov4 portproxy per docs: netsh interface portproxy add v4tov4 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=127.0.0.1
  3. From WSL2: curl http://<windows-ip>:9222/json/version → Empty reply (exit code 52)
  4. From Windows: curl http://127.0.0.1:9222/json/version → Empty reply
  5. From Windows: curl http://[::1]:9222/json/version → 200 OK, returns JSON

Expected behavior

curl http://127.0.0.1:9222/json/version should return Chrome DevTools JSON, as it did in Chrome 146 and earlier.

Actual behavior

Chrome 147 only responds on [::1]:9222 (IPv6 loopback). IPv4 connections are accepted (TCP handshake completes) but Chrome returns empty responses.

Fix

Use v4tov6 portproxy instead of v4tov4:

netsh interface portproxy delete v4tov4 listenport=9222 listenaddress=0.0.0.0
netsh interface portproxy add v4tov6 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=::1

Additionally, Chrome 147 requires --user-data-dir to be a non-default directory for CDP HTTP endpoints to respond:

chrome.exe --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --user-data-dir="C:\ChromeDebug" --no-first-run --remote-allow-origins="*"

Without --user-data-dir, Chrome shows LISTENING on port 9222 but returns empty replies to all HTTP requests.

Diagnosis tips

  1. If netstat shows LISTENING on 9222 but curl http://127.0.0.1:9222/json/version returns empty → test IPv6: curl http://[::1]:9222/json/version
  2. If IPv6 works but IPv4 doesn't → Chrome 147 IPv6-only binding, use v4tov6 portproxy
  3. If neither works → Chrome needs --user-data-dir pointing to a non-default directory

Suggested doc update

The WSL2 troubleshooting page (https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting) should be updated to:

  1. Note Chrome 147+ IPv6-only CDP binding
  2. Recommend v4tov6 portproxy instead of v4tov4
  3. Note the --user-data-dir requirement for CDP to respond

OpenClaw version

2026.4.15

Operating system

Windows 11 + WSL2 (Ubuntu)

Install method

Gateway in WSL2 + Chrome 147 on Windows via remote CDP

extent analysis

TL;DR

To fix the issue with Chrome 147 not responding on IPv4, use v4tov6 portproxy instead of v4tov4 and specify a non-default --user-data-dir when running Chrome.

Guidance

  • Update the portproxy configuration to use v4tov6 instead of v4tov4 to forward IPv4 requests to Chrome's IPv6-bound debugging port.
  • Specify a non-default directory for --user-data-dir when running Chrome to enable CDP HTTP endpoints to respond.
  • Verify that Chrome is listening on the correct port and address using netstat and test both IPv4 and IPv6 connections using curl.
  • If issues persist, check the Chrome version and ensure that the --remote-debugging-port and --remote-debugging-address flags are correctly set.

Example

netsh interface portproxy add v4tov6 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=::1
chrome.exe --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --user-data-dir="C:\ChromeDebug" --no-first-run --remote-allow-origins="*"

Notes

This solution assumes that the issue is specific to Chrome 147 and later versions, and that the v4tov6 portproxy and non-default --user-data-dir are sufficient to resolve the issue.

Recommendation

Apply the workaround by updating the portproxy configuration and specifying a non-default --user-data-dir when running Chrome, as this is a specific solution to the issue described.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

curl http://127.0.0.1:9222/json/version should return Chrome DevTools JSON, as it did in Chrome 146 and earlier.

#api#ssr#installation#tensor shape#autograd error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING