执行 codex 命令超时需分三步排查：先用 curl -v 模拟请求确认是否发出；再通过 debug 日志或 tcpdump 抓包验证 node.js 客户端行为；最后用 time、代理对比和 --insecure 测试定位超时环节。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你执行 codex 命令后卡住几秒直接报 Error: Request timeout exceeded 30000ms，无法判断是请求根本没发出去，还是发出去了但服务端没响应——这种不确定性会浪费大量排查时间。
用 curl 模拟 Codex 请求头验证是否发出
第一步：从 Codex 配置中提取关键参数
打开 ~/.codex/config.toml，找到 [model_providers.xxx] 段落，记下 base_url（如 https://api.openai.com/v1）、env_key 对应的环境变量名（如 OPENAI_API_KEY），以及实际生效的 model（如 gpt-4o）。
第二步：构造等效 curl 命令
在终端运行：curl -v -X POST "$BASE_URL/chat/completions" \-H "Authorization: Bearer $OPENAI_API_KEY" \-H "Content-Type: application/json" \--data '{"model":"gpt-4o","messages":[{"role":"user","content":"hi"}]}' \
注意：必须用 -v 参数，否则看不到请求发出的明确证据。
第三步：观察 curl 输出首行
如果看到 * Trying x.x.x.x:443... 或 * Connected to api.openai.com (x.x.x.x) port 443 (#0)，说明请求已发出；若卡在 DNS 解析或直接报 Could not resolve host，则请求根本未离开本地。
检查 Node.js HTTP 客户端真实行为
方法一：启用 Codex 内置调试日志
执行命令前先设置：export DEBUG=codex:client,codex:http
再运行 codex "test"。日志中出现 HTTP POST /chat/completions 表示请求已构造并交由底层 client 发出；若只看到 starting request 就中断，说明卡在 DNS 或 TLS 握手阶段。
方法二：抓包确认流量出口
在另一终端运行：sudo tcpdump -i any -A -s 0 'tcp port 443 and (host api.openai.com or host apikey.quest)' | grep -i 'post\|host:'
执行 codex 命令后，若抓包窗口立即出现 POST /v1/chat/completions 和 Host: api.openai.com 字样，证明请求确实发出；若全程静默，则问题在应用层之前。
区分超时发生在哪一环节
① 运行：time curl -I --max-time 5 https://api.openai.com/v1/models 2>&1 | grep real
记录耗时。若超过 5 秒才报超时，说明 DNS 或 TCP 连接本身慢；若不到 1 秒就失败，说明是服务端拒绝或防火墙拦截。
② 对比测试：
用相同代理配置运行：HTTPS_PROXY=http://127.0.0.1:7890 curl -v https://api.openai.com/v1/models
和HTTPS_PROXY=http://127.0.0.1:7890 codex list
如果 curl 成功而 codex 失败，【说明 Codex 的 HTTP 客户端配置（如 timeout、keep-alive）与你的代理不兼容】，不是网络不通。
③ 检查是否被中间设备截断
执行：curl -v --insecure https://api.openai.com/v1/models 2>&1 | grep -E "(Connected|SSL handshake)"
若出现 SSL handshake has read 0 bytes，表明 TLS 握手被企业防火墙或 DPI 设备主动中断，此时请求虽发出但被半路掐断。
