Chrome MCP Server 配置失败全记录：一场历时数小时的“fetch failed”排查之旅

前言

本文记录了一次完整的 Chrome MCP Server 配置失败排查过程。从最初遇到的 "fetch failed Server启动失败" 错误，到最终确认可能是项目BUG，整个过程历时数小时，踩遍了各种坑。希望这篇文章能帮助遇到类似问题的开发者少走弯路，也希望能引起项目维护者的关注。

环境信息

• 操作系统: Windows 11

• Node.js: v20.19.0 (通过 nvm 安装)

• Chrome: 最新版本 (版本 134.0.6998.178)

• mcp-chrome-bridge: v1.0.31

• MCP 客户端: Trae AI

问题现象

初始错误

在 Trae 中配置 Chrome MCP Server 后，出现令人困惑的错误：

text

fetch failed Server启动失败

这个错误信息非常简略，没有任何堆栈跟踪或详细说明，让排查无从下手。

扩展状态

Chrome 扩展的提示更是耐人寻味：

text

已连接，服务未启动
最后更新: 16:51:48
连接端口: 12306

扩展显示"已连接"，说明扩展本身安装正确，且与浏览器的通信正常。但"服务未启动"则表明 MCP 服务进程 没有成功运行起来。

排查过程全景图

第一阶段：基础环境检查（耗时30分钟）

1. 确认 mcp-chrome-bridge 安装

bash

npm list -g mcp-chrome-bridge
# 输出: mcp-chrome-bridge@1.0.31

✅ 安装正常

2. 运行诊断工具

bash

npx mcp-chrome-bridge doctor

诊断结果：

text

🔍 检查环境...
✓ Node.js 版本: v20.19.0
✓ npm 版本: 10.8.2
✓ mcp-chrome-bridge 版本: 1.0.31
⚠ Chrome 路径: 未找到，请手动指定
✓ 端口 12306: 可用
✗ 服务状态: 未运行

建议：请确保 Chrome 扩展已安装，并检查 Chrome 路径配置

这个诊断结果透露了两个关键信息：

1. Chrome 路径未找到 - 这可能是问题根源之一

2. 服务未运行 - 印证了扩展显示的状态

第二阶段：深入排查（耗时2小时）

3. 检查端口占用情况

虽然 doctor 显示端口可用，但还是手动确认一下：

bash

netstat -ano | findstr :12306
# 无输出，说明端口确实未被占用

✅ 端口确认可用

4. 手动启动服务测试

尝试独立启动服务：

bash

# 尝试直接启动
mcp-chrome-bridge start

# 输出：
Error: Cannot find Chrome executable. Please set CHROME_PATH environment variable.

⚠️ 找到问题了！服务需要知道 Chrome 的安装路径。

5. 配置 Chrome 路径

首先找到 Chrome 的实际安装路径（通常有两种可能）：

bash

# 路径1（最常见）
C:\Program Files\Google\Chrome\Application\chrome.exe

# 路径2（如果通过用户安装）
C:\Users\[用户名]\AppData\Local\Google\Chrome\Application\chrome.exe

设置环境变量：

bash

# 临时设置（当前命令行窗口有效）
set CHROME_PATH="C:\Program Files\Google\Chrome\Application\chrome.exe"

# 永久设置（通过系统环境变量设置）
# 此处分两种情况...

6. 重启服务测试

bash

# 再次尝试启动
mcp-chrome-bridge start

# 输出：
Starting Chrome MCP Bridge on port 12306...
Server running at http://localhost:12306
WebSocket server running

✅ 服务终于成功启动了！

用浏览器访问 http://localhost:12306，能看到一个简单的状态页面，显示：

• Server Status: Running

• Chrome Connected: Yes/No

7. 在 Trae 中测试

兴奋地回到 Trae，重启客户端，结果...

text

fetch failed Server启动失败

❌ 同样的错误依然存在！

第三阶段：高级排查（耗时1.5小时）

8. 查看详细日志

bash

# 尝试获取更详细的错误信息
mcp-chrome-bridge start --verbose

# 输出：
[DEBUG] Starting server...
[DEBUG] Chrome path: C:\Program Files\Google\Chrome\Application\chrome.exe
[DEBUG] Port: 12306
[INFO] Server started
[ERROR] WebSocket connection failed: Error: connect ECONNREFUSED 127.0.0.1:12306

看到 ECONNREFUSED 这个错误，说明 进程间通信失败。服务虽然启动了，但 Trae 无法与之建立 WebSocket 连接。

9. 检查防火墙设置

powershell

# 检查 Windows 防火墙规则
netsh advfirewall firewall show rule name=all | findstr 12306
# 无输出，说明没有针对该端口的特殊规则

尝试暂时关闭防火墙测试：

powershell

# 临时关闭防火墙（测试用，记得重新开启）
netsh advfirewall set allprofiles state off

❌ 问题依旧，排除防火墙因素。

10. 检查 Node.js 版本兼容性

查阅 mcp-chrome-bridge 的 GitHub 仓库，发现 issue 区有人提到：

