Chrome 144 下 MCP 自动化配置大幅简化，LLM 可更方便地控制你已登录的浏览器会话了

问题描述：

1 月 13 日发布的 Chrome 144 稳定版正式支持在 chrome://inspect/#remote-debugging 页面直接启动 remote debugging ，这对于 Chrome Devtools MCP 以及其他希望通过 CDP 协议 来对 Chrome 默认 profile 进行自动化控制的用户是重大利好。Edge 144 也同样支持了该特性。

---

比如你的工作流中需要 LLM 使用 Chrome Devtools MCP 控制浏览器，在此前的 Chrome 版本中，一般的配置方案如下：

1. 关闭所有 Chrome 实例，使用 chrome --remote-debugging-port=9222 --user-data-dir=xxx 命令启动一个全新的 Chrome 实例。由于 --user-data-dir 不允许使用用户默认的 profile 路径，用户或 LLM 需要在全新的 profile 下重新登录以访问受限资源。

2. 使用默认的 Chrome Devtools MCP 配置，比如

   "chrome-devtools": { "command": "npx", "args": [ "-y", "chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222" ] }

更新 Chrome 144 后，只需做如下配置 LLM 即可通过 Chrome Devtools MCP 控制当前 正在运行 的 Chrome 默认 profile:

1. 在 Chrome 中访问 chrome://inspect/#remote-debugging，勾选 Allow remote debugging for this browser instance

2. 使用如下 Chrome Devtools MCP 配置

   "chrome-devtools": { "command": "npx", "args": [ "-y", "chrome-devtools-mcp@latest", "--auto-connect" ] }

这一特性带来很多好处：

• 你不必关闭正在访问的页面就能立即让 LLM 或其他 CDP 工具控制浏览器
• LLM 可以复用已经你登陆、已有 cookie 的浏览器会话
• 在 Web 开发测试过程中，网站出现问题时 LLM 能够随时接管并共享所有的 Devtools 上下文

想要更好地利用 CDP 协议并发现更多工具，可以参考 ChromeDevTools/awesome-chrome-devtools

网友解答：

---

--【壹】--：

这ai自动化更方便了？

---

--【贰】--：

方便多了，之前这样得用chrome beta版本的chrome浏览器

---

--【叁】--：

如果没开debug岂不是会报错

---

--【肆】--：

果然L站常看常新呀，这就去配置了！

---

--【伍】--：

比较好奇这个和playwright哪个好用一些

看了一下大概就是方便在自己已经打开的浏览器中进行操作了？也就是说在需要复用已经登录好的账号之类的情况下？

---

--【陆】--：

win11下很简单，步骤如下：
1、将WSL2的网络模式调整为 Mirrored
2、chrome开启调试：chrome://inspect/#remote-debugging
3、cc 配置 chrome-devtools mcp：claude mcp add chrome-devtools -s user – npx chrome-devtools-mcp@latest --browserUrl=http://127.0.0.1:9222

---

--【柒】--：

利好爬虫呀

不用花时间配置反爬

不过 网站似乎可以检测到

---

--【捌】--：

如果有佬遇到这个问题，Error: Network.enable timed out. Increase the 'protocolTimeout' setting。可以参考 issue Connecting to Chrome with suspended/frozen tabs fails (usually with --auto-connect) · Issue #775 · ChromeDevTools/chrome-devtools-mcp · GitHub 如果有冻结标签的话就会报错

---

--【玖】--：

我在Win上测试的这套配置，（按照Chrome144的方案）如果chrome没有运行就直接调用MCP，是会报错无法连接的，不会自动启用chrome实例。

---

--【拾】--：

终于等到了

---

--【拾壹】--：

我发现一个问题，如果是多用户（头像处添加其他账号），启动的2个chrome实例都是9222端口，2个实例是同时开同时关的。
我怎么做才能连指定账号的chrome实例呢？

---

--【拾贰】--：

不知道wsl能不能连win下开的chrome，现在cc提示● MCPSearch(Search MCP tools: “select:mcp__chrome-devtools__list_pages”)
⎿ Found 1 tool
⎿ Error: Could not connect to Chrome. Check if Chrome is running and remote debugging is enabled by going to chrome://inspect/#remote-debugging.
Cause: Could not find DevToolsActivePort for chrome at /root/config/google-chrome/DevToolsActivePort

---

--【拾叁】--：

