MCP 实战：自动化浏览器调试（DevTools MCP）从 0 到可用

很多人把 MCP 当成“让 AI 调工具”的概念词，但真落地时最常卡在浏览器调试：AI 连不上 Chrome、拿不到网络请求、看不到性能瓶颈。这篇直接给你一套能复制的流程，把 DevTools MCP 跑起来，让 AI 能自动查页面问题。

适用环境

Windows 11 + WSL2
Chrome（Windows 侧）
WSL 中可用 node / npx
任意支持 MCP 的客户端（如 Codex CLI）

1) 在 Windows 打开 9222 转发与防火墙

用管理员权限打开 PowerShell，执行：

netsh interface portproxy add v4tov4 `
  listenaddress=0.0.0.0 listenport=9222 `
  connectaddress=127.0.0.1 connectport=9222

New-NetFirewallRule `
  -DisplayName "Chrome DevTools MCP 9222" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 9222 `
  -Action Allow

这一步解决的是：WSL 访问不到 Windows 本地 127.0.0.1:9222 的问题。

2) 启动带远程调试参数的 Chrome

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

建议单独 user-data-dir，别污染你平时浏览器配置。

3) 在 WSL 侧配置 DevTools MCP

示例（Codex）：

[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest", "--browserUrl=http://172.31.240.1:9222/json"]

172.31.240.1 不是固定值，去 Windows ipconfig 里找 vEthernet (WSL...) 的 IPv4。

4) 先做连通性检查，再交给 AI

在 WSL 里先测：

curl http://172.31.240.1:9222/json

如果返回 JSON 且带 webSocketDebuggerUrl，说明链路通了。再让 AI 做这些事：

自动抓控制台报错
自动分析 Network 慢请求
自动导出性能 trace（定位 LCP/INP）
自动回归检查关键页面

常见坑与修复

坑 1：`curl` 超时

检查 PowerShell 的端口转发和防火墙规则是否生效
确认 Chrome 仍在带 --remote-debugging-port=9222 运行

坑 2：MCP 客户端连上但没有页面

浏览器 URL 要用 /json 端点，不是裸 9222
Chrome 可能开在了另一个 profile 或被旧进程占住

坑 3：偶发断连

避免系统睡眠后复用旧 session
断连后先重启 Chrome，再重启 MCP server

为什么这个方案对流量站点有价值

如果你做博客或内容站，页面体验直接影响收录和停留时长。让 AI 接管 DevTools 后，能把“慢、报错、渲染抖动”这类问题从手工巡检变成自动化流程，长期就是更稳的 SEO 表现。

总结

核心就三步：Windows 放行 9222、Chrome 开远程调试、WSL 用网关 IP 连 /json。链路通了以后，AI 才真能接管浏览器调试，而不是只会纸上谈兵。

适用环境#

1) 在 Windows 打开 9222 转发与防火墙#

2) 启动带远程调试参数的 Chrome#

3) 在 WSL 侧配置 DevTools MCP#

4) 先做连通性检查，再交给 AI#

常见坑与修复#

坑 1：curl 超时#

坑 2：MCP 客户端连上但没有页面#

坑 3：偶发断连#

为什么这个方案对流量站点有价值#

总结#