Codex 新会话每次重连5次 fallback 解决方案在Windows 上的 wss 代理问题：现象、原因与完整解决方案

Codex CLI (Windows) wss 代理超时问题分析与解决方案

在 Windows 环境下运行 Codex CLI 时，终端常会输出以下警告信息：

⚠ Falling back from WebSockets to HTTPS transport. timeout waiting for child process to exit

该提示表明 Codex CLI 从 WebSockets 协议回退到了 HTTPS 传输。通过网络层分析可知，该现象的直接原因在于 Codex CLI 的 wss 流量在应用层未能正确路由至本地代理服务，引发直连超时。

以下为该问题的现象解析、底层逻辑以及相应的解决方案评估。

一、现象解析：wss 连接超时与降级

运行 Codex CLI 时出现的超时报错，其内部执行流程如下：

Codex CLI 默认优先通过 WebSocket (wss://) 与服务端建立实时长连接。
受网络环境限制，wss 直连无法在预定时间内完成握手。
达到超时阈值后，CLI 自动降级，尝试回退使用常规的 HTTPS 轮询机制。
在清理并结束异常子进程时再次触发超时，最终输出 timeout waiting for child process to exit。

若未能确保网络流量被代理规则接管，wss 直连失败将必然触发上述降级流程。

二、成因分析：应用层环境变量的断层

该现象的核心冲突在于：Codex CLI 在 Windows 环境下，其网络栈仅依赖特定环境变量，不会主动读取应用层的“系统代理”（如 Windows 设置中的代理服务器配置）。

具体机制如下：

Codex CLI 的底层网络模块基于 Rust 构建。
该模块在解析代理配置时，严格依赖以下环境变量：
HTTP_PROXY / HTTPS_PROXY：处理 HTTP/HTTPS 协议流量。
ALL_PROXY / all_proxy：处理包括 WebSocket 在内的全局协议流量。
该程序不会读取 Windows 系统设置中的 HTTP/SOCKS 代理或 PAC 脚本。

因此，即使系统代理已开启且浏览器访问正常，若终端环境中缺失 ALL_PROXY 变量，Codex CLI 依然会尝试发起网络直连，导致 wss 连接超时。

三、解决方案评估

解决网络路由问题应遵循“最小作用域与精准控制”原则。以下提供三种可行方案，按工程实践的优雅程度排序。

方案一：使用专属环境文件 `.codex\.env`（首选，作用域独立）

为避免环境变量造成的全局污染，仅针对 Codex CLI 单独配置网络代理是架构上最为整洁的方式。

1. 定位配置文件
在 Windows 操作系统中，Codex CLI 的配置文件固定路径为：（无则创建）

%USERPROFILE%\.codex\.env

2. 写入配置参数
创建或编辑该 .env 文件，添加以下内容（假设本地 SOCKS5 端口为 10808）：

ALL_PROXY=socks5h://127.0.0.1:10808
all_proxy=socks5h://127.0.0.1:10808

配置完成后，后续运行 Codex CLI 时将自动读取该配置，建立稳定的 wss 连接。

方案二：通过系统环境变量配置（全局生效）

此方案适用于需要让终端内所有支持代理环境变量的 CLI 工具统一路由的场景。

在 PowerShell 中执行以下命令：

setx ALL_PROXY "socks5h://127.0.0.1:10808"
setx all_proxy "socks5h://127.0.0.1:10808"

技术说明：使用 socks5h:// 协议头可指示本地不进行 DNS 解析，交由远端代理服务器处理以防污染。执行 setx 后必须重启终端应用程序方可生效。

方案三：启用 Tun 模式虚拟网卡接管（可行，但不推荐）

实现机制：
在代理客户端中开启 Tun 模式（Tun Mode）。该模式通过创建虚拟网卡，在操作系统的网络层（Layer 3）直接拦截并路由所有出站流量。由于拦截发生在底层，绕过了应用层的解析逻辑，Codex CLI 无需配置任何环境变量即可被代理。

局限性与风险评估：
虽能消除 wss 超时报错，但针对单一 CLI 工具的网络连通性问题，采用 Tun 模式是一种缺乏优雅性的“一刀切”式妥协手段。强制接管全局底层流量不仅会产生额外的网络性能开销，且极易引发复杂的环境冲突（特别是与 WSL、Docker 或其他依赖虚拟网卡的开发组件）。因此，除非具备明确的全局网络路由需求，通常不推荐将此作为首选解决方案。