在公司网络 + VSCode Remote SSH 环境下使用 Codex 完整踩坑与解决方案

一、问题背景与分析

为了让公司服务器能够访问外网，通常会先通过 SSH 远程转发（RemoteForward），将服务器的流量转发到本地代理端口（比如C-LASH的7890），以 Windows为例，编辑 C:\Users\用户名\.ssh\config，添加如下配置：

Host 自定义服务器名
    HostName 服务器ip
    User 服务器用户名
    RemoteForward 7890 127.0.0.1:7890

登录服务器，配置代理环境变量（仅当前窗口有效）：

ssh 服务器用户名@服务器ip
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

在完成端口转发后，服务器已经具备基本的外网访问能力，例如：

curl https://api.openai.com

可以正常返回结果。

但此时继续使用 Codex，仍然会遇到一系列问题：

使用ChatGPT登录选项，浏览器登录失败（timeout / 无法完成登录）
使用Device Code认证选项，浏览器还是报错（403 / region not supported）
curl auth.openai.com 被 Cloudflare challenge 拦截
使用VSCode Codex插件登录ChatGPT失败

而同一ChatGPT账号、同一C-LASH配置，在个人电脑上却能正常使用Codex。

这说明一个关键问题： 在企业网络环境中，外网可访问 ≠ Codex可登录。

进一步分析可以发现，这些问题并不是配置错误，而是由以下因素叠加导致：

OAuth 登录依赖浏览器回调（localhost / device code）
Cloudflare 对代理节点进行风控校验
企业网络对 TLS / 长连接存在干扰
Token exchange 阶段容易被中断或拒绝

因此本质结论是：

即使能访问外网，Codex 登录流程在企业网络环境下仍然不可用

由此得到核心思路：

不要在问题环境中修登录，而是在正常环境完成认证，再迁移凭证

即：正常网络电脑登录Codex → 生成 .codex 目录 → 复制到公司电脑 → 上传至服务器 → 启动Codex

二、完整解决流程（可复现）

首先在能够正常访问外网、安装了Codex的个人电脑上执行（例如 Windows 环境）：打开Powershell或CMD，输入codex，回车。如果提示登录，则去登录，登录成功后，codex会在用户目录下生成.codex，路径是C:\Users\用户名\.codex。然后通过钉钉、微信等方式拷贝.codex目录（可先打包）至公司电脑。
在公司电脑上（假设也是Windows）打包：

cd C:\Users\用户名
tar --exclude=.codex/tmp -czf codex.tar.gz .codex

注：这里排除了临时目录tmp，因为不需要上传，上传也可能报错

上传到服务器：

scp C:\Users\用户名\codex.tar.gz 服务器用户名@服务器ip:~

新开会话，登录服务器，在服务器解压、覆盖原目录：

ssh 服务器用户名@服务器ip
cd ~
rm -rf ~/.codex
tar -xzf codex.tar.gz

设置权限：

chmod 700 ~/.codex
chmod 600 ~/.codex/auth.json ~/.codex/config.toml

完成后直接输入codex，回车，无需登录即可使用。

三、远程 VSCode 插件断流问题

完成 .codex 迁移后，常见问题：

终端 codex 正常（服务器上的codex）
远程 VSCode 插件报错：stream disconnected before completion

原因：SSH 远程转发（RemoteForward）已经建立了网络隧道，使远程服务器能通过本地 C-LASH 代理访问外网。但远程插件（Codex）运行时，其网络请求不继承服务器终端中的 HTTP_PROXY 环境变量，而是使用 VSCode 自身的代理设置。

解决方法：本地 VSCode 配置代理

远程插件（Codex）运行时，其网络请求由本地 VSCode 的网络栈处理，因此需要在本地 VSCode 中配置代理，使插件的请求通过 SSH 隧道连上本地代理。

👉 操作路径：