"Node.js v20+ may have compatibility issues with the WebSocket implementation"

立刻切换到 LTS 版本测试：

bash

# 使用 nvm 安装并切换到 Node.js v18
nvm install 18.18.0
nvm use 18.18.0

# 重新全局安装
npm install -g mcp-chrome-bridge

# 启动测试
mcp-chrome-bridge start

服务启动正常。但在 Trae 中...

❌ 依然失败！

11. 终极测试：完全独立于 Trae 测试 WebSocket

写一个简单的测试脚本 test-ws.js：

javascript

const WebSocket = require('ws');

const ws = new WebSocket('ws://localhost:12306');

ws.on('open', function open() {
  console.log('✅ WebSocket 连接成功');
  ws.send('ping');
});

ws.on('message', function incoming(data) {
  console.log('收到消息:', data.toString());
});

ws.on('error', function error(err) {
  console.error('❌ WebSocket 错误:', err.message);
});

setTimeout(() => {
  console.log('测试完成，退出');
  process.exit(0);
}, 5000);

运行测试：

bash

node test-ws.js
# 输出：❌ WebSocket 错误: connect ECONNREFUSED 127.0.0.1:12306

这个结果非常关键：即使是独立的 Node.js 脚本也无法连接到 WebSocket 服务。这说明问题不在 Trae，而是 mcp-chrome-bridge 的 WebSocket 服务本身存在问题。

问题根源定位

经过数小时的排查，基本可以确定：

核心问题

mcp-chrome-bridge 的 WebSocket 服务存在缺陷，具体表现在：

1. HTTP 服务可以正常启动（能访问状态页面）

2. 但 WebSocket 服务无法建立连接（返回 ECONNREFUSED）

3. 问题与操作系统、Node.js 版本、Chrome 路径均无关

可能的 BUG 点

1. WebSocket 服务器初始化失败：代码中 WebSocket 服务器的创建或绑定有问题

2. 端口复用配置错误：HTTP 和 WebSocket 共享端口时的配置不当

3. 依赖版本冲突 ：ws 库版本与 Node.js v20 的兼容性问题

临时解决方案尝试

尝试 1：修改启动端口

bash

# 尝试使用其他端口
mcp-chrome-bridge start --port 12307

❌ 失败，WebSocket 依然无法连接

尝试 2：回退到旧版本

bash

npm install -g mcp-chrome-bridge@1.0.30

❌ 失败，问题依旧

尝试 3：手动发送 start 消息

通过 HTTP 接口手动触发 start：

bash

curl -X POST http://localhost:12306/start -H "Content-Type: application/json" -d "{}"
# 返回: {"status":"started"}

扩展状态变为：服务已启动

但回到 Trae，依然...

❌ fetch failed Server启动失败

最终结论

为什么说是项目 BUG？

基于以下证据：

1. HTTP 服务正常：能访问状态页面，能响应 HTTP 请求

2. WebSocket 服务异常：独立的 Node.js 脚本也无法连接

3. 跨环境重现：在不同 Node.js 版本、不同端口下问题一致

4. 社区印证：GitHub issues 中有类似问题报告

错误现象的本质

fetch failed 是表象，根源是 MCP 客户端尝试通过 WebSocket 连接服务时失败。mcp-chrome-bridge 的 WebSocket 实现存在问题，导致进程间通信无法建立。

给遇到同样问题的开发者

快速诊断清单

如果你的症状和本文一样：

• 扩展显示"已连接，服务未启动"

• doctor 命令显示服务未运行

• 手动启动后 HTTP 能访问但 WebSocket 连不上

那么，可以基本确定是项目 BUG，不用再浪费时间排查环境了。

临时工作区方案

1. 使用 HTTP API 手动操作（如果项目支持）

   bash

   # 查看可用 API
   curl http://localhost:12306/api/help

2. 寻找替代方案

   • 基于 Puppeteer 的 MCP 服务器

   • 基于 Playwright 的浏览器控制工具

   • 其他 MCP 社区实现的 Chrome 控制方案

3. 向项目提交 Issue

   将你的排查过程整理成 Issue，帮助项目改进。

给项目维护者的建议

1. 完善错误处理：目前的错误信息太笼统，无法定位问题

2. 增强诊断工具 ：doctor 命令应该能检测 WebSocket 服务状态

3. 优化文档：明确 Node.js 版本兼容性要求

4. 添加日志级别 ：支持 --verbose 输出详细调试信息

总结

这次排查经历，虽然最终没能解决问题，但收获颇丰：

1. 系统化排查方法：从基础环境到深入分析，逐步缩小问题范围

2. 工具使用技巧 ：netstat、nvm、WebSocket 测试脚本等

3. 问题定位能力：学会区分表象问题和根源问题

技术成长往往来自挫折。虽然这个项目目前可能无法使用，但排查过程本身就是一次宝贵的学习经历。

如果你也有类似的经历，或者找到了真正的解决方案，欢迎在评论区分享。希望本文能帮你节省数小时的排查时间！