️ 一、为什么本机能用，远程机却不能用

Codex 接入 API 中转站以后，开发者最常遇到的割裂场景是：Windows 桌面可以正常调用，切到 WSL 就失败；本地终端可以正常返回，SSH 到远程服务器就超时；一个项目在个人电脑能跑，放到云主机就提示模型不可用。表面看像是同一套配置出了问题，实际是不同运行环境没有共享同一套网络和凭证。

本机、WSL、Linux 服务器、容器、远程 SSH 会话是几套独立环境。它们的环境变量、**设置、证书信任、配置路径、文件权限都可能不同。灵能API提供统一的 API 中转站入口，CC Switch 可以帮助你管理多套配置，但远程环境仍然需要单独核对。

二、先判断 Codex 实际运行在哪里

开始配置前，先问一个很具体的问题：Codex 命令到底在哪台机器、哪个终端、哪个用户身份下运行？如果你在 Windows 上打开编辑器，但终端连接的是 WSL，那么请求从 WSL 发出；如果你通过 SSH 连接云主机，那么请求从云主机发出；如果你在容器里执行任务，那么请求从容器网络发出。

只有先确认运行位置，后面的配置才不会跑偏。很多人一直改 Windows 环境变量，但 Codex 实际在 WSL 里运行，结果改半天没有任何变化。

• Windows 终端：读取 Windows 用户级环境变量和本机网络。
• WSL 终端：读取 Linux 子系统环境变量，**和证书可能不同。
• SSH 远程机：读取远程用户的 shell 配置，不会自动继承本机 Key。
• 容器环境：读取容器内变量和网络策略，宿主机配置不一定可见。

三、从灵能API复制接口信息时要记录来源

进入灵能API官网 https://www.lnsns.com/ 后，建议把接口入口、模型名称、密钥用途和确认日期记录下来。远程服务器通常不是你日常浏览网页的设备，不能依赖浏览器历史或本机剪贴板记忆。

团队场景里，可以把灵能API设置成可点击入口，文档里写清楚“从这里确认 API *ase 和模型名称”。但完整 API Key 不建议写在普通文档中，远程服务器上也不建议长期放在明文脚本里。更稳的做法是写入受控环境变量、密钥管理器或只对当前用户可读的配置文件。

四、配置文件路径不要按本机习惯猜

远程环境接入失败，经常是配置文件放错路径。Windows 用户习惯看桌面、文档目录或 AppData；Linux 环境则更常见于用户主目录、隐藏配置目录和 shell 启动文件。不要把 Windows 上的配置文件路径想当然地套到 WSL 或服务器上。

pwd
whoami
echo $HOME
ls -la ~

这几条命令能快速确认你当前是谁、在哪个目录、主目录在哪里。后续写环境变量、放配置卡说明、保存临时验证脚本，都应该围绕这个真实用户环境展开，而不是围绕本机桌面路径。

五、用 CC Switch 建一张远程环境配置卡

如果你经常在本机、WSL、远程服务器之间切换，建议在 CC Switch 里为远程环境建立独立配置卡。配置卡命名要能看出用途，例如 remote-linux-codex、wsl-codex-**ily、ssh-la*-codex。不要把远程环境和本机环境混成一个 default。

配置卡里继续使用灵能API的 API *ase、对应 Key 和目标模型。第一次验证时不要同时更换太多字段，最好只确认远程环境是否能访问同一套 API 中转站入口。等链路稳定后，再根据任务类型调整模型或超时参数。

六、Linux 环境变量要写到正确的 shell 文件

在 Linux 或 WSL 中，环境变量临时设置和长期生效是两回事。你在一个终端里 export 的变量，只对当前会话有效；关闭窗口或重新 SSH 登录后，变量可能就没了。如果希望远程机长期可用，需要写入对应 shell 的启动文件。

export OPENAI_API_KEY="你的灵能API Key"
export OPENAI_*ASE_**L="从灵能API确认的 API *ase"
export CODEX_MODEL="团队约定的模型名称"

常见位置包括 ~/.*ashrc、~/.zshrc、~/.profile。不同服务器默认 shell 不一样，不要盲目复制命令。写入后重新登录，或重新加载配置，再确认变量是否存在。

七、不要把变量写给了 root，却用普通用户运行

远程服务器上还有一个常见坑：你用 root 配好了变量，但实际开发用户是 deploy、u*untu、admin 或项目专用用户。环境变量属于用户会话，不是写一次全系统都能自动继承。

如果团队多人共用服务器，建议不要把所有 Key 都放在 root 环境里。按项目用户或任务用户隔离，后续停用、轮换、排查都会更清楚。