这两天测试了一下，功能差不多，并且remote debugging是Chrome一侧的新特性，Playwright也能通过--cdp-endpoint=ws://127.0.0.1:9222/devtools/browser/<UID>参数来使用（目前仅发现这一种连接方式可用），其中 <UID> 可以在 %LOCALAPPDATA%\Google\Chrome\User Data\DevToolsActivePort 文件中找到。

chrome-devtools-mcp 底层用的是 Puppeteer。Puppeteer是Google开发的项目，但是仅支持Chrome的控制，发展比较久了；Playwright是MS的项目，起步晚，但支持几乎所有的浏览器平台。另外Puppeteer的开发sdk好像也比较少，支持GO和TS；Playwright支持很多语言包括Python。个人测试下来网页基本操作方面chrome-devtools-mcp和playwright-mcp的体验差不多。

---

--【拾肆】--：

我刚测试出来的方法，在 chrome 桌面快捷方式上点属性 → 目标，后面加上–remote-debugging-port=9222，这种方式启动 chrome，还是用你原来的 user data dir，最方便

---

--【拾伍】--：

使用一个月，算是搞清楚了。

如果不希望修改 WSL2 默认的 NAT 网络模式，可以按照下面方法配置：

# 以下命令在 WSL 终端中执行 # 获得 WSL2 所在虚拟子网的网关地址 <WSL_HOST_IP> ip route show | grep -i default | awk '{ print $3}'

# 以下命令通过管理员权限在 Windows PowerShell 执行 # 1. 将 WSL2 请求 Windows 主机 9222 端口映射到 Windows 主机的 127.0.0.1:9222 netsh interface portproxy add v4tov4 ` listenaddress=<WSL_HOST_IP> listenport=9222 ` connectaddress=127.0.0.1 connectport=9222 # 2. 开放防火墙 9222 端口给 WSL 网关 New-NetFirewallRule -DisplayName "WSL to Win 9222" ` -Direction Inbound -Action Allow -Protocol TCP ` -LocalPort 9222 -LocalAddress <WSL_HOST_IP> # 注意，如果正常使用一段时间后发现再次出现无法连接 remote debugging 的问题，可以删除第一步的防火墙映射规则，重新配置一遍，应该能修复。 # 列出所有映射规则 netsh interface portproxy show all # 删除不作用的规则 netsh interface portproxy delete v4tov4 listenaddress=<WSL_HOST_IP> listenport=9222 # 重新添加 netsh interface portproxy add v4tov4 ` listenaddress=<WSL_HOST_IP> listenport=9222 ` connectaddress=127.0.0.1 connectport=9222

原理：使用 chrome-devtools-mcp 的 --wsEndpoint 参数连接方式，只需要这一个参数即可连接到启用了 remote-debugging 开关的 Chrome 浏览器实例。--wsEndpoint 参数值形如 ws://<WSL_HOST_IP>:<PORT>/devtools/browser/<UUID> 需要自行组装，其中：

1. <WSL_HOST_IP> 为浏览器实例所在的主机地址。在 NAT 网络模式下，Windows 宿主机的 IP 就是 WSL2 所在虚拟子网的网关。该网关地址在 Windows 网络设置或 WSL 配置不改变的情况下是维持不变的，可以硬编码在 MCP 配置中。Chrome 的 remote debugging server 仅开放给 127.0.0.1 访问（WSL2 通过虚拟子网网关访问时，相当于访问的是 0.0.0.0）。为此，需要配置 portproxy 规则桥接。
2. <PORT> 为浏览器自动分配的 remote debugging 调试端口，Chrome 144+ 一般为 9222。需要开放对应的防火墙端口。
3. <UUID> 由浏览器在启动时自动生成，每次重启发生变化，可以通过访问 %LOCALAPPDATA%\Google\Chrome\User Data\DevToolsActivePort 文本文件获得，文件包含了 <IP> 和 <PORT> 信息。也可以自行编写一个脚本实现刷新。

---

--【拾陆】--：

新版本要怎么做 port forward，可以让服务器上面跑着的 agent 可以使用本地chrome

---

--【拾柒】--：

感谢分享。我实际使用上也是感觉差不多的，就是chrome-devtools会感觉明显的更加费token一些

---

--【拾捌】--： 佩恩:

awesome

佬.我在mac上使用 会打开一个新的chrome.是我用的不对还是本来就是这样?

---

--【拾玖】--：

已经按照佬的办法配置好了~