问题现象
使用 Windows 版 Codex 桌面应用连接外部 Chrome 时，能够在聊天中选择浏览器标签页，但实际读取页面时报错：
nodeRepl.fetch request failed本文记录一次实际排查与恢复过程。最终在现有网络工具中开启 TUN 模式后，Chrome 标签页列表和页面内容恢复读取。这个结果仅代表本次环境验证通过，不是所有同类报错的通用结论。
一、先确认失败发生在哪一步
最初，浏览器工具能够识别 Chrome 扩展的连接记录，却无法列出标签页。同一次检查中，两个 Edge 扩展连接也出现了相同错误。
这个现象提示：问题可能位于多个浏览器共用的连接链路，不能只根据一句报错就判断扩展损坏、账号失效或者需要重装。
二、哪些操作尝试过，但没有恢复
排查中确认了本机浏览器插件文件存在，桌面应用使用自带的 Node 运行时，版本为 v24.21.0。因此，在本次环境里，没有证据表明需要重新安装系统 Node。
随后重置浏览器工具运行时、重新测试连接，并完全退出和重新打开 Codex 桌面应用。这些操作后，读取标签页仍然失败。
重启后的新日志显示，本机 local app-server 已连接，而远端 durable WebSocket 多次在连接建立前关闭。这是继续检查网络连通性的线索，但不能直接把远端日志当成浏览器报错的完整根因。
三、关键发现：不同连接路径的结果不同
对应用使用的远端服务地址进行基础连通性测试时，直连请求在限定时间内超时；通过电脑上已经配置的本地 HTTP 代理发起请求，则能够收到 HTTP 响应。
需要区分"收到响应"和"功能可用"：测试返回 HTTP 403，只能说明该路径收到了服务器响应，不能证明接口鉴权成功，也不能证明浏览器控制已经恢复。
当时 代理工具 已开启系统代理，使用规则模式，但 TUN 模式关闭。结合这些结果，下一步选择临时开启 TUN，让未使用系统代理设置的连接也有机会使用当前网络路径，再进行实际功能验证。
四、实际有效的处理与验证
- 保持当前已配置的网络工具和连接节点。
- 在 代理工具 中开启 TUN／虚拟网卡模式。
- 回到 Codex，重新请求 Chrome 标签页列表。
- 选择之前失败的百度搜索标签页，读取页面内容。
这次标签页列表成功返回，原页面的搜索框、搜索结果和链接也能正常读取，没有再出现 nodeRepl.fetch request failed。至此，可以确认本次浏览器连接在 TUN 开启状态下恢复。
TUN 会影响其他应用的网络流量，测试前应了解其作用范围；它不是每个人都需要开启的选项。关闭 TUN 后是否仍能正常连接，本次没有验证。
五、这次排查可以得到什么结论
本次有效措施是开启现有网络工具的 TUN 模式，结果与网络路径覆盖不足的判断相符。不过，尚未取得最初失败请求的完整底层 cause，因此不能进一步断言是哪一个内部组件忽略了系统代理。
整个过程中没有修改 API 密钥、登录凭据、模型名称或安全校验设置，也没有删除插件缓存。没有对应日志证据时，不建议把这些操作作为固定步骤。
六、遇到同类问题时的排查顺序
- 记录完整错误和发生步骤，区分识别浏览器、列出标签页、读取页面三个阶段。
- 检查插件和扩展是否存在、启用，以及桌面应用实际使用的运行时。
- 先重置运行时或重启应用，再做一次功能复测。
- 检查近期日志中的底层错误，并比较现有网络路径的连通性。
- 只调整有证据支持的设置，每次调整后用原来失败的页面验证。
如果日志明确出现本地端口连接被拒绝、登录失效或文件锁错误，应按对应分支处理。本文的网络调整方法不能替代这些问题各自的诊断。
参考与说明
排查时参考了以下社区资料，本文的步骤与结果来自本次实际测试：