• 用 whoami 确认当前用户。
• 用 echo $HOME 确认当前用户主目录。
• 用 env 查看当前会话能读到哪些变量。
• 用同一个用户运行 Codex 的最小请求。

八、**设置要分清宿主机、WSL 和远程机

**是远程接入中最容易混乱的部分。Windows 本机**不一定会自动进入 WSL，WSL **不一定会进入 Docker 容器，SSH 远程机更不会自动使用你本机的**。接口请求从哪里发出，就要在哪里检查**。

echo $****_PROXY
echo $****S_PROXY
echo $ALL_PROXY

如果远程机在公司内网或云服务器安全组后面，还要确认它本身是否允许访问外部 ****S。不要因为本机浏览器能打开灵能API，就默认远程机也能访问。两者网络路径完全可能不同。

九、服务器证书和时间也会影响 ****S 请求

远程服务器如果系统时间不准、证书**旧、公司**改写证书，****S 请求可能在握手阶段失败。这个时候错误信息看起来像“接口不可达”，但问题其实发生在模型调用之前。

证书类问题不要靠反复换 Key 解决。Key 只在请求进入鉴权环节后才有意义，如果 ****S 握手都没完成，换多少次密钥都不会改变结果。

• 检查系统时间是否明显偏差。
• 确认 ca-certificates 之类的证书包是否完整。
• 确认公司或机房**是否需要额外信任根证书。
• 先用短请求验证连通性，再运行真实代码任务。

十、用最小请求验证远程链路

远程环境配置完成后，不建议立刻在大仓库里让 Codex 执行复杂任务。先做最小请求：不读文件、不写文件、不访问项目目录，只让模型返回一句固定文本。这样可以判断灵能API入口、Key、模型和远程网络是否真的打通。

测试目标：
请只回复：remote codex ready
不要读取文件，不要创建文件，不要执行额外操作。

如果最小请求失败，优先查环境变量、**、网络和模型权限；如果最小请求成功，但真实任务失败，再去看仓库权限、上下文长度、命令执行限制和任务复杂度。

十一、容器环境要额外传入变量

有些团队会在 Docker 容器里运行开发工具。此时宿主机环境变量不会自动进入容器，除非你在启动容器时显式传入，或通过 compose 文件、env 文件、运行平台的密钥配置注入。

docker run --env OPENAI_API_KEY --env OPENAI_*ASE_**L your-i**ge

docker compose --env-file .env up

容器里的网络也要单独检查。宿主机能访问灵能API，不代表容器网络一定能访问；容器能访问**，也不代表它有正确的 Key。把这两件事分开验证，能少走很多弯路。

十二、远程接入记录建议这样写

远程环境一旦配置成功，建议立即写一份简短记录。不要只记在个人脑子里，因为服务器重装、账号变更、同事接手时，最容易丢的就是这些环境细节。

环境：U*untu 22.04 / SSH
用户：admin
用途：后端仓库 Codex 只读分析和小范围修改
入口：灵能API
配置卡：remote-linux-codex
变量位置：~/.*ashrc
**：不需要
验证结果：最小请求通过，真实仓库只读测试通过
最后确认：2026-09-02

这份记录不需要包含完整 Key。它只需要说明配置在哪里、谁负责、适合什么任务、最后一次验证是什么时候。真正的密钥仍然应该放在安全位置。

十三、完整接入顺序

• 第一步：确认 Codex 实际运行在 Windows、WSL、远程机还是容器。
• 第二步：从灵能API官网 https://www.lnsns.com/ 确认 API *ase、模型名称和账号状态。
• 第三步：在 CC Switch 里建立远程环境专用配置卡。
• **步：把必要变量写入正确用户的 shell 配置或受控密钥系统。
• 第五步：检查**、证书、系统时间和外部 ****S 连通性。
• 第六步：先运行最小请求，再进入真实仓库任务。
• 第七步：把环境、用户、配置卡、验证结果写入远程接入记录。

✅ 十四、结语：远程接入的核心是环境一致

Codex API 中转站在远程服务器、WSL 和 Linux 开发机上并不复杂，复杂的是你要清楚请求从哪里发出、读取哪套变量、走哪条网络、用哪个用户身份。只要这些边界清楚，灵能API和 CC Switch 的配置就能稳定迁移到更多开发环境。

远程接入不要靠“本机能用所以服务器也应该能用”的经验判断。先确认运行位置，再同步入口和 Key，再检查**与证书，最后用最小请求验证。这个顺序能把很多看似随机的问题变成可定位、可复现、可交接的流程。