先看错误正文与受影响入口
404 的含义是服务器找不到请求的资源，但这份响应可能来自产品后端、模型路由层、客户端请求路径或中间网络环节。仅凭状态码无法确定原因，必须结合错误正文和失败范围排查。Codex 请求返回 404 Unknown error 与接口返回 Model not found，排查方向并不相同。
- Codex 请求返回 404 Unknown error，且多个模型或入口同时失败：查 OpenAI 状态页，记录发生时间，判断是否与服务端事故时间吻合。
- 错误正文为 Model not found：记录模型名，试一个可选的其他模型；不能只凭报错断言模型下线。
- 桌面 Chat 失败，但网页、手机、Work 或 Codex 可用：保持账号与网络不变，逐个比较入口。
- 同一客户端只在某些网络出口失败：固定模型、账号和设备，对照两条网络路径并留存请求 ID。
三类常见原因及判断边界
HTTP 404 本身信息量很低，分类型的价值在于避免误操作：服务端故障时反复重装客户端没有意义，模型路由问题时换网络同样解决不了。三类原因可能同时存在，也可能一个都对不上。
服务端事故
典型特征是多产品、多入口同时失败，错误正文常为 Unknown error 404。2026年9月3日 OpenAI 状态页确认 ChatGPT 与 Codex 多项服务同时故障，事后定位并解决，当时报告多为 Codex 请求返回 Unknown error 404。该事故已结束，不能用它解释今天的新报错。
Model not found
错误正文指向模型标识。10月中旬的 Model not found 错误正文为 {"detail":"Model not found"}，集中在普通 Chat 与桌面入口，部分账号的 Work、Codex 或手机端仍能用。这说明“入口 × 模型”组合是关键变量；社区尚未确认通用根因，不能据此断言模型下线或账号异常。
客户端或入口差异
同账号同网络下，只有某个入口或客户端失败。这说明需要比较入口行为，但不能仅凭这一点断言是客户端 Bug。
六步排查顺序
每一步都给出操作和判定结果的含义，哪一步恢复了就停在哪一步，恢复点本身就是病因定位。
- 留证据：完整复制错误正文，并记录产品入口、模型名、发生时间、客户端版本和脱敏后的请求 ID。只有状态码时，后续所有对照都无法验证。
- 查状态页并记录时间：对照 OpenAI 官方状态页是否有对应事故。有事故就保存错误信息等待恢复；状态页显示正常不代表个人请求正常，继续下一步。
- 做同账号入口对照：保持账号与网络不变，依次在网页版、手机端、桌面普通 Chat、Work 和 Codex 发送简单请求并记录。注意各入口提供的模型可能不一致，不一致时标记出来，不算严格同条件。结果不同说明产品入口是关键变量，集中排查失败入口的版本与请求路径；全部失败则回到状态页与账号、模型维度，此时怀疑网络为时过早。
- 仅浏览器单点异常时测无痕窗口和另一浏览器：只有浏览器入口失败时，开无痕窗口、换另一个浏览器各重试一次。恢复说明是浏览器状态问题（缓存、扩展或会话数据）；无效则停止套用这组操作。这是低成本排除浏览器状态的办法，不是已证实的普遍修复，桌面端和 CLI 报错不要套用。
- 只有错误随网络路径稳定变化时才查出口：固定账号、模型、设备和客户端版本，只改网络路径，多次复测。仍是一通一错，才能说“与出口路径相关”；复现不了就停止换节点，回到模型、客户端与服务状态。即使确认出口相关，也不能直接说 IP 被封——现有报告涉及的是模型标识和客户端差异，推不出 IP 信誉结论。
- 仍未解决时提交反馈：汇总客户端与版本、操作系统、产品入口、选中模型、完整错误正文、发生时间、脱敏请求 ID，隐去访问令牌与 Cookie 等凭证后提交官方支持渠道。带齐信息的一次反馈，比反复重装更有效。
可选办法与证据边界
- 使用同账号下能正常工作的入口临时继续：有用户报告网页、手机、Work 或 Codex 中某些入口正常；这是绕行，不是修复。
- 无痕窗口、换浏览器：有个案有效，也有同一问题在无痕和另一浏览器仍失败的报告。
- 更换网络出口：有用户报告不同出口结果不同，也有换节点无效的报告；只能作为对照测试。
- 修改 User-Agent：有用户报告改为较旧 Chrome 标识后恢复，也有用户结果不同；属个案测试，非官方修复，不作为普通用户首选方案，也不建议长期伪装浏览器身份。
- 重装、清缓存、重新登录：有用户报告无效，不列成默认必做步骤。
何时才需排查网络出口
网络是最后一个进入排查的变量，进入之前有几条边界要认清：
- 网页能打开只说明页面能访问，不能证明每个接口请求都正常——页面加载和功能请求走的是不同路径与校验逻辑。
- 404 不能单独证明 IP 被封；Model not found 也可能来自模型标识或产品请求映射。
- 有用户在固定账号和模型下报告不同出口结果不同，但尚无官方确认根因是 IP 信誉、封禁还是路由策略，这批报告推不出 IP 信誉结论。
- 换路径后结果不稳定或无法复现，就停止反复换节点，回到模型、客户端和服务状态排查。
如果同一客户端、账号和模型在不同网络路径下持续出现可复现差异，再把出口路径纳入排查。IPxSS 海外 AI 网络方案可作为网络路径对照的方案之一，其固定归属让登录记录连贯，优质运营商资源降低出口被挑战的概率，并提供 7×24 监控异常及时响应，详情可访问 https://www.ipxss.com/。
常见问题
Codex 提示 404 Not Found 是 IP 被封了吗？
不能只凭 404 判断。只有当同一账号、客户端、模型下错误随出口稳定复现差异时，出口才进入排查范围，且仍不能直接等同于 IP 被封。
Codex 返回 Model not found 是模型下线了吗？
不一定，更可能是模型标识或请求映射问题。同账号换一个其他可用模型验证：正常则问题集中在失败模型，保留模型名和脱敏请求 ID。
Codex 404 但手机端能用，是电脑出问题了吗？
更可能是入口差异而非设备故障。各入口模型、权限和请求实现不同，同账号同模型各发一条请求对照，部分入口能用就切过去继续工作。
Codex 404 要换网络节点才能解决吗？
只有错误随网络路径稳定变化时才值得换。固定账号、模型、客户端，两条网络各跑一次：一通一不通才查出口，结果一致就别换节点，问题不在网络。
把浏览器标识改成旧版 Chrome 能修复 Codex 404 吗？
有用户对照发现改旧版标识后请求成功，也有用户结果不同，属个案复测、未获官方确认。不作为常规修复步骤，也不建议长期伪装浏览器身份。
总结
Codex Model not found 和各类 404 的处理主线只有一条：完整错误正文和受影响入口是判断起点，按类型分原因，做同账号入口对照这类低风险验证，只在错误随网络路径稳定复现差异时才检查出口，最后把带齐证据的反馈提交官方渠道。需要稳定跨境网络环境时，可把 IPxSS 海外 AI 网络方案作为路径对照选项。