1. 阿里云服务器上 Openclaw 远程访问与 Codex 接入的真实场景Openclaw 是一个可以在服务器上长期运行的智能体框架它把 Control UI、会话模型、工具调用都收拢到一个本地网关里。你在阿里云 ECS 上把它跑起来之后第一件让人头疼的事往往不是安装而是「远程怎么连、模型怎么接」。默认情况下Openclaw 的 Control UI 只认安全上下文也就是https://或者http://127.0.0.1:18789这种本地回环地址。你从自己电脑浏览器直接敲http://公网IP:18789大概率是打不开的页面要么空白要么提示不安全上下文被拒绝。我一开始也踩过这个坑ECS 安全组端口开了服务也systemctl status显示 running但浏览器就是连不上 Control UI。后来才明白Openclaw 对远程 UI 的访问做了限制要么走 HTTPS要么走 Tailscale 这类私有网络要么在配置里显式放开不安全认证。这三种方式各有取舍本文重点放在「放开 HTTP 用 TaoToken 统一 Key 接管 Codex」这条最省事的路径上同时把 Codex 的auth.json和 Base URL 配置讲透。为什么要把 Codex 接进来因为 Openclaw 的会话默认模型来自~/.openclaw/openclaw.json里的agents.defaults.model.primary而这个模型必须在models/providers里列出来。Codex 作为编码类智能体在 Openclaw 里承担代码生成、文件编辑、命令执行这些任务。如果你本地已经用 Codex CLI 登录过会有一个~/.codex/auth.json里面存着 token 和账号信息。问题在于本地能用的 auth.json搬到阿里云服务器上经常直接 401或者报local proxy failed。原因通常是本地走了某个代理通道而服务器上没有同样的出口或者 token 绑定了本地环境。TaoToken 在这里的作用是提供一个统一的 API 通道和 Key把 Codex 的 Base URL 指向一个稳定的入口这样 auth.json 里不再依赖本地代理服务器上也能直接发请求。下面我会按「先解决远程访问再解决模型接入最后验证连通性」的顺序把每一步的配置片段都给出来你可以直接复制改。需要提前说明的是本文不涉及任何网络加速工具所有操作都在阿里云服务器自身的网络环境内完成。TaoToken 的接入地址是https://taotoken.net/api官网是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content后面配置里会反复用到。2. TaoToken 前置准备统一 Key 与 API 通道的获取和校验在动 Openclaw 配置之前先把 TaoToken 这边的准备工作做完。这一步的核心是拿到一个可用的 API Key并确认https://taotoken.net/api这个 Base URL 在你的阿里云服务器上能通。很多人跳过这步直接改 auth.json结果 401 报错查半天其实是 Key 没生效或者网络不通。首先登录 TaoToken 控制台。打开https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content在控制台里找到 API Keys 页面路径是https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。新建一个 Key命名建议带上用途比如openclaw-aliyun-codex方便以后区分。创建后立刻复制保存页面刷新后就看不到完整 Key 了。拿到 Key 之后先在服务器上做一次最朴素的连通性测试不要急着改 Openclaw。用 curl 直接打 TaoToken 的 API 端点curl -sS -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}], max_tokens: 16 }如果返回里能看到choices字段和一段回复内容说明 Key 和 Base URL 都没问题。如果返回 401检查 Key 是否复制完整、有没有多余空格如果返回连接超时检查阿里云 ECS 的出方向安全组是否放行了 443 端口以及服务器 DNS 是否正常。这一步过了后面 Openclaw 和 Codex 的配置才有意义。关于模型选择TaoToken 支持多种模型 ID你在 Openclaw 的models/providers里列出的模型名要和 TaoToken 侧支持的模型 ID 对得上。常见的编码类模型可以直接用gpt-4o、claude-3-5-sonnet这类 ID。如果你不确定某个模型 ID 是否可用可以在模型对话页面https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content里手动选一下能正常对话就说明这个 ID 有效。还有一个容易被忽略的点TaoToken 的 Base URL 是https://taotoken.net/api注意结尾没有斜杠。有些工具会在后面自动拼/v1/chat/completions有些则要求你写全。Codex 的 auth.json 和 Openclaw 的 provider 配置对 Base URL 的处理方式不同下面会分别说明。建议你在服务器上把 Key 存到一个环境变量文件里比如~/.taotoken.env权限设为 600避免明文散落在多个配置文件里。echo export TAOTOKEN_API_KEYsk-你的TaoTokenKey ~/.taotoken.env chmod 600 ~/.taotoken.env source ~/.taotoken.env这样后面写配置时可以用$TAOTOKEN_API_KEY引用减少泄露风险。准备工作做到这里就够了接下来进入 Openclaw 本身的远程访问配置。3. 可复制配置openclaw.json 放开 HTTP 与 Codex auth.json 接管这一节是全文的核心分两块先改~/.openclaw/openclaw.json让 Control UI 能从公网 HTTP 访问再改~/.codex/auth.json把 Codex 的请求指向 TaoToken。先看 Openclaw 的网关配置。文件路径是~/.openclaw/openclaw.json注意不同安装方式下可能是/home/用户名/.openclaw/openclaw.json。用编辑器打开找到gateway段改成下面这样{ gateway: { port: 18789, mode: local, bind: lan, controlUi: { allowInsecureAuth: true, dangerouslyDisableDeviceAuth: true } } }这里三个点要解释清楚。bind从默认的local改成lan是让网关监听所有网卡而不是只监听 127.0.0.1否则公网 IP 根本连不进来。allowInsecureAuth设为 true是允许在非 HTTPS 上下文下进行认证这正是 HTTP 远程访问能打开的关键。dangerouslyDisableDeviceAuth设为 true是关掉设备认证否则新设备首次访问会被拦。名字里带dangerously不是吓唬人它确实降低了安全门槛所以务必配合阿里云安全组只放行你自己的出口 IP 到 18789 端口不要对0.0.0.0/0开放。改完 gateway再确认会话默认模型。同一个文件里找到agents段{ agents: { defaults: { model: { primary: gpt-4o } } } }这个primary的值必须出现在models/providers列表里否则 Openclaw 启动时会报模型未注册。你可以在会话里用/model 模型ID临时切换但默认值还是以这里为准。接下来是 Codex 的 auth.json。路径是~/.codex/auth.json。如果你本地已经有这个文件不要直接复制过来因为里面的 token 可能绑定了本地环境。正确做法是在服务器上重新生成或改写把 Base URL 指向 TaoToken。一个可用的 auth.json 结构如下{ OPENAI_API_KEY: sk-你的TaoTokenKey, OPENAI_BASE_URL: https://taotoken.net/api, tokens: { access_token: sk-你的TaoTokenKey, refresh_token: , account_id: } }这里的关键是OPENAI_BASE_URL指向https://taotoken.net/apiOPENAI_API_KEY和tokens.access_token都填 TaoToken 的 Key。有些 Codex 版本读的是OPENAI_API_KEY有些读tokens.access_token两个都填上最稳妥。refresh_token和account_id留空即可因为 TaoToken 走的是 API Key 认证不需要 OAuth 刷新流程。如果你用的是 Codex CLI 的较新版本它可能还认一个~/.codex/config.toml里面可以显式指定 providermodel_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY这个 TOML 片段和 auth.json 配合使用env_key指向你之前设的环境变量。这样 Codex 启动时会优先读 config.toml 里的 provider再用 auth.json 里的 Key 去认证。三件套凑齐Base URL 是https://taotoken.net/apiKey 是 TaoToken 的sk-开头字符串Model ID 是gpt-4o或你选定的编码模型。改完两个文件后重启 Openclaw 服务systemctl --user restart openclaw # 或者如果是系统级服务 sudo systemctl restart openclaw重启后确认端口监听状态ss -tlnp | grep 18789应该能看到0.0.0.0:18789或*:18789而不是127.0.0.1:18789。如果是后者说明bind没生效检查 JSON 是否有语法错误可以用python3 -m json.tool ~/.openclaw/openclaw.json校验。4. 验证请求从 Control UI 到 Codex 的完整连通性测试配置改完不代表能用必须做端到端验证。这一节我按「先 UI 后 Codex」的顺序给你一套可复现的验证流程。第一步浏览器访问 Control UI。在你自己电脑上打开http://你的阿里云公网IP:18789。如果页面正常加载出登录或控制界面说明 gateway 的bind和allowInsecureAuth都生效了。如果还是打不开回到上一节检查安全组和 JSON 语法。注意这里用的是 HTTP不是 HTTPS因为我们显式放开了不安全认证。如果你更倾向 HTTPS可以后续用 Tailscale 或自签证书但那是另一条路径本文不展开。第二步在 Control UI 里发一条测试消息。进入会话界面输入/model gpt-4o确认当前模型然后发一句「用 Python 写一个快速排序」。如果 Openclaw 返回了代码说明会话模型这条链路通了。这一步走的是 Openclaw 自己的 provider 配置和 Codex 的 auth.json 是两条独立的路径但都指向 TaoToken。第三步验证 Codex 侧。在服务器上直接跑 Codex CLIcodex print hello world in python如果 Codex 正常返回代码说明 auth.json 和 config.toml 生效了。如果报 401先检查echo $TAOTOKEN_API_KEY是否有值再检查 auth.json 里的 Key 是否和它一致。如果报local proxy failed说明 Codex 还在尝试走本地代理检查是否有HTTP_PROXY或HTTPS_PROXY环境变量残留env | grep -i proxy有的话 unset 掉或者在 Codex 配置里显式禁用代理。TaoToken 的接入不需要任何代理直连https://taotoken.net/api即可。第四步做一次带choices字段校验的请求。有时候请求返回 200但内容为空问题出在响应解析上。用 curl 打一次完整请求把返回存下来看结构curl -sS -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: reply with the word ok}], max_tokens: 8 } | python3 -m json.tool正常返回里应该有choices: [{message: {content: ok}}]这样的结构。如果choices是空数组或者报reading choices相关错误通常是模型 ID 不对或者请求体格式有问题。确认model字段的值和 TaoToken 侧支持的 ID 一致。第五步把 Openclaw 和 Codex 串起来测一次。在 Control UI 里触发一个需要 Codex 执行的任务比如「在当前目录创建一个 test.py 并写入 hello」。观察 Openclaw 日志journalctl --user -u openclaw -f如果日志里能看到 Codex 的调用记录并且最终文件被创建说明整条链路打通了。这一步能过基本就没什么大问题了。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth配置过程中最容易撞上的就是这几类报错我按实际遇到的频率排一下每个都给出定位方法和修复动作。401 Unauthorized。这是最高频的。表现是请求返回{error: {message: Invalid API key}}或类似。排查顺序第一确认 Key 没有多余空格或换行echo $TAOTOKEN_API_KEY | wc -c看长度是否合理第二确认 auth.json 里的 Key 和 curl 测试用的是同一个第三确认 Base URL 是https://taotoken.net/api没有多写/v1或少写https。如果 Key 是在控制台刚创建的等几秒再试有时候有缓存延迟。还有一种情况是 Key 被禁用或额度耗尽去https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content确认状态。local proxy failed。这个报错通常出现在 Codex CLI 启动时提示无法连接本地代理。根因是 Codex 默认会尝试走127.0.0.1上的某个代理端口而服务器上并没有跑那个代理。修复方法是清掉代理环境变量并在 Codex 配置里显式指定 provider 为 TaoToken。检查~/.codex/config.toml是否有model_provider指向了本地代理改成taotoken。同时确认env | grep -i proxy输出为空。reading choices 相关错误。表现是请求返回 200但解析响应时抛异常日志里出现reading choices或cannot read property of undefined。这通常是响应体结构和预期不符。用上一节的 curl 命令看原始返回确认有choices数组。如果没有可能是模型 ID 写错TaoToken 返回了错误信息但被当成正常响应解析了。把model字段改成确认可用的 ID比如gpt-4o。OAuth 相关报错。如果你之前用 Codex CLI 登录过官方账号auth.json 里可能有 OAuth 的refresh_token和account_id。搬到服务器后Codex 可能尝试用这些 token 去刷新结果失败。修复方法是把refresh_token和account_id清空只保留 API Key 认证。TaoToken 走的是 Key 认证不需要 OAuth 流程。如果你在 config.toml 里看到preferred_auth_method chatgpt之类的配置改成apikey。Control UI 打不开但端口在听。检查阿里云安全组入方向是否放行了 18789且来源 IP 限制为你自己的出口 IP。再检查openclaw.json里bind是否为lanallowInsecureAuth是否为 true。如果都对了还是不行看 Openclaw 日志有没有insecure context相关警告有时候需要同时设置dangerouslyDisableDeviceAuth。模型未注册。Openclaw 启动时报model not found in providers。检查agents.defaults.model.primary的值是否在models.providers列表里。两个地方的名字必须完全一致大小写敏感。如果你在会话里用/model临时切换那个模型也必须已注册。排查时建议开两个终端一个跑journalctl -f看日志一个执行操作这样报错和动作能对上。大部分问题集中在 Key、Base URL、模型 ID 这三个变量上逐个确认基本都能解决。6. 长期编码与 Agent 场景下的 TaoToken 接入建议把 Openclaw 跑在阿里云服务器上配合 TaoToken 统一 Key最大的好处是环境稳定、不依赖本地机器。你可以在服务器上挂长期运行的 Agent 任务比如定时拉代码、跑测试、生成文档而 Codex 的 auth.json 和 Base URL 一旦配好就不用再动。我自己的做法是把~/.taotoken.env作为唯一 Key 来源auth.json 和 config.toml 都引用它这样换 Key 只改一个文件。如果你打算把 Openclaw 用在更重的编码场景比如多轮 Agent 协作、长上下文代码库分析建议关注 TaoToken 的 Coding Plan。它针对长期编码和 Agent 调用做了额度与稳定性优化入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。对于需要频繁调用模型的场景比按次计费更划算。另外几个实用建议。第一Control UI 的 HTTP 访问虽然方便但安全组一定要收紧只放行你的固定出口 IP不要图省事开0.0.0.0/0。第二auth.json 权限设为 600chmod 600 ~/.codex/auth.json避免其他用户读到 Key。第三定期在 TaoToken 控制台轮换 Key轮换后同步更新~/.taotoken.env并重启 Openclaw 和 Codex。第四如果你在会话里临时切模型记得/model只影响当前会话重启后还是回到openclaw.json里的默认值。关于模型 ID 的选择编码类任务优先用gpt-4o或claude-3-5-sonnet这两个在代码生成和长上下文理解上表现稳定。如果你不确定某个 ID 是否可用先去模型对话页面https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content手动试一次能正常对话再写进配置。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content里面有各工具的 Base URL 和参数说明配置卡住时对照一下。最后说一个我踩过的坑Openclaw 升级后openclaw.json的字段结构偶尔会变比如controlUi下面的键名调整。升级前先备份配置文件升级后对比默认配置把自定义项重新填进去。Codex 的 auth.json 结构相对稳定但 config.toml 的 provider 写法在不同版本间有差异遇到解析错误时优先看官方文档的示例。把这些都理顺之后阿里云服务器上的 Openclaw 加 TaoToken 这套组合基本可以做到一次配置、长期使用。