1. 从零跑通 AI API 网关：域名、邮件、支付、上游渠道全链路拆解
AI API 网关说白了就是一个「统一收银台 + 统一调度中心」：对外只暴露一个域名、一套 Key，对内把请求分发到不同的上游模型渠道，同时把用户注册、额度计费、充值到账这些事全管起来。适合谁？适合手里有几个上游渠道、想给团队或小圈子做统一入口的开发者，也适合想把自己常用的模型能力包装成可计费服务的个人。我这次用的是 new-api 这套开源框架，它是 one-api 的增强分支，Go 后端加 React 前端，Docker 一条命令就能拉起来，自带用户系统、钱包、令牌管理和多渠道负载均衡。
但真正跑起来你会发现，框架本身只是骨架，真正决定这套服务能不能长期稳定运行的，是四个外围环节：域名解析、邮件发信、支付回调、上游渠道健康。这四个环节任何一个出问题，用户侧的表现都是「注册收不到邮件」「充值不到账」「调用频繁失败」，而这些问题排查起来往往比写代码还费时间。下面我按实际搭建顺序，把每一步的可复制配置和踩坑点都摊开讲，你可以直接照着改参数用。
2. TaoToken 前置准备：统一 Key 与 Base URL 的接入姿势
在动手配域名和支付之前，先把上游通道这块理清楚。TaoToken 在这里扮演的角色是「上游渠道提供方」——你不需要自己去维护一堆账号池，而是拿一个统一的 API Key 和 Base URL，把它作为一个渠道填进 new-api 的后台。这样做的好处是：上游的模型列表、计费口径、可用性都由对方维护，你这边只需要关心自己的用户和定价。
具体操作上，先去官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 注册账号，然后在控制台里生成 API Key。这个 Key 就是你填进 new-api「渠道管理」里的凭证。Base URL 用 https://taotoken.net/api，注意这个地址后面不加任何 UTM 参数，直接填进渠道的代理地址栏。模型 ID 这块，TaoToken 兼容 OpenAI 格式，所以你可以在渠道里勾选需要的模型，比如 gpt-4o、claude-3-5-sonnet 这类常见 ID，具体以控制台里列出的为准。
这里有个细节值得说：new-api 的渠道配置里，「代理」和「Base URL」是两个概念。如果你服务器在国内，可能需要给渠道配一个出站代理；如果服务器本身能直连，那 Base URL 直接填 https://taotoken.net/api 就行。我实测下来，把 TaoToken 作为一个独立渠道加进去，然后在「模型倍率」里按自己的定价策略设好倍率，用户侧调用时就会自动走这个渠道。如果你后面要接 Claude Code 或者做 coding plan 类的长期编码场景，建议单独建一个渠道分组，把稳定性和延迟更好的模型放进去，避免和普通对话请求抢资源。
另外提醒一句：API Key 生成后只显示一次，记得立刻存到密码管理器里。如果你打算用多个 Key 做轮询，可以在控制台多生成几个，然后在 new-api 里配成同一个渠道的多个 Key，框架会自动做负载均衡。
3. 可复制配置：Cloudflare DNS、邮件 SPF/DKIM 与支付回调
这一节是全文最干的部分，我把域名、邮件、支付三块的配置片段都写出来，你直接替换成自己的域名和参数即可。
3.1 Cloudflare DNS 记录
域名建议直接在 Cloudflare Registrar 买，续费同价，没有首年低价次年暴涨的套路，而且买完自动托管 DNS，SSL 也是开箱即用。假设你的网关域名是api.yourdomain.com，服务器 IP 是203.0.113.10，在 Cloudflare DNS 里加两条记录：
类型 名称 内容 代理状态 TTL A api 203.0.113.10 已代理 自动 CNAME www api.yourdomain.com 已代理 自动代理状态打开后，Cloudflare 会帮你挡掉一部分扫描和 DDoS，但要注意：如果你后面配 Webhook 回调，某些支付平台会校验源站 IP，这时候可能需要把对应子域切成「仅 DNS」模式。我的做法是主 API 域名走代理，Webhook 单独用一个hook.yourdomain.com走仅 DNS，这样两边互不影响。
3.2 邮件发信：SPF 与 DKIM 记录
邮件这块别用个人邮箱，批量发验证码很容易触发限制，而且大概率进垃圾箱。我用的是阿里云邮件推送，买资源包，日均几百封成本很低。配置时需要在 Cloudflare DNS 加两条 TXT 记录：
类型 名称 内容 TXT @ v=spf1 include:spf.dm.aliyun.com ~all TXT aliyun._domainkey v=DKIM1; k=rsa; p=MIGfMA0GCSq...（阿里云控制台生成）SPF 里的~all表示软失败，比-all温和一些，避免误伤正常邮件。DKIM 那串公钥在阿里云控制台「发信域名」里生成，复制过来即可。两条记录生效后，在 new-api 后台的 SMTP 设置里填：
SMTP 服务器：smtpdm.aliyun.com 端口：465（SSL） 发信地址：no-reply@yourdomain.com 用户名：你的阿里云发信地址 密码：阿里云生成的 SMTP 密码填完点「测试发信」，能收到就说明链路通了。这里踩过的坑是：发信地址必须和 SPF/DKIM 里配的域名一致，否则会被拒。
3.3 Stripe 与易支付回调配置
支付分两条线。国际用户走 Stripe，在 Stripe Dashboard 里建一个 Webhook Endpoint，URL 填：
https://api.yourdomain.com/api/stripe/webhook监听事件勾选checkout.session.completed和payment_intent.succeeded，然后把 Signing Secret 填进 new-api 的支付设置里。国内用户走易支付，回调地址填：
https://api.yourdomain.com/api/epay/notify易支付的商户 ID 和密钥填进后台对应字段。两个回调都建议先用测试模式跑一遍，确认订单状态能从「待支付」变成「已完成」，再切正式环境。
4. 验证请求：一次端到端调用与渠道健康检查脚本
配置填完不代表跑通，得实际发一次请求验证。最直接的方式是用 curl 打你自己的网关：
curl -X POST https://api.yourdomain.com/v1/chat/completions \ -H "Authorization: Bearer sk-你的网关令牌" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 10 }'如果返回里带choices字段和正常的content，说明网关到上游的链路是通的。如果报 401，先检查令牌有没有额度、有没有过期；如果报local proxy failed，多半是渠道的出站代理没配好。
渠道健康这块，new-api 自带定时检测，但我建议再加一个外部脚本做兜底。下面这个 Python 脚本可以放到服务器 cron 里，每 5 分钟跑一次，发现异常就发邮件告警：
import requests, smtplib from email.mime.text import MIMEText GATEWAY = "https://api.yourdomain.com/v1/chat/completions" TOKEN = "sk-你的网关令牌" def check(): try: r = requests.post(GATEWAY, headers={ "Authorization": f"Bearer {TOKEN}", "Content-Type": "application/json" }, json={ "model": "gpt-4o", "messages": [{"role": "user", "content": "health"}], "max_tokens": 5 }, timeout=15) return r.status_code == 200 and "choices" in r.text except Exception as e: print("check failed:", e) return False if not check(): msg = MIMEText("网关健康检查失败，请立即排查上游渠道。") msg["Subject"] = "AI Gateway Alert" msg["From"] = "no-reply@yourdomain.com" msg["To"] = "you@yourdomain.com" with smtplib.SMTP_SSL("smtpdm.aliyun.com", 465) as s: s.login("no-reply@yourdomain.com", "你的SMTP密码") s.send_message(msg)这个脚本的好处是不依赖 new-api 内部状态，直接从外部视角验证「用户能不能拿到结果」。我试过在渠道抖动的时候，new-api 后台还显示正常，但外部脚本已经连续失败两次，提前发了告警，争取到了切换渠道的时间。
5. 本篇常见错排查：401、local proxy failed、reading choices 与 OAuth 回调
搭建过程中最容易撞上的几类报错，我按实际遇到的频率排一下。
401 Unauthorized：分两种。一种是你调网关时令牌错了，检查Authorization头里的 Key 是不是 new-api 生成的令牌，而不是 TaoToken 的 Key。另一种是网关调上游时 401，这时候去渠道管理里看 TaoToken 的 Key 有没有过期、额度是不是用完了。如果用了 Claude Code 这类工具，注意它的auth.json里填的应该是网关地址和网关令牌，不是上游的。
local proxy failed：这个报错基本锁定在出站代理。new-api 的渠道设置里如果填了代理地址，但代理本身不通，就会报这个。排查顺序是：先在服务器上curl -x 代理地址 https://taotoken.net/api看通不通，不通就换代理或者去掉代理直连。如果服务器本身能直连，渠道里的代理栏留空即可。
reading choices 相关报错：通常是上游返回的 JSON 结构和你预期的对不上，比如上游返回了错误信息但 HTTP 状态码是 200。这时候去 new-api 的日志里看原始响应，多半是模型 ID 写错了，或者上游不支持你请求的那个模型。把模型 ID 换成控制台里明确列出的，再试一次。
OAuth 回调失败：GitHub 或 Google 登录配好后点授权，回来报redirect_uri_mismatch，说明 OAuth 应用里填的回调地址和实际请求的不一致。GitHub 那边填https://api.yourdomain.com/oauth/github，Google 那边填https://api.yourdomain.com/oauth/google，注意协议和域名都要完全一致，不能一个带 www 一个不带。
如果你用的是 CC Switch 或者 Cline 这类客户端接 MCP，配置里同样要写全三件套：Base URL 填https://taotoken.net/api，Key 填 TaoToken 的 Key，Model ID 填控制台里列出的模型。少任何一个都会连不上。
6. 把链路握在自己手里：后续维护与接入入口
这套东西跑通之后，日常维护其实不重，但有几件事建议固定下来。数据库定时备份必须配，new-api 的数据都在 MySQL 里，丢了用户和订单就麻烦了。上游渠道的健康检查脚本挂到 cron 上，告警邮件发到自己常看的邮箱。支付回调的日志单独存一份，对账的时候用得上。
如果你还没开始接，建议先把 TaoToken 的 Key 拿到手，在模型对话里试几个请求，确认模型可用性，再去配 new-api 的渠道。接入文档里有完整的 Base URL 和参数说明，照着填就行。等你把域名、邮件、支付、上游这四块都串起来，这套网关就算真正跑通了，后面加渠道、调倍率、做活动都是在这个骨架上改参数的事。
