打开 Codex 客户端还没来得及敲第一行需求状态栏就开始抽风Reconnecting... 断线、重连、再断、再连循环到第五次之后要么颤颤巍巍连上要么直接瘫在 waiting for network 上彻底不动。这个问题最近在 Codex 用户群里出现频率高得离谱我自己也被它折磨了整整两周最后把认证令牌、模型配置、本机转发链路、Windows 安装残留四条线全部过了一遍才算把每次打开必重连 5 次的根因彻底挖干净。这篇文章不打算写重启一下试试这种正确的废话。我会完整还原我的排查链路每次重连背后客户端到底在做什么、5 次这个数字从哪来、日志里哪些关键字分别指向什么病、每一步怎么修。不管你是用桌面版还是终端里的 CLI照着这个顺序走一遍十分钟内大概率能定位到你自己机器上的那一个根因。1. 现象复盘那 5 次 Reconnecting 到底在重连什么1.1 复现时的完整画面先说现象不然对不上号。我这边是 Windows 桌面版每次启动应用后窗口能正常弹出来界面也能画出来但会话列表和输入区全部不可用顶部一直交替显示 Connecting、Reconnecting 和 waiting for network 三种状态。大概三到五秒一轮连续五轮左右状态才稳定下来。这五轮里你什么都干不了敲回车也没反应整个应用像被按了暂停键。还有一种更气人的变体五轮重连之后看起来连上了界面上也出现输入框了但一旦你发起第一条请求立刻又开始新的一轮重连。这种属于假连接——传输层握手成功了但底层链路在真正传输数据时随即断开客户端只能重新走一遍连接流程于是你看到一个奇怪的循环界面正常但一说话就断线。CLI 版本的表现不一样没有那么多花哨的状态提示就是启动后卡在日志刷新上等很久才出现提示符。如果拿它跑批处理任务任务会一直挂起迟迟没有输出最后抛出一串连接超时错误然后退出。很多人遇到这种情况第一反应是网络出问题了但实际上它和桌面版反复重连是同一套底层机制只是外层表现不同。1.2 5 次不是玄学客户端的退避重试策略刚开始我也觉得每次恰好五次是玄学直到把日志打开才看明白。Codex 客户端对建立会话的基础请求做的是有限次数的退避重试每次失败后等待时间递增典型的指数退避序列是 1 秒、2 秒、4 秒、8 秒、16 秒五次失败后放弃当前连接策略或者降级到一个只读等待状态界面上的表现就是卡死在 waiting for network。理解这个机制特别重要它能直接告诉你两件事。第一如果五次重连之后恢复了说明触发问题的那个环节在第五次之前恢复了可用。最典型的场景就是本机某个转发服务启动得比 Codex 晚前四轮请求打过去时端口还没监听第五轮它总算就绪了连接才建立成功。这种启动顺序错位造成的重连你改任何 Codex 配置都没用得从启动编排上下手。第二如果五次之后还是连不上说明问题不是临时抖动而是持续性的硬故障。比如令牌彻底失效、模型名根本不存在、转发端口压根没在监听或者你连的接口地址本身就是错的。这种情况下重试多少次都一样反复重启客户端只是浪费生命。所以遇到重连先别急着瞎折腾把日志打开看一眼再动手。1.3 打开日志的正确姿势桌面版一般不需要额外参数日志文件默认落在本地目录。Windows 下在%USERPROFILE%\.codex\logs\macOS 和 Linux 在~/.codex/logs/。用资源管理器或ls直接列目录就行按时间排序找最新的日志文件。CLI 版可以带调试参数启动不同小版本的参数名略有差异拿不准就直接执行codex --help查一下日志等级相关的选项或者把环境变量里的日志级别调到 debug 甚至 trace。日志一多会刷屏但没关系我们要找的不是全部内容而是每一轮重连开始时第一条失败原因。日志里真正值得关注的关键字就几个带auth token或unauthorized字样指向认证令牌问题。带model is not supported字样指向模型配置问题。单独出现waiting for network多半是网络链路压根没建立起来。出现本地转发失败相关报错指向本机出口配置问题。把第一轮失败原因找出来你的排查方向基本就定了剩下的事就是顺着目录往下走。2. 快速分诊把认证、模型、网络三类病因一次分清楚2.1 三类病因的典型报错对照我把社区里反馈过的 reconnecting 病案归拢了一下绝大多数落在三类上。区分它们其实很快看报错关键字和重连后的行为就能定位。下面这张表是我自己整理的判断依据你可以直接拿来对照。报错关键字所属类别重连失败后的典型表现auth token is unavailable、unauthorized、401认证直接退出登录态界面提示重新授权model is not supported、model not found模型配置界面能正常加载一发请求就报错waiting for network、connect timeout、connection reset网络链路五轮后仍卡死偶尔恢复但很快又断本地转发失败相关报错网络链路本机出口启动必重连转发服务恢复后自动好2.2 一分钟快速分诊法不用把所有工具都装齐分诊只需要三个动作。第一个动作看日志里第一轮重连的失败原因。这个最直接日志写了什么就按什么方向查。第二个动作换一个网络出口试一次比如从宽带切到手机热点。如果立刻不再重连问题基本锁定在本地网络链路和本机转发配置如果照旧重连那多半不是网络通路的问题而是认证或模型配置——这两个问题换哪个网络都一样。第三个动作在命令行里直接请求一次 API 域名验证基础连通性。能通再谈认证和模型不通先把链路修好。分诊这一步省不得。我见过太多人上来就重装客户端、清缓存折腾一晚上最后发现只是转发端口被占用了。端口这种问题重装十次也解决不了但看日志一眼就能定位。2.3 一个特别容易误判成网络问题的场景有一种场景特别容易让新手误判企业内部网络或者校园网。这类网络通常有自己的出口认证机制Codex 启动时正好赶上出口认证失效、带宽被限或者访问策略调整表现就是反复重连日志里全是超时和连接重置。你在这个网络里折腾一晚上什么结论都得不到切到手机热点一测所有报错瞬间消失那问题就锁定在当前网络的出口跟 Codex 本身没有任何关系。这类场景的修复方式也不是改 Codex而是去处理网络出口的问题。先把这个最外层的变量排除掉再回来排查本机逻辑上会清爽很多。3. 认证令牌失效auth token is unavailable 的完整处理3.1 令牌文件存在哪、为什么会失效Codex 走的是本地凭证机制登录成功后会把访问令牌落到本地文件里后续每次启动都靠读取这个文件完成鉴权。文件位置因平台而异Windows 在%USERPROFILE%\.codex\auth.jsonmacOS 和 Linux 在~/.codex/auth.json。auth token is unavailable这条报错翻译过来就是客户端启动时尝试读取令牌但文件里没有有效的令牌内容。常见原因有三个令牌过期后被客户端标记成失效文件被清理软件或磁盘清理工具误删多账号切换时某个账号的写入没有完成留下一个只剩半边内容的残文件。这个问题的隐蔽之处在于报错时机经常不是在启动那一刻而是第一次发起请求的时候。所以你会看到一种迷惑现象界面正常加载看起来一切都好但一输入内容就开始重连。其实那已经是令牌问题的后半场了。3.2 标准重登流程与验证处理方式不复杂核心操作就一句话让客户端重新走一遍完整的登录授权流程。codex logout codex login执行完 logout 之后建议顺手把 auth 文件备份后清掉避免残留的半截状态干扰新的登录。然后重新执行 login客户端会弹出浏览器授权页面确认账号后把授权信息回写。完成后验证一下状态能正常进入会话就说明令牌这一环已经修好。桌面版的入口在设置面板里一般有账号相关的登出和重新登录按钮交互逻辑和 CLI 一致。这里要特别提醒桌面版和 CLI 不保证共享同一份凭证如果你两个都在用两边都要分别确认一遍登录态别只修了一个就觉得完事了。3.3 两个容易忽略的坑环境变量覆盖与文件权限第一个坑是环境变量覆盖。部分版本支持通过环境变量注入密钥或令牌如果你之前在这个用户下设置过相关变量它的优先级可能高于本地登录文件而且内容经常是旧值。结果就是不管你重新 login 多少次客户端读到的都是那个旧值表现永远是令牌不可用。排查方式很简单临时把相关环境变量清掉再启动一次如果立刻恢复正常就是它在捣乱。第二个坑是文件权限。Linux 和 macOS 上如果 auth 文件的权限设置得过宽或者过窄客户端可能直接拒绝读取报错和文件不存在一模一样。用ls -l看一眼文件权限确认只有当前用户可读就行。Windows 上类似的问题是杀毒软件或系统清理工具把 auth 文件当成可疑文件隔离了记得把.codex目录加进信任列表。4. 模型配置冲突gpt-5.6-sol 这类 not supported 报错的修正4.1 模型名是从哪冒出来的Codex 默认会选择当前账号可用的推荐模型但很多用户会手动在配置文件里指定模型名或者在使用第三方引导工具时工具自动往配置里写入了一个模型名。配置文件是config.tomlWindows 在%USERPROFILE%\.codex\config.tomlmacOS 和 Linux 在~/.codex/config.toml。社区里大量出现的the gpt-5.6-sol model is not supported就是典型的模型名翻车现场。这个模型名可能是某个新功能的内测代号、第三方接入文档里的示例或者干脆就是你从某篇旧教程里抄来的。客户端在和服务器握手时发现该模型在当前 API 版本下不可用请求直接被拒。连接层不知道这是应用层错误以为是临时失败于是进入重试表现出来就是你看到的反复重连。这类问题最坑的地方在于它完全不是网络问题但表现比网络问题还像网络问题。如果你把时间花在查端口、查 DNS、甚至重装系统上永远找不到答案。4.2 确认你的账号实际能用哪些模型这一步别猜直接验证。最稳妥的方式是去 OpenAI 账号后台查看当前订阅计划可用的模型列表或者用官方 CLI 提供的方式查询模型清单。如果你是通过第三方兼容接口接入的那就以该服务方提供的模型列表为准因为不同服务方对模型名的兼容映射差别非常大同一个名字在不同服务方那里的含义可能完全不同。拿到可用列表后把配置里的模型名改成列表里真实存在的名字。这里要特别强调不要迷信网上随便抄来的模型名。同一个名字在不同接口、不同账号、不同时间点可用性都可能不一样你抄来的那一刻也许它还存在等你看教程的时候它可能已经被下架了。4.3 修改配置的正确姿势配置文件是 TOML 格式修改模型名核心就一行# ~/.codex/config.toml 或 %USERPROFILE%\.codex\config.toml model gpt-5.4改完保存完全退出客户端再重新启动。注意是完全退出——Windows 桌面版经常在系统托盘里驻留进程光关窗口配置不会重新加载。最稳妥的做法是任务管理器里确认没有 codex 相关进程存活再重新启动。改完之后先发一条最简单的消息验证模型链路别上来就丢大任务。如果还报 not supported回到 4.2 重新确认模型名如果不再报错说明问题解决。另外改配置之前先把原文件备份一份万一改坏了还能恢复这是所有配置文件操作的基本素养。5. 网络链路与本地转发端口启动时前几轮必失败的典型场景5.1 转发层在重连里扮演的角色这一节要说的场景是本机配置了请求转发服务。Codex 的所有 API 请求先打到本地某个转发端口再由它向外转发。这种配置本身没问题但一旦转发环节出状况Codex 的表现就会非常网络化——反复重连而且报错里时常出现local proxy failed相关关键字也就是社区里大家高频讨论的那条转发失败报错。为什么启动时最容易爆发因为存在服务启动顺序问题。很多人开机后 Codex 自动启动而本机转发服务比它晚几秒才就绪。Codex 第一轮请求发出去转发端口还没监听请求直接失败第二轮再试可能还没起来直到第五轮转发服务总算就绪连接才建立成功。这就完美解释了每次打开都要重连 5 次。如果你发现重连之后能连上而且五次之后就正常先怀疑这里而不是怀疑 Codex 本身。这个场景下 Codex 是个受害者真正的问题出在转发服务的启动时机上。5.2 端口存活与配置一致性检查首先确认转发服务是不是真的在监听你配置的那个端口# Windows netstat -ano | findstr 1080 # macOS / Linux netstat -anv | grep 1080换成你的实际端口。没有输出说明服务没起来有输出但对应进程不是你以为的那个说明端口被别的程序占用了。端口被占是另一个经典坑你配置的转发端口被某个完全不相关的进程抢了Codex 的请求全部发给了那个无辜进程对方当然不响应于是一轮轮重连。接下来确认 Codex 走的端口和转发服务监听的端口是不是同一个。很多人改了转发服务的端口却忘了同步改 Codex 这一侧的配置两边不一致表现就是永远连不上连五次之后彻底放弃。还有一个常见问题是环境变量残留。系统里常见的HTTP_PROXY、HTTPS_PROXY、NO_PROXY这类环境变量如果指向了一个失效地址或端口Codex 的每条请求都会先打到一个不存在的地方然后才开始重试。这种问题最坑的地方在于它和网络不通的表现几乎一样但根源完全不同。用echo $HTTP_PROXY或 Windows 的set HTTP_PROXY看一下当前环境变量把失效的清理掉。5.3 本机回路、DNS 与防火墙的隐性干扰如果转发服务本身还要访问本机上的其他服务比如本地缓存、本地模型网关这时候要注意本机回路的绕过配置。也就是NO_PROXY白名单里该包含localhost和127.0.0.1却没有包含的情况。请求会在本机内部绕一圈自己访问自己一旦转发层对这个路径处理不当就会超时重试。这个问题的典型表现是外部网络明明连通普通网页、其他开发工具都正常但 Codex 依旧重连。排查时留意日志里是否有指向本机地址的请求卡住超时。DNS 解析异常也不容忽视。waiting for network有一种隐藏原因就是域名解析失败或解析极慢。排查方式很简单ping一下 API 域名看解析是否正常、延迟是否离谱。如果发现解析到错误 IP检查 hosts 文件里是不是有历史残留。防火墙和安全软件是另一大干扰源。部分安全软件会对频繁发起网络请求的新程序进行拦截Codex 更新后数字签名变化可能触发新的拦截规则。这类问题在重连日志里通常表现为连接被重置或者拒绝而且时间点非常规律——每次启动固定被拦。5.4 用命令行直连验证绕开所有中间层无论你怀疑什么最后都建议做一次直连验证排除所有中间环节的干扰。在终端里直接请求 API 域名curl -v https://api.openai.com/v1/models如果这一步有响应说明基础网络通如果超时说明链路本身存在问题先解决链路问题再看 Codex。如果直连通但 Codex 不通问题就锁定在 Codex 的配置或本机转发设置上。顺带提一个场景不少用户会把 Codex 接到第三方兼容接口上使用比如通过兼容 OpenAI 接口标准的服务跑各类模型这也是社区热门话题之一。这种场景下接口地址填错、路径少了一段、鉴权头格式不对都会在启动时表现为反复重连。同样用 curl 直接打这个接口的地址看返回的是正常 JSON 还是错误码很快就能定位。日志里那些看似高深的报错绝大多数都能被一个简单的 curl 请求解释清楚。6. Windows 安装残留与让重连成为历史的日常操作6.1 Windows 安装不完整带来的连带问题如果你用的是 Windows 桌面版还要额外检查安装状态。codex windows 安装未完成这个搜索热词不是没道理安装程序中断、被杀毒软件拦了一半、多个版本残留都会让客户端处于半可用状态。表现就是能打开、能显示界面但底层组件缺失启动时反复尝试加载失败进而触发重连。这种半残状态非常迷惑人因为从界面上看一切正常只有日志里不断出现组件加载失败的记录。处理方式是彻底清理后重装先卸载桌面版再手动检查%USERPROFILE%\.codex目录下是否有版本残留最后重新下载安装包安装。不要覆盖安装覆盖安装很容易把半截状态原封不动地保留下来换了也白换。6.2 遇到重连时的标准操作顺序经过前面这些折腾我自己总结了一套遇到重连时的标准操作顺序按这个顺序来能省掉大量无效操作先开日志找到第一轮重连的失败原因这一步决定方向。按日志关键字走分诊认证问题重新登录模型问题改配置链路问题查端口和转发服务。修复后不要只关窗口要让客户端进程完全退出再启动确保配置和凭证都重新加载。修复后发一条最简单的消息验证别上来就丢大任务。这套顺序帮我解决了自己机器上 90% 以上的重连问题剩下 10% 属于 OpenAI 服务端本身的临时故障。那种情况等几分钟自己就好客户端的重试机制会兜底你反复重启反而可能因为触发频率限制让情况更糟。6.3 让每次打开重连 5 次变成历史最后说几个长期有效的防复发手段。令牌在失效前主动重新登录一次别等到客户端开始报错才处理本地转发服务的端口固定下来不要频繁更换Codex 和转发服务设置为同一个开机启动组避免启动顺序错开定期清理 config.toml 里不再使用的自定义模型名Windows 上定期确认.codex目录没有被安全软件隔离。我自己现在启动 Codex 的基本状态是打开、秒连、直接干活。回想那两周被 reconnecting 支配的日子最大的教训就是别盯着转圈发呆先看日志第一条报错。这类问题从来不会藏在你以为的地方它总是大大方方写在日志里只是你还没来得及去看。排查的每一步都是排除法而日志就是帮你把候选范围一步步缩小的最可靠工具。