Codex App接入Sub2API不显示模型？排查思路与解决方案

最近在折腾 AI 相关的工具时，不少朋友反馈在用 Codex App 接入 Sub2API 时，明明订阅链接没问题，可客户端里死活刷新不出模型列表。这个问题其实很常见，通常不是因为软件坏了，而是配置细节上容易“踩坑”。今天我就把平时排查这类问题的经验整理一下，希望能帮大家节省点调试时间。

Sub2API 工作流程示意图

Sub2API 将订阅链接转换为 OpenAI 兼容格式的流程示意。

在解决问题前，我们得先明白 Sub2API 是干嘛的。简单来说，它就是一个格式转换器，负责把你的订阅链接（通常是 Clash 或 Sing-box 格式）转换成 OpenAI 兼容的 API 格式。

配置界面示意图

在 Sub2API 配置界面手动指定模型名称或进行参数设置。

如果 Codex App 收不到模型，大概率是因为转换后的数据里没有正确包含模型名称，或者是 Codex App 请求时的参数对不上。所以，排查的核心就在于“订阅源”和“转换配置”这两头。

很多时候，问题出在源头上。如果你的订阅商提供的节点本身没有打上正确的标签，Sub2API 读不到，自然也就吐不出模型列表。

确认节点支持：先去订阅商的后台确认，你选用的节点是否明确支持 OpenAI 或 Claude 等大模型的转发。有些节点虽然能上网，但屏蔽了 AI 端口。
节点嗅探选项：如果你是自建的节点，或者在 Surge 等客户端里配置过，记得开启“sniffing（嗅探）”选项，确保流量能被正确识别为 TLS 流量，防止被当成普通 HTTP 流量处理导致握手失败。
协议兼容性：Sub2API 对某些协议的支持可能有限。如果你订阅里全是 Trojan 或者 Reality 节点，尝试切换一个 Vmess 或 Vless 节点试试，有时候协议层的实现差异会导致握手信息丢失。

这是问题最高发的地方。很多时候我们直接把订阅链接丢进去，默认参数其实并不适配 Codex App。

自定义模型名称：不要依赖自动识别。在 Sub2API 的配置页面或请求体中，尽量手动指定 model_mappings 或者直接将目标模型（如 gpt-4o, claude-3-5-sonnet）硬编码到返回结果里。

检查 Base URL 和 Key：Codex App 里填写的 Base URL 必须精准指向 Sub2API 的转换接口地址（通常是以 /v1 结尾）。同时，API Key 虽然有时候可以随便填，但最好还是按照 Sub2API 后台要求的格式填写，避免鉴权层直接拦截请求。
HTTPS 与证书：如果你部署的 Sub2API 用了自签名证书，Codex App 作为一个普通客户端，大概率会报 SSL 错误从而导致加载失败。建议使用反向代理（如 Nginx+Caddy）配置正规的 SSL 证书，或者确保 Codex App 的设置里勾选了“允许不安全连接”（如果有此选项的话）。

如果后端都没问题，那就看看是不是客户端操作不当。

强制刷新：添加完 API 后，不要就在列表里干等。尝试下拉刷新，或者删掉重新添加一次，触发一次完整的数据同步。
查看调试日志：这是终极手段。虽然用户界面看不到报错，但如果你有权限访问 Sub2API 的服务端日志，去看看 Codex App 发来的请求长什么样。
- 关注点：检查 /v1/models 这个接口的返回值。如果是 200 OK 但数组为空，说明转换器没读到模型；如果是 401/403，那就是 Key 权限问题。

如果实在排查不出原因，你又急着用，可以尝试以下“绕路”法：

直连模式：如果订阅商同时提供了专门的 AI 中转地址（通常是一个独立的 API 链接），试着绕过 Sub2API，直接把这个地址填进 Codex App。如果直连能显示模型，那 100% 是 Sub2API 的配置问题。
使用通用转换工具：市面上有不少现成的 Sub2API 在线转换服务，或者是一键部署的 Docker 镜像（如 tiangolo/sub2api 等类似项目），换一个转换工具试试，排除特定工具的 Bug。

接入不显示模型，无非就是“源（订阅）-> 管（Sub2API）-> 端（App）”这三个环节脱节了。先绕过 Sub2API 直连测试，再逐步倒推检查转换配置，最后看看是不是协议或证书的小细节在作祟。希望这篇笔记能让你少抓几次头皮，搞定这个恼人的空白列表！