1. 为什么要在 Cloudflare Worker 上接一层 TaoToken你可能已经有一个跑在 Cloudflare Worker 上的小服务想让它调用 Gemini Pro 这类模型但直接对接官方接口时认证链路、区域可用性、Key 管理这几件事叠在一起调试成本并不低。尤其是当你不止用一个模型今天 Gemini、明天 Claude、后天又换一个国产模型时每个平台一套 Key、一套鉴权方式Worker 里的代码会越写越乱。我自己的做法是Worker 只负责业务逻辑模型调用统一走一个兼容层。TaoToken 在这里扮演的就是这个统一入口——它提供 OpenAI 兼容的 API 通道你拿一个 Key 就能在 Worker 里用同一套请求格式去调不同模型。对个人开发者来说好处很直接Worker 侧的环境变量只需要维护一个TAOTOKEN_API_KEY模型切换只改请求体里的model字段不用动部署流程。这篇要解决的具体问题是你本地已经有一个 Worker 项目想给它加一份可复制的config.toml骨架把 TaoToken 的 Key 通过环境变量绑进去然后跑通一次能看见返回结果的调用。适合谁适合已经会wrangler基本命令、但不想在鉴权细节上反复踩坑的开发者。下面从配置到验证一步步来命令和参数都可以直接抄。2. TaoToken 前置准备Key 与通道确认在动 Worker 代码之前先把两样东西准备好一个可用的 API Key以及确认你要调用的模型 ID。这两样都在 TaoToken 的控制台里完成。访问 https://taotoken.net/api 可以拿到 API 的基础地址注意这个地址不带任何多余路径Worker 里拼接时用/v1/chat/completions这种标准 OpenAI 兼容路径即可。Key 的创建入口在控制台的 API Keys 页面生成后是一串以sk-开头的字符串复制下来先存好后面要写进 Worker 的 secret。这里有个容易忽略的点TaoToken 的 Key 是统一 Key也就是说同一个 Key 可以调不同模型你不需要为 Gemini Pro 单独申请一个。模型 ID 建议直接在模型对话页面确认一下当前可用的写法比如gemini-2.5-pro这类标识避免拼错导致 404。如果你后续打算长期在 Worker 里跑编码类或 Agent 类任务可以顺带看一下 Coding Plan 的说明它和按量调用在配额策略上不太一样提前了解能少走弯路。准备好这两样后先别急着写 Worker用一条 curl 在本地确认 Key 本身是通的。这一步能把「Key 问题」和「Worker 配置问题」提前分开排障时省很多时间。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: gemini-2.5-pro, messages: [{role: user, content: 只回复两个字通了}] }如果返回里choices[0].message.content有内容说明 Key 和通道都没问题可以进入 Worker 配置环节。如果报 401检查 Key 是否复制完整报 404检查模型 ID 拼写。3. config.toml 骨架与 Worker 环境变量绑定Cloudflare Worker 项目里wrangler.toml是部署配置的核心文件。很多人会把它和业务配置混在一起结果 Key 硬编码进仓库既不安全也不好维护。正确的做法是wrangler.toml只放非敏感的绑定声明真正的 Key 走 secret。下面是一份可以直接复制的wrangler.toml骨架重点看[vars]和 secret 的配合方式name gemini-proxy-worker main src/index.js compatibility_date 2024-11-01 [vars] TAOTOKEN_BASE_URL https://taotoken.net/api MODEL_ID gemini-2.5-pro # 注意TAOTOKEN_API_KEY 不写在这里用 wrangler secret 注入[vars]里的两项是明文配置改模型或改基础地址时直接改这里重新部署即可。而TAOTOKEN_API_KEY必须用 secret 方式绑定命令如下wrangler secret put TAOTOKEN_API_KEY执行后终端会提示你粘贴 Key 值粘贴回车即可。这个值不会出现在wrangler.toml里也不会进 git部署后 Worker 运行时通过env.TAOTOKEN_API_KEY读取。本地开发时可以在项目根目录建一个.dev.vars文件TAOTOKEN_API_KEYsk-你的Key.dev.vars记得加进.gitignore。这样本地wrangler dev和线上部署用的是同一套变量名代码不用改。Worker 侧读取配置的写法大致是这样放在src/index.js里export default { async fetch(request, env) { const baseUrl env.TAOTOKEN_BASE_URL; const apiKey env.TAOTOKEN_API_KEY; const model env.MODEL_ID; if (!apiKey) { return new Response(缺少 TAOTOKEN_API_KEY, { status: 500 }); } const body await request.json(); const upstream await fetch(${baseUrl}/v1/chat/completions, { method: POST, headers: { Authorization: Bearer ${apiKey}, Content-Type: application/json }, body: JSON.stringify({ model: model, messages: body.messages || [] }) }); return new Response(upstream.body, { status: upstream.status, headers: { Content-Type: application/json } }); } };这段代码的关键点是Key 从env读不落盘模型 ID 从[vars]读方便切换。部署用wrangler deploy本地调试用wrangler dev。4. 验证请求curl 命令与返回结果判读Worker 部署成功后wrangler deploy会输出一个*.workers.dev的地址。假设是https://gemini-proxy-worker.yourname.workers.dev现在用 curl 打一次确认整条链路通了。curl -X POST https://gemini-proxy-worker.yourname.workers.dev \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 用一句话说明你是什么模型}] }这里注意请求 Worker 时不需要再带Authorization因为 Key 已经在 Worker 内部注入了。如果你希望 Worker 对外也做一层保护可以在 Worker 里加一个自定义 header 校验但那是另一个话题。返回结果怎么判读正常情况你会看到类似这样的 JSON{ id: chatcmpl-xxx, object: chat.completion, model: gemini-2.5-pro, choices: [ { index: 0, message: { role: assistant, content: 我是一个大型语言模型…… }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 30, total_tokens: 42 } }重点看三个字段choices[0].message.content有内容说明模型正常返回model字段确认实际调用的模型和你配置的一致usage里的 token 数说明计费链路是通的。如果content为空但finish_reason是length说明被截断了检查请求参数。实测下来从 Worker 发出请求到拿到返回延迟主要取决于模型本身Worker 这一层几乎不增加可感知的耗时。如果你在本地wrangler dev里测试返回结构和线上一致可以放心先在本地调通再部署。5. 本篇常见错排查配置过程中最容易卡住的几个点我按出现频率列一下对照着查能省不少时间。401 Unauthorized九成是 Key 的问题。先确认wrangler secret put时粘贴的 Key 没有多余空格或换行再确认本地.dev.vars里的 Key 和线上是同一个。如果本地通、线上不通多半是 secret 没更新重新执行一次wrangler secret put覆盖即可。404 Not Found检查TAOTOKEN_BASE_URL是否写成了带/v1的地址。正确写法是https://taotoken.net/api路径拼接在代码里完成。另外确认模型 ID 拼写gemini-2.5-pro和gemini-pro是两个不同的标识。Worker 报 env 变量 undefinedwrangler.toml里[vars]的变量在env上能直接读到但 secret 必须通过wrangler secret put绑定后才存在。如果你在本地wrangler dev时没建.dev.varsenv.TAOTOKEN_API_KEY就是 undefined代码里那个if (!apiKey)判断会直接返回 500。请求体解析失败Worker 里用了await request.json()如果客户端发的是 GET 或空 body会抛异常。建议在解析前判断request.method POST或者用 try/catch 包一层返回更明确的错误信息。部署后地址访问超时确认compatibility_date不要太旧某些 fetch 行为在新版本运行时才稳定。另外检查 Worker 的出口请求是否被防火墙规则拦截正常情况下 Cloudflare 出口到 TaoToken 的通道是通的。排障时如果拿不准是 Key 还是代码问题最快的办法是回到第 2 节那条 curl用同一个 Key 直接打 TaoToken 的 API。curl 通而 Worker 不通问题一定在 Worker 配置curl 也不通问题在 Key 或模型 ID。6. 把 Key 管好把调用跑顺走到这里你应该已经拿到了一次可观测的返回结果。回头看整个链路真正需要长期维护的其实就两样wrangler.toml里的[vars]和 secret 里的 Key。模型切换改MODEL_IDKey 轮换重新wrangler secret putWorker 代码基本不用动。如果你后续要在 Worker 里跑更复杂的编码任务或 Agent 流程建议把请求封装成一个独立函数把重试和超时也加进去这样业务代码里只关心「发什么消息、拿什么结果」。Key 的管理入口在 API Keys 页面接入细节可以对照接入文档模型可用性在模型对话里随时验证。把这几处固定下来你的私人 Gemini Pro API 就算真正跑顺了。