L站有没有SM的资深用户，难道没有人想过重构这个软件吗？

在 Windows10 WSL2 中使用 chrome-devtools mcp 的配置经验
起因
我在 Windows 10 上用 VS Code 和 Chrome，在 WSL2 里用 Codex / Claude，通过 chrome-devtools-mcp 去驱动宿主机浏览器。
直觉上，既然 Chrome 开了远程调试端口：

"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir="$env:USERPROFILE\ChromeProfiles\mcp" --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --no-first-run --no-default-browser-check


那在 WSL2 里 curl http://<宿主机IP>:9222/json 应该就能拿到 DevTools 的 JSON 列表。但实际情况是：


Windows 本机 http://127.0.0.1:9222/json 可以访问；


WSL2 里 curl http://172.x.x.x:9222/json 一直连不上。


问题的本质：WSL2 是独立网络栈，Chrome 又只监听在 Windows 自己的 loopback 上，两边默认是打不通的。
曲折
第一轮：WSL2 → Windows 网络不通
在 WSL2 中我这样拿宿主机 IP：

HOST_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}')

curl -v --connect-timeout 5 "http://$HOST_IP:9222/json"


结果是 Connection timeout。与此同时，在 Windows 上：

netstat -ano | findstr 9222

TCP 127.0.0.1:9222 0.0.0.0:0 LISTENING


Chrome 只监听 127.0.0.1:9222。从 WSL2 看过去，目标是 172.x.x.x:9222，自然连不上。
于是我照常规做法加了 portproxy 和防火墙放行，想让 0.0.0.0:9222 对外暴露，再转回 127.0.0.1:9222。这个阶段网络问题基本解决，但埋下了后面的坑。
第二轮：连接通了，但“空响应”
后来我发现：


WSL2 → http://HOST_IP:9223/json 可以建立 TCP 连接；


Windows 本机 → http://127.0.0.1:9222/json 也能连上；


但两边都是：curl: (52) Empty reply from server。


这说明：


防火墙没有拦；


连接也不是超时、不是拒绝；


是服务端收到请求后直接把连接掐掉，一个字节的 HTTP 响应都没发。


直到我临时换了一个端口：

"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir="$env:USERPROFILE\ChromeProfiles\mcp" --remote-debugging-port=9228 --remote-debugging-address=0.0.0.0 --no-first-run --no-default-browser-check


然后：

curl.exe -v "http://127.0.0.1:9228/json"


立刻得到正常的 200 + JSON 结果。这说明：


Chrome 的远程调试功能本身是好的；


真正“坏掉”的只是一开始折腾 portproxy 时的那个 9222。


结合之前做过类似：

netsh interface portproxy add v4tov4 `

listenaddress=0.0.0.0 listenport=9222 `

connectaddress=127.0.0.1 connectport=9222


可以合理推断：这条“0.0.0.0:9222 → 127.0.0.1:9222”的自转发，把 9222 的行为搞乱了——连接能建，但应用层表现异常，导致“Empty reply from server”。
第三轮：换一个干净端口 + 全链路打通
确认 9228 正常后，我直接放弃 9222，选了一个干净的组合：


Chrome 调试端口：9228（仅 Windows 本机用）；


portproxy 对外暴露：9229（给 WSL2 / MCP 用）。


这样做的好处：


避开了任何历史遗留配置；


9228 只在本机回环网卡上用，不直接暴露；


WSL2 统一连 HOST_IP:9229，逻辑清晰。


结果
最终状态：


在 Windows 上，Chrome 正常监听 127.0.0.1:9228 并提供 DevTools 的 /json 接口；


用 netsh interface portproxy 把 0.0.0.0:9229 转发到 127.0.0.1:9228；


用 New-NetFirewallRule 永久放行入站 TCP 9229；


在 WSL2 中，通过 /etc/resolv.conf 里的 nameserver 拿到宿主机 IP，然后直接访问 http://HOST_IP:9229/json；


MCP 的配置统一指向 HOST_IP:9229，chrome-devtools-mcp 就能从 WSL2 驱动 Windows 上的 Chrome。


经过这套配置之后，无论我重启 WSL2 还是 Windows，只需要重启一次 Chrome，就能恢复整个链路。
最终可执行命令
下面是我最终稳定使用的一套完整命令。
1. Windows 侧（管理员 PowerShell）
1.1 启动专用 Chrome（DevTools 端口 9228）

taskkill /IM chrome.exe /F

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `

--user-data-dir="$env:USERPROFILE\ChromeProfiles\mcp" `

--remote-debugging-port=9228 `

--remote-debugging-address=127.0.0.1 `

--no-first-run `

--no-default-browser-check


1.2 配置端口转发：0.0.0.0:9229 → 127.0.0.1:9228

netsh interface portproxy add v4tov4 `

listenaddress=0.0.0.0 listenport=9229 `

connectaddress=127.0.0.1 connectport=9228


1.3 配置防火墙放行 9229（只需要执行一次）

New-NetFirewallRule `

-DisplayName "Chrome DevTools MCP 9229" `

-Direction Inbound `

-Protocol TCP `

-LocalPort 9229 `

-Action Allow


1.4 本机验证 DevTools 是否正常

curl.exe -v "http://127.0.0.1:9228/json"


应该返回 HTTP 200 + JSON。
2. WSL2 侧
2.1 获取宿主机 IP

HOST_IP=$(grep nameserver /etc/resolv.conf | awk '{print $2}')

echo "$HOST_IP"


典型值类似 172.21.144.1。
2.2 验证跨系统访问

curl -v "http://$HOST_IP:9229/json"


如果输出和 Windows 本机访问 9228 的 JSON 一样，就说明：


WSL2 → Windows 的链路 OK；


portproxy OK；


防火墙规则 OK。


2.3 MCP / chrome-devtools-mcp 配置要点


host：上面拿到的 HOST_IP（例如 172.21.144.1）；


port：9229。



codex


[mcp_servers.chrome-devtools]

command = "npx"

args = ["chrome-devtools-mcp@latest", "--browserUrl=http://172.21.144.1:9229"]

startup_timeout_sec = 60.0


只要这两项对了，WSL2 中运行的 MCP（Codex / Claude）就能通过 HOST_IP:9229 跟 Windows 上的 C

本机电脑开启了v2rayN的“自动配置系统代理”，然后使用ssh连接远程服务器。我并没有开启tun模式和本地Socks5代理，但是通过echo $SSH_CONNECTION这行命令发现输出的居然是代理IP，而不是本机IP。请问这个是合理的吗？假如这样，用美国的IP 连接中国注册的甲骨文服务器，甲骨文辉被封吗（因为检测到的是美国IP）

我想升级，大家可以帮我一线嘛

网站地址：https://dontkillmyapp.com/

最早是几年前看于建国博士的学习观系列视频入的坑的，当时真的被震住了。很多概念放到现在看都算超前但又说得通。后来他又出了世界模型的课程，正好赶上这几年 AI 一路狂飙，越看越感觉当年那套东西是真有远见。