1 问题现象
2026 年 9 月，我在使用 Codex 桌面端的 Browser / Computer Use 功能时，遇到过一个比较特殊的网络问题：普通网页访问和常规代理连接基本正常，但相关自动化能力无法正常发起网络请求。
当时出现的错误是：
nodeRepl.fetch request failed
这类报错很容易让人先怀疑 Codex 本身、浏览器环境或服务端状态。不过，我当时使用的是 Clash Verge 的代理环境，问题也可能出在应用流量的转发方式上。
2 排查思路
代理客户端通常提供系统代理和 TUN 两种不同的接管方式。
- 系统代理：主要通过系统代理设置，让遵循系统代理配置的应用转发流量
- TUN 模式：通过虚拟网络接口接管更广泛的网络流量，覆盖部分不读取系统代理设置的应用或进程
桌面应用中的自动化组件不一定与普通浏览器采用相同的网络请求路径。即使浏览器已经可以通过系统代理访问网页，也不能据此判断 Browser / Computer Use 使用的所有网络请求都已被代理接管。
3 实际解决方式
我当时使用的代理配置并非 TUN 模式。排查后，直接在 Clash Verge 中开启 TUN 模式，再重新测试 Codex 的 Browser / Computer Use，相关功能便恢复正常。
这次问题的处理过程可以概括为：
- 确认普通网络和代理节点本身可用
- 检查 Clash Verge 当前是否只开启了系统代理
- 开启 TUN 模式
- 重新发起 Codex Browser / Computer Use 请求
- 确认原来的
nodeRepl.fetch request failed不再出现
这只是我当时设备与网络环境下验证有效的解决办法，不代表所有 Codex 网络异常都需要开启 TUN。
4 如果仍然失败
可以按下面的顺序缩小范围：
- 先确认代理节点本身能够正常访问目标服务
- 检查 Clash Verge 的运行状态、系统代理和 TUN 状态
- 检查系统防火墙或安全软件是否拦截相关进程
- 切换网络后重新启动代理客户端，再测试自动化请求
- 如果普通浏览器正常而自动化请求仍失败，再进一步检查应用自身的网络环境
不建议一开始就反复重装 Codex 或重置全部代理配置。先区分“普通浏览器流量”和“自动化组件流量”，通常更容易定位问题。
5 总结
这次排查最有价值的地方，是意识到系统代理可用，不代表应用中的每一个网络组件都能自动使用它。
对于 Browser、Computer Use 或其他桌面自动化功能，网络请求可能来自独立进程或运行环境。遇到类似的 fetch 错误时，除了检查服务状态，也应该确认代理接管范围是否覆盖了实际发起请求的组件。