Codex怎么把中转站删了

很多人一开始图省事把 Codex 指到了中转站，后来想换回官方、或者干脆不想用了，结果发现改回配置还是往旧地址发请求——多半是环境变量没清、或者好几个配置文件里各留了一份。这篇不讲怎么选站，只讲怎么删干净：先找出所有写死中转地址的地方，再按顺序清掉，最后跑一遍验证确认没有残留。

很多人一开始图省事，把 Codex 这类命令行工具指到了中转站，后来想换回官方、或者干脆不想用了，结果改回配置发现请求还是往旧地址发。问题基本不在工具本身，而是中转地址被写进了好几个地方，你只改了看得见的那一处。这篇只讲一件事：怎么把中转配置和残留环境变量清干净。

思路很直白，分三步走。先找出所有写死中转地址的位置，再按优先级从高到低依次删掉，最后开个干净终端跑一遍验证。中间任何一步偷懒，都可能留下一个还在生效的旧地址。

先搞清楚中转配置可能藏在哪几个地方

这类工具读配置是有顺序的：命令行参数优先级最高，往下是环境变量、用户级配置文件、项目级配置文件。顺序在前的会把后面的覆盖掉。所以你只改了配置文件，环境变量还指着一手中转地址，那自然还是走中转。先把读取顺序理清楚，再动手删，不然就是白忙。

1. 第一步：列出环境变量在终端里用 printenv 或 echo，把变量名里带 base url、api key、proxy、openai 字样的全部打印一遍。有输出就记下来，这是最容易被忽略的一层。
2. 第二步：全局搜旧域名在项目目录和用户配置目录里搜中转站的旧域名，把命中的文件路径记下来。两个结果对上了，才算把可能的位置找全。
3. 第三步：检查别名和函数用 alias 命令和查看 shell 函数定义的方式，确认工具不是被一个夹带参数的命令调起来的。是的话，先把那个别名或函数找出来，单独处理。

按顺序删：环境变量、配置文件、缓存凭证

删的时候讲究顺序。环境变量优先级比配置文件高，先清环境变量，再改配置文件，最后处理缓存和登录态。顺序反了，你会以为自己改好了，其实高优先级那层还在压着。

• 环境变量：临时生效的直接 unset；永久生效的去启动文件里把对应行整行删掉或注释掉。改完必须重开一个终端窗口，旧窗口里的变量还在内存里，不会自动刷新。
• 配置文件：把 base url 改回官方地址，或者整段删掉；同时把中转站专用的 api key 一起清掉，别只换地址把旧 key 留着。
• 缓存和登录态：工具缓存的凭证、token 文件、插件目录里可能还存着一份旧的鉴权信息，不删的话可能仍被优先读取。
• 备份：动手前把旧配置复制一份存到别处。万一某条配置是别的东西在共用，能马上还原，不至于连累其它工具。

判断标准很简单：哪一层优先级高，就先动哪一层。命令行参数和别名优先级最高，如果发现工具是被别名调起来的，那个别名要最先处理。什么情况下不适用？如果中转站是公司统一推的配置文件，改之前先确认改动会不会影响同事，这种情况最好单独拉一份自己的配置。

验证是否真的清干净了

改完不等于清干净，得跑一遍验证。验证的核心是确认请求实际打到了哪个域名，而不是看你配置文件里写了什么。配置写对了、请求还走旧地址的情况很常见。

如果请求仍然走旧地址，排查顺序是从高优先级到低优先级：命令行别名、环境变量、项目配置、用户配置，一层一层排除。每排除一层就重新发一次请求，确认问题是否消失，别一次改好几处，那样出了新问题分不清是谁引起的。

换回官方之后，顺手把测速基线重新量一次，延迟和原来的差异心里有个数。这类跨地域访问的延迟差异挺明显，具体做法和当时的数据可以到站内的测速工具页看，别凭感觉判断。

配置改对了不代表请求改了路，只有日志和抓包能告诉你请求真正去了哪。