最近把代理服务器 IP 换了下，从 192.168.0.13 换成了 192.168.0.170，在远端 Linux 上用 Codex CLI 走新服务器的 HTTP 代理，遇到报错：

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

export RUST_LOG=trace 打开 trace 级别日志后，查看 ~/.codex/log/codex-tui.log，发现它竟然去连旧代理 192.168.0.13:7890，并报 Host is unreachable

最诡异的是：我检查运行中的 codex 进程环境变量，里面完全看不到旧代理。
这里我采用了原来帖子里处理 codex VSCode 插件的方法直接添加了代理所以看不到原来的旧代理:

#!/usr/bin/env bash set -euo pipefail

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

PROXY="http://192.168.0.170:7890" export http_proxy="$PROXY" export https_proxy="$PROXY" export all_proxy="$PROXY" export HTTP_PROXY="$PROXY" export HTTPS_PROXY="$PROXY" export ALL_PROXY="$PROXY" export NO_PROXY="localhost,127.0.0.1,::1" export no_proxy="$NO_PROXY" # 用于确认 VS Code/CLI 实际有没有跑到这个 wrapper env | grep -i _proxy > "/tmp/codex-proxy-env.$$.txt"

HERE="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)" exec "$HERE/codex.real" "$@" 

1）我怎么确认 “进程 environ 里没有旧代理”

我用下面命令抓 codex 相关进程的环境变量：

查看 codex 进程对应的环境变量

for p in $(pgrep -af codex | awk '{print $1}'); do echo "=== PID $p exe=$(readlink -f /proc/$p/exe 2>/dev/null) ===" tr '\0' '\n' < /proc/$p/environ 2>/dev/null | grep -iE '(^|_)proxy=' || true done 

输出看起来代理都是统一的（只有新代理 192.168.0.170）：

=== PID 1703340 exe=/home/user/.vscode-server/extensions/openai.chatgpt-0.4.62-linux-arm64/bin/linux-aarch64/codex.real ===
HTTPS_PROXY=http://192.168.0.170:7890
HTTP_PROXY=http://192.168.0.170:7890
=== PID 1713620 exe=/home/user/.local/node/bin/node ===
no_proxy=localhost,127.0.0.1,::1
https_proxy=http://192.168.0.170:7890
NO_PROXY=localhost,127.0.0.1,::1
HTTPS_PROXY=http://192.168.0.170:7890
HTTP_PROXY=http://192.168.0.170:7890
http_proxy=http://192.168.0.170:7890
ALL_PROXY=http://192.168.0.170:7890
all_proxy=http://192.168.0.170:7890
=== PID 1713631 exe=/home/user/.local/node/lib/node_modules/@openai/codex/vendor/aarch64-unknown-linux-musl/codex/codex ===
no_proxy=localhost,127.0.0.1,::1
https_proxy=http://192.168.0.170:7890
NO_PROXY=localhost,127.0.0.1,::1
HTTPS_PROXY=http://192.168.0.170:7890
HTTP_PROXY=http://192.168.0.170:7890
http_proxy=http://192.168.0.170:7890
ALL_PROXY=http://192.168.0.170:7890
all_proxy=http://192.168.0.170:7890

2) 但 trace 日志里仍然出现旧代理

我开启 trace：

追踪 codex 执行的日志

export RUST_LOG=trace
codex

然后在～/.codex/log/codex-tui.log 里看到它尝试连接旧代理 192.168.0.13:7890（典型是 reqwest /hyper 的 connect error）。

3) 最终根因：~/.codex/.env 里残留了旧代理

看了下常规的～/.bashrc , /etc/bash.bashrc 都没有老代理的影子，使用才最残暴的 sudo grep -nri 192.168.0.13 /* 暴力搜索所有文件夹下包含老代理的 IP。最后发现我以前在～/.codex/.env 里写过旧的 http_proxy/https_proxy，后来忘了删。。。。删除后，问题解决。

4) 经验总结

只看 /proc/$PID/environ 可能会被误导：即便进程环境里已经是新代理，codex-tui.log 仍可能暴露 “.env 残留的旧代理”。这时候一定要善用 export RUST_LOG=trace 来观察 codex 运行日志。

有些时候我们需要开发调试修改 HTTP 的 Header (例如 User-Agent)，UA3F 可以做到对客户端无感的透明重写。

UA3F 作为一个 HTTP 、SOCKS5 、TPROXY 、REDIRECT 、NFQUEUE 代理服务对 HTTP/1.1 请求 Header 进行透明重写。

UA3F 还可以自定义重写规则，根据匹配条件的不同进行不同行为的重写:
匹配规则类型支持：KEYWORD 、REGEX 、DEST-PORT 、SRC-IP 、IP-CIDR
重写策略支持：DELETE 、REPLACE 、REPLACE-PART 、DROP
后续会有更多规则加入。

[bsgit user="SunBK201"]UA3F[/bsgit]