左下角齿轮图标 → 设置
右上角第一个图标（打开 settings.json）
在本地 settings.json 中追加如下两行：

"http.proxy": "http://127.0.0.1:7890",
"http.proxySupport": "override"

配置完成后，需重新加载 VSCode 窗口使设置生效：

左下角齿轮图标
命令面板（Ctrl + Shift + P）
输入 Developer: Reload Window，回车

重启插件后，插件即可正常使用。

解决远程集成终端的网络问题（可选）

若需要在 VSCode 的远程集成终端中执行 codex 命令或访问外网，则也需要为终端配置代理，所以我们可以直接在服务器的 ~/.bashrc 中设置代理。

在服务器上执行：

echo 'export HTTP_PROXY=http://127.0.0.1:7890' >> ~/.bashrc
echo 'export HTTPS_PROXY=http://127.0.0.1:7890' >> ~/.bashrc
source ~/.bashrc

注：此为快速验证方案，后续将优化为仅影响 VSCode 环境的配置。

关键认知：本地与远程是两套系统。

VSCode Remote SSH 实际结构：

本地 VSCode
        ↓
Remote SSH
        ↓
远程 Linux 上的 VSCode

因此配置分工为：

本地 settings.json → 本地 VSCode 全局配置（包括插件、终端等）
远程 settings.json → VSCode Remote SSH 集成终端（界面下方打开的终端面板）
bashrc → 远程 Linux 用户全局环境（慎用）

四、(可选)代理隔离：只影响自己，不影响同事

注：如果使用export临时配置代理或只用VSCode插件访问Codex，请跳过本节。

如果直接在服务器的 ~/.bashrc 中配置代理，则该操作会影响该用户的所有交互式 shell 会话（SSH 登录等），可能导致非预期的网络行为，不是最佳实践。

最佳实践：只在 VSCode 环境生效

👉 操作路径：
首先，打开远程 ~/.bashrc：

nano ~/.bashrc

再把以下代理配置删掉：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

然后ctrl+o保存,ctrl+x退出，再让网络配置生效：

source ~/.bashrc
unset HTTP_PROXY HTTPS_PROXY

本地打开VSCode，进行如下操作：

左下角齿轮图标
命令面板（Ctrl + Shift + P）
输入：open remote，选择Preferences: Open Remote Settings (JSON)

在打开的远程settings.json（VSCode的，不是系统的）中追加：

"terminal.integrated.env.linux": {
   "HTTP_PROXY": "http://127.0.0.1:7890",
   "HTTPS_PROXY": "http://127.0.0.1:7890"
}

效果：

远程 VSCode 终端 → 走代理
远程 VSCode 插件 → 走代理
同事 SSH 登录 → 不受影响
服务器默认网络 → 不变

五、总结

配置分工：

SSH 远程转发（.ssh/config 中的 RemoteForward）：建立网络隧道，让远程服务器能通过本地代理访问外网。
本地 VSCode 配置：让远程插件的请求走本地代理。
（可选）远程 VSCode 配置：让远程集成终端（VSCode终端面板）也走本地代理。

最终架构：

本地 VSCode
  ├── 远程插件 + 远程终端 → 本地 proxy
  └── Remote SSH 连接

远程 Linux
  ├── 插件后端 + 集成终端 → 通过 SSH 远程转发 → 本地 proxy
  └── 其他用户会话 → 默认网络

核心逻辑：服务器借用你本地网络访问外网，但仅限 VSCode 环境。

最终稳定方案：

SSH 远程转发复用本地网络
在正常环境完成认证
迁移 .codex 目录到服务器
本地 VSCode 配置代理
远程 VSCode 配置代理（可选）

这类问题的关键不是调配置，而是思路： 如果问题在错误环境无法解决，要想到能否在正确环境解决然后迁移相关文件。

posted @ 2026-03-31 00:18 zht639 阅读(373) 评论(0) 收藏举报

刷新页面返回顶部