问题概述 Reqable MCP Server 无法读取实时抓包数据。默认配置读取到的端口是 9000,该端口可以正常作为 HTTP 代理使用,但访问 MCP 所需的 API 路由时,Reqable 会直接关闭连接,不返回 HTTP 响应。
环境信息
系统:Windows
Reqable 安装路径:C:\Program Files\Reqable
MCP Server 路径:C:\Program Files\Reqable\mcp-server.exe
MCP Server 版本:开源仓库中显示为 1.0.0
Reqable 配置文件路径: C:\Users\Administrator\AppData\Roaming\Reqable\config\capture_config
相关配置内容:
{
"proxyPort": 9000,
"autoCapture": true,
"proxyLoopback": true,
"proxySystem": true
}
MCP 配置 Kilo 中的 MCP 配置如下:
{
"mcp": {
"reqable": {
"type": "local",
"command": ["cmd", "/c", "C:\Program Files\Reqable\mcp-server.exe"],
"enabled": true
}
}
}
也测试过显式指定端口:
"command": ["cmd", "/c", "C:\Program Files\Reqable\mcp-server.exe", "--port", "9000"]
结果相同。
实际现象 Reqable 正在运行,并且监听 9000 端口。
9000 端口作为 HTTP 代理可以正常使用。下面命令可以成功返回 Example Domain 页面:
curl.exe -x http://127.0.0.1:9000 --max-time 15 http://example.com/
但是访问同一端口上的 MCP API 路由会失败。
执行:
curl.exe -v http://127.0.0.1:9000/capture/live/status -H "User-Agent: reqable-mcp/1.0.0"
返回:
- Trying 127.0.0.1:9000...
- Connected to 127.0.0.1 (127.0.0.1) port 9000
GET /capture/live/status HTTP/1.1
Host: 127.0.0.1:9000
Accept: /
User-Agent: reqable-mcp/1.0.0
- Request completely sent off
- Empty reply from server
- Closing connection
curl: (52) Empty reply from server
在 MCP 工具中调用 capture_live_status 时,错误为:
HttpException: Connection closed before full header was received, uri = http://127.0.0.1:9000/capture/live/status
调用 live capture filter 也失败:
curl.exe -v http://127.0.0.1:9000/capture/live/filter -H "User-Agent: reqable-mcp/1.0.0"
-H "Content-Type: application/json" `
--data-raw "{"filters":[]}"
结果同样是:
Empty reply from server
MCP 工具中的错误为:
HttpException: Connection closed before full header was received, uri = http://127.0.0.1:9000/capture/live/filter
预期行为 根据开源项目源码,MCP Server 会直接向 Reqable API endpoint 发送 HTTP 请求。
lib/tools/capture/live.dart 中定义了这些路由:
GET /capture/live/status
GET /capture/live/on
GET /capture/live/off
POST /capture/live/filter
POST /capture/live/get
lib/config.dart 中,当未指定 --port 时,会读取:
%APPDATA%\Reqable\config\capture_config
并使用其中的:
proxyPort
在当前环境中,proxyPort 是 9000。
因此预期:
http://127.0.0.1:9000/capture/live/status
应该返回有效的 JSON 状态数据,而不是直接关闭连接。
额外发现 Reqable 还监听了另一个本地端口 12310。
执行:
curl.exe -v http://127.0.0.1:12310/capture/live/status
返回的是标准 HTTP 响应:
HTTP/1.1 400 Bad Request
content-type: text/plain; charset=utf-8
content-length: 0
曾临时将 MCP 配置为:
"command": ["cmd", "/c", "C:\Program Files\Reqable\mcp-server.exe", "--port", "12310"]
此时 MCP 调用不再出现 Connection closed before full header was received,但 live capture 查询返回空记录。因此不确定 12310 是否是内部 API 端口,或者只是另一个无关服务。
需要确认的问题
Reqable MCP API 是否应该和 HTTP 代理共用 proxyPort,也就是当前的 9000?
如果应该共用 9000,为什么代理流量可以正常工作,但 /capture/live/status、/capture/live/filter 等 MCP API 路由会直接关闭连接?
如果不应该共用 9000,reqable-mcp-server 应该如何发现正确的 Reqable API 端口?
是否需要在 Reqable UI 中开启某个 MCP/API/AI Agent/自动化相关开关后,/capture/live/* 路由才会可用?
最小复现步骤
启动 Reqable。
确认 %APPDATA%\Reqable\config\capture_config 中 proxyPort 为 9000。
确认代理可用:
curl.exe -x http://127.0.0.1:9000 --max-time 15 http://example.com/
测试 MCP live capture API:
curl.exe -v http://127.0.0.1:9000/capture/live/status -H "User-Agent: reqable-mcp/1.0.0"
实际结果为:
Empty reply from server
预期结果应为 live capture 状态 JSON。
问题概述 Reqable MCP Server 无法读取实时抓包数据。默认配置读取到的端口是 9000,该端口可以正常作为 HTTP 代理使用,但访问 MCP 所需的 API 路由时,Reqable 会直接关闭连接,不返回 HTTP 响应。
环境信息
系统:Windows
Reqable 安装路径:C:\Program Files\Reqable
MCP Server 路径:C:\Program Files\Reqable\mcp-server.exe
MCP Server 版本:开源仓库中显示为 1.0.0
Reqable 配置文件路径: C:\Users\Administrator\AppData\Roaming\Reqable\config\capture_config
相关配置内容:
{
"proxyPort": 9000,
"autoCapture": true,
"proxyLoopback": true,
"proxySystem": true
}
MCP 配置 Kilo 中的 MCP 配置如下:
{
"mcp": {
"reqable": {
"type": "local",
"command": ["cmd", "/c", "C:\Program Files\Reqable\mcp-server.exe"],
"enabled": true
}
}
}
也测试过显式指定端口:
"command": ["cmd", "/c", "C:\Program Files\Reqable\mcp-server.exe", "--port", "9000"]
结果相同。
实际现象 Reqable 正在运行,并且监听 9000 端口。
9000 端口作为 HTTP 代理可以正常使用。下面命令可以成功返回 Example Domain 页面:
curl.exe -x http://127.0.0.1:9000 --max-time 15 http://example.com/
但是访问同一端口上的 MCP API 路由会失败。
执行:
curl.exe -v http://127.0.0.1:9000/capture/live/status -H "User-Agent: reqable-mcp/1.0.0"
返回:
curl: (52) Empty reply from server
在 MCP 工具中调用 capture_live_status 时,错误为:
HttpException: Connection closed before full header was received, uri = http://127.0.0.1:9000/capture/live/status
调用 live capture filter 也失败:
curl.exe -v http://127.0.0.1:9000/capture/live/filter
-H "User-Agent: reqable-mcp/1.0.0"-H "Content-Type: application/json" `
--data-raw "{"filters":[]}"
结果同样是:
Empty reply from server
MCP 工具中的错误为:
HttpException: Connection closed before full header was received, uri = http://127.0.0.1:9000/capture/live/filter
预期行为 根据开源项目源码,MCP Server 会直接向 Reqable API endpoint 发送 HTTP 请求。
lib/tools/capture/live.dart 中定义了这些路由:
GET /capture/live/status
GET /capture/live/on
GET /capture/live/off
POST /capture/live/filter
POST /capture/live/get
lib/config.dart 中,当未指定 --port 时,会读取:
%APPDATA%\Reqable\config\capture_config
并使用其中的:
proxyPort
在当前环境中,proxyPort 是 9000。
因此预期:
http://127.0.0.1:9000/capture/live/status
应该返回有效的 JSON 状态数据,而不是直接关闭连接。
额外发现 Reqable 还监听了另一个本地端口 12310。
执行:
curl.exe -v http://127.0.0.1:12310/capture/live/status
返回的是标准 HTTP 响应:
HTTP/1.1 400 Bad Request
content-type: text/plain; charset=utf-8
content-length: 0
曾临时将 MCP 配置为:
"command": ["cmd", "/c", "C:\Program Files\Reqable\mcp-server.exe", "--port", "12310"]
此时 MCP 调用不再出现 Connection closed before full header was received,但 live capture 查询返回空记录。因此不确定 12310 是否是内部 API 端口,或者只是另一个无关服务。
需要确认的问题
Reqable MCP API 是否应该和 HTTP 代理共用 proxyPort,也就是当前的 9000?
如果应该共用 9000,为什么代理流量可以正常工作,但 /capture/live/status、/capture/live/filter 等 MCP API 路由会直接关闭连接?
如果不应该共用 9000,reqable-mcp-server 应该如何发现正确的 Reqable API 端口?
是否需要在 Reqable UI 中开启某个 MCP/API/AI Agent/自动化相关开关后,/capture/live/* 路由才会可用?
最小复现步骤
启动 Reqable。
确认 %APPDATA%\Reqable\config\capture_config 中 proxyPort 为 9000。
确认代理可用:
curl.exe -x http://127.0.0.1:9000 --max-time 15 http://example.com/
测试 MCP live capture API:
curl.exe -v http://127.0.0.1:9000/capture/live/status -H "User-Agent: reqable-mcp/1.0.0"
实际结果为:
Empty reply from server
预期结果应为 live capture 状态 JSON。