[Bug]: 浏览器控制无法连接 Chrome 136+ 默认配置文件:/json/version 返回 404,一直 Request timeout

Fermée
#3,654 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
devtools, rust
Domaine
desktop, networking

Piste de recherche

The payload names no source files. Start by finding where the app discovers the DevTools endpoint, which calls /json/version and /json/list on 127.0.0.1:9222. Reproduce with curl against a Chrome 136+ instance that has remote debugging enabled, and confirm that /devtools/browser completes a WebSocket handshake. Done means discovery succeeds on that Chrome build, either by falling back to the browser WebSocket or by reading the DevToolsActivePort file, and a maintainer confirms the approach first because the report offers several options.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

环境:macOS(Apple Silicon),OpenBitFun 1.0.8 桌面版,Chrome 156 稳定版,默认配置文件已登录。

复现步骤:

  1. 设置 → 浏览器控制 → 点击启用/连接。
  2. 浏览器自动打开 chrome://inspect/#remote-debugging,勾选「Allow remote debugging for this browser instance」,页面显示服务已在 127.0.0.1:9222 监听。
  3. 回到 OpenBitFun 再次连接。约 2 分钟内重试 6 次,全部失败。

结果:每次都提示 Request timeout,但浏览器始终在 9222 上监听,CDP 的 WebSocket 端点也完全正常。

关键证据:HTTP 发现接口返回 404,而 WebSocket 可用。

GET /json/version   -> 404, Content-Length: 0
GET /json/list      -> 404, Content-Length: 0
/json、/json/new、/json/protocol 同样返回 404

手工向 /devtools/browser 发起 WebSocket 握手 -> 101 WebSocket Protocol Handshake
Browser.getVersion    -> protocolVersion 1.3, product Chrome/156.0.8078.74
Target.getTargets     -> 返回 19 个页面目标
Target.attachToTarget -> 正常返回 sessionId

推测原因:CDP 发现流程只请求上述 HTTP 接口。Chrome 144+ 的这种受控远程调试模式会有意不再提供 /json* 接口,于是发现阶段拿到 404,连接一直等到超时。

次要问题:该模式下 WebSocket 握手存在偶发卡顿(部分尝试超过 6 秒无响应),即使修好协议,固定的短超时也可能偏紧。

建议修复:

  1. 当 /json/version 返回 404 时,回退为直接连接 ws://127.0.0.1:{端口}/devtools/browser,改用 Browser.getVersion 与 Target.getTargets 完成发现。
  2. 或者从浏览器用户数据目录下的 DevToolsActivePort 文件中解析出浏览器 WebSocket 路径。
  3. 针对该受控模式,为 WebSocket 握手增加带退避的重试。

影响:在当前的 Chrome 稳定版上,浏览器控制完全无法接入用户的真实配置文件,现有标签页和登录状态都用不了。应用内「重启浏览器并连接」也无效,因为 Chrome 136+ 对默认配置文件会忽略远程调试相关启动参数。

隐私说明:本报告不含任何账号标识、文件路径、工作区数据或其他个人信息。

Area

Desktop app

Reproduction or evidence

复现步骤:

  1. 设置 → 浏览器控制 → 点击启用/连接。
  2. 浏览器自动打开 chrome://inspect/#remote-debugging,勾选「Allow remote debugging for this browser instance」,页面显示服务已在 127.0.0.1:9222 监听。
  3. 回到 OpenBitFun 再次连接。约 2 分钟内重试 6 次,全部失败。
Environment, if relevant

OpenBitFun 版本:1.0.8(桌面版,官方安装包)
操作系统:macOS 27.2,Apple Silicon(arm64)
浏览器/设备:Google Chrome 156.0.8078.74 稳定版,默认配置文件,已通过 chrome://inspect 启用远程调试
模型/服务商:与该问题无关

Langage dominant
Rust
Étoiles
2.3k
Forks
236
Merge moyen
13 h 23 min
PR mergées (30 j)
333

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de GCWing/OpenBitFun

Toutes les issues de GCWing/OpenBitFun

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.