自建 AI API 全链路：从域名邮箱到 Sub2API
这篇文章本来是写给朋友看的，顺手整理一下发出来。
假设你之前没折腾过域名邮箱、Cloudflare Workers、接码平台、注册机、AI API 中转这些东西，我尽量按"为什么要做这一步"和"怎么确认这步做对了"来讲。中间卡住了可以直接把报错丢给 AI 问，实测 Codex 对这类部署文档和配置排错的理解还行。不过 API Key、密码、Cookie、Token 这些东西，发给 AI 之前先脱敏，别问我怎么知道的。
整套东西搭完就是这个结构：
- 一个自己的域名，用来生成邮箱地址
- 部署在 Cloudflare 上的临时邮箱服务，收验证码邮件
- 一个接码平台，收短信验证码
- 一个注册机，把邮箱、短信验证码这些步骤串起来
- 一个 Sub2API 服务，统一接入和分发 AI API
先说清楚边界：这篇文章只记录自用环境搭建和测试流程。请遵守目标服务的使用条款，不要用于未经授权的自动化注册或滥用资源。
先把几个名词讲清楚
已经懂的可以直接跳后面。
域名
域名就是你在互联网上买的一个名字，比如 example.com。有了域名之后，你可以配很多邮箱地址：a@example.com、test@example.com、anything@example.com，后面就是用自己的域名来收注册验证码。
DNS
DNS 是域名的路标系统。你在 Cloudflare 里加的各种记录，就是告诉互联网：访问这个域名的时候去哪里找对应的服务。这篇教程会用到 DNS，是因为邮箱、子域名和 Cloudflare 服务都需要靠 DNS 指过去。
Cloudflare
Cloudflare 是一个常用的域名托管和网络服务平台。这里主要用它做三件事：管理域名 DNS、部署 cloudflare_temp_email、绑定自己的邮箱域名或子域名。
临时邮箱
临时邮箱就是用来收邮件的轻量服务。我们会用 cloudflare_temp_email 部署一个自己的临时邮箱，让自己的域名可以接收验证码邮件。
接码平台
有些注册流程除了邮箱验证码还要短信验证码。接码平台就是提供临时手机号收短信的。我目前用的是 Hero SMS。这不是广告，没有推广返利，只是我自己在用的。你完全可以换别的，只要注册机支持，或者你能把接口适配进去就行。
注册机
注册机就是把注册流程自动化的工具。它一般需要：邮箱收验证码、接码平台收短信验证码、稳定的网络环境、一份配置文件告诉它每一步怎么做。
我用的是 linux.do 里的这个帖子：https://linux.do/t/topic/2129705。这个帖子在 linux.do 的 3 级区，非 3 级用户可能看不见。如果是 2 级用户，可以站内搜类似关键词，通常 2 级区也有一些方案。拿到注册机之后不建议直接运行，至少先通读配置、依赖和网络请求部分。
Sub2API
Sub2API 不是网络代理工具，也不是"把代理订阅转成 API"的东西。它是一个 AI API 网关平台，把 Claude、OpenAI、Gemini 等上游账号或 API 接入同一个后台，再给下游工具分发 API Key。
用人话说就一件事：
上游 AI 账号/API/订阅额度 -> Sub2API -> 统一的 API Key 和接口地址 -> 下游工具调用它负责：管理多个上游账号或 API Key、给用户生成可调用的 API Key、鉴权/计费/限速/并发控制、多上游之间调度请求、后台页面查看用户和用量。官方仓库是 Wei-Shaw/sub2api。
整体流程
先看总路线，后面再展开：
- 买一个域名
- 把域名接入 Cloudflare
- 部署 cloudflare_temp_email
- 配置主域名邮箱和子域名邮箱
- 注册接码平台并拿到 API Key
- 部署或配置 Sub2API，提前建好接收账号的分组
- 准备注册机，检查配置
- 先单账号跑一次注册流程
- 把注册结果导入 Sub2API
- 在 Sub2API 后台生成下游 API Key，测试调用
不要一上来就追求全自动跑通。第一次搭的时候，每一步单独测试，确认没问题再进下一步。这不是在给你灌鸡汤，这是真的踩过坑之后得出的结论——一边改 DNS、一边改环境变量、一边跑注册机，出了问题根本不知道该查哪里。
准备材料
开始前需要准备的：
| 需要 | 用来做什么 |
|---|---|
| 域名注册商账号 | 买域名 |
| Cloudflare 账号 | 托管 DNS、部署邮箱服务 |
| Hero SMS 或其他接码平台账号 | 收短信验证码 |
| 能跑真实浏览器的本地环境 | 执行注册机流程，Chrome 或 Edge |
| 注册机文件或项目地址 | 按原帖说明准备 |
| Sub2API 服务 | 统一管理和分发 AI API |
| 上游 AI 账号或 API Key | 接入 Sub2API 作为可调用资源 |
| 服务器或 Docker 环境 | 部署 Sub2API |
只是先看教程的话可以不急着买域名，但真正跑流程的时候，域名、Cloudflare 和接码平台基本绕不开。
一、买域名
第一步是买一个自己的域名。不需要很贵，普通后缀就行。
选择域名时注意几点：尽量短一点，后面填配置方便；不要太像批量注册用的那种域名；选常见后缀，少用冷门的；先查一下有没有明显黑历史。一个之前被拿去发过垃圾邮件的域名，后面收验证码会非常痛苦。
买完之后，找到域名后台里的 Nameserver 或 DNS Server 设置，因为下一步要把域名交给 Cloudflare 管。不同注册商的入口名字不一样，常见位置在"域名管理"“DNS 管理"“Nameserver"这类菜单里。
二、把域名接入 Cloudflare
目标是让 Cloudflare 接管你的域名 DNS。
大概步骤：登录 Cloudflare → 添加站点 → 输入你刚买的域名 → 选免费计划 → Cloudflare 会给你两条 Nameserver → 回到域名注册商后台把原来的 Nameserver 改成 Cloudflare 给的 → 等待生效。
怎么确认做对了：
- Cloudflare 里显示域名已经 Active
- Cloudflare 的 DNS 页面能看到你的域名
- 后续添加 DNS 记录不会报错
这一步可能要等几分钟到几小时。第一次等 DNS 生效比较磨人，但它不是你配错了就一定会立刻报错的东西，所以不要一看没生效就反复改，改多了反而容易把自己改晕。
三、部署 cloudflare_temp_email
目标是搭一个可以收邮件的临时邮箱服务。
cloudflare_temp_email 是一个基于 Cloudflare 的临时邮箱项目，主要用到 Workers、Pages、D1 和 Email Routing。部署好以后，你可以用自己的域名收邮件：test@example.com、abc@example.com、anything@example.com，后面注册机就用这些邮箱地址接验证码。
项目入口：
- GitHub 仓库：dreamhunter2333/cloudflare_temp_email
- 部署文档：https://temp-mail-docs.awsl.uk
- 站内 2026 版图文教程：小白也能看懂的自建 Cloudflare 临时邮箱教程（域名邮箱）
- AI 辅助部署参考：用 Claude Code 部署 Cloudflare 临时邮箱，20 分钟搞定
这个项目的文档比较完整，官方给了命令行、Cloudflare 后台 UI、GitHub Actions 等部署方式。新手不想手动对着文档一点点配的话，可以把项目 README、部署文档和自己的域名情况交给 AI，让它帮你拆步骤、检查配置和排错。再次提醒，不要把真实 API Key、密码、后台 Token 发出去，需要排错时先脱敏。手动部署也没问题，站里应该也有相关教程。
这里最容易踩坑的是 Email Routing。域名 DNS 必须先托管到 Cloudflare，并在 Cloudflare 里启用 Email Routing、下发对应的邮件 DNS 记录。Worker 部署完成后，还要把该域名的 Catch-all 路由投递到 Worker。只部署 Worker 或 Pages 但没配 Email Routing / Catch-all，是收不到验证码邮件的。如果只是想先理解 Cloudflare 邮件路由、Catch-all 和转发邮箱怎么工作，可以先看站内这篇：Cloudflare 的无限域名电子邮箱转发。
零基础可以按这个最小路径走：
- 确认域名在 Cloudflare 里显示 Active
- 在 Cloudflare 的 Email Routing 里启用邮件路由
- 按 Cloudflare 提示添加或确认邮件 DNS 记录
- 部署 cloudflare_temp_email 的后端 Worker
- 创建并绑定项目需要的 D1 数据库
- 部署前端 Pages，或者按项目文档把前端资源挂到 Worker
- 在 Email Routing 里把 Catch-all 地址投递到这个 Worker
- 打开邮箱页面，创建或输入一个测试邮箱
- 先用常用邮箱发一封普通邮件测试
- 再找一个低风险场景测试验证码邮件
先让邮箱服务本身跑起来，再去接注册机。不要同时改 DNS、改环境变量、跑注册机，出了问题很难定位。
部署完先手动验证邮箱能不能收信。验证方法：打开部署好的邮箱页面 → 随便生成或输入一个测试邮箱 → 用常用邮箱给它发一封测试邮件 → 看页面能不能收到 → 再测试一次验证码邮件。
怎么确认做对了：
- 邮箱页面可以打开
- 测试邮件能收到
- 验证码邮件能收到
- 延迟在可接受范围内
- 注册机配置好邮箱渠道后，也能创建邮箱并读取邮件
普通邮件能收但验证码邮件收不到的话，可能是目标平台拦截、邮件路由没配好，或者域名信誉问题。域名信誉这东西挺玄学的，运气成分不小。
四、配置主域名邮箱和子域名邮箱
目标是让不同用途的邮箱互相分开，后面好排查问题。
最简单的方式是直接用主域名邮箱：test@example.com、user001@example.com、user002@example.com。
如果想把不同任务拆开，也可以用子域名：
| 子域名 | 示例邮箱 | 用途 |
|---|---|---|
| a.example.com | test@a.example.com | 任务 A |
| b.example.com | test@b.example.com | 任务 B |
| test.example.com | abc@test.example.com | 测试 |
好处是某一组邮箱出问题时不会影响其他组。配置时重点看 cloudflare_temp_email 的说明，它要求你添加哪些 MX、TXT、CNAME 或路由记录，就按它的要求填。主域名和子域名都要单独测试，不要默认主域名能收子域名就一定能收。
子域名也要单独启用 Email Routing，并单独配邮件 DNS 记录和 Catch-all。只在主域名 example.com 上启用 Email Routing，不会自动覆盖子域名。Cloudflare 不会帮你做这件事，得自己一个一个加。
新手建议先只用主域名跑通，比如先测试 test@example.com。主域名能稳定收邮件后，再去加子域名。子域名每加一个，就按"邮件 DNS 记录 + Catch-all + 实际收信测试"重复验证一次。
怎么确认做对了：
- 主域名邮箱可以收邮件
- 子域名邮箱可以收邮件
- 每个子域名都能单独测试
五、注册接码平台
目标是拿到一个可用的短信验证码接口。
我用的是 Hero SMS。再说一次，这不是广告，只是当前自用方案。接码平台很多，选哪个都行，关键是它能稳定收到你目标服务的短信。
新手建议：先小额充值测试，不要一上来就充一大笔；不要只看价格，看成功率；优先测试你实际要注册的服务；API Key 不要发给别人，也不要截图公开。接码平台的 API Key 泄露了，余额会被人刷光的，这种事在各个群里已经见过好几次了。
Hero SMS 入口是 https://hero-sms.com。注册后先找到余额、服务选择、号码获取和 API Key 页面。不同平台的菜单名称会变，但逻辑基本一样：充值余额 → 选择目标服务 → 获取号码 → 等待验证码 → 把 API Key 填到注册机里。
接码测试流程：
- 登录接码平台
- 选择国家或地区
- 选择目标服务
- 获取手机号
- 记录手机号和订单 / activationId
- 在目标服务里填写手机号
- 等待短信验证码
- 确认平台能显示验证码
怎么确认做对了：
- 能获取手机号
- 能收到短信验证码
- 验证码没有明显超时
- 平台余额扣费符合预期
如果注册机支持手工手机号模式，建议同时保存 activationId。有些脚本后续需要根据 activationId 查询短信状态，只保存手机号的话脚本可能要反查订单，反查失败就会卡住。
常见问题的优先排查方向：
- 获取不到号码：检查目标服务、国家地区、平台余额
- 有号码但收不到验证码：号码是否已被使用、目标服务是否支持该地区
- 验证码很久才到：平台延迟、运营商延迟、目标服务限流
- 扣费异常：平台订单状态、取消规则、余额流水
六、准备并检查注册机
目标是拿到注册机，但先别急着跑。
我用的是 linux.do 里的这个帖子：https://linux.do/t/topic/2129705。这个帖子在 3 级区，非 3 级用户可能看不见。看不到的话可以站内搜类似关键词，2 级区也有一些方案。搜索时优先看近期回复和标题状态，带"已关"“已死"“不可用"的帖子就别当主方案了。找到后建议让 AI 先帮你做一次安全检查，再根据自己的环境改配置。
这里不展开注册机内部细节，具体用法以原帖为准。从流程上理解，它是一个基于本地真实浏览器的自动化工具，核心作用是把短信验证码、邮箱验证码、登录授权结果或 API 凭证获取这些环节串起来。当前更稳的思路不是一上来追求全自动，而是先按半自动方式跑通：手机号、邮箱、验证码这些环节能手动就先手动，确认链路没问题后再逐步自动化。
它和前面几个服务的关系：
- 接码平台负责提供短信验证码
- cloudflare_temp_email 可以作为自建邮箱渠道，通常对应注册机里的 legacy 邮箱方式，用来创建邮箱和轮询邮箱验证码
- 邮箱也可以先手工操作，或者用注册机支持的其他邮箱渠道
- Sub2API 不是注册机的网络代理，而是后面接收和管理注册结果的 API 网关
如果你不熟悉代码，可以让 AI 或懂代码的人帮你重点看几个地方：有没有把邮箱、接码 API Key、账号密码发到陌生地址；有没有远程下载脚本并直接执行；有没有明显混淆、加密字符串或可疑域名；会不会把配置文件完整打印到日志；是否支持你正在用的邮箱、接码平台和目标服务；配置项有没有默认填了别人的地址或 Token。
注册机配置通常包含这些内容：
| 配置项 | 填什么 | 说明 |
|---|---|---|
| 邮箱域名 | example.com | 用来生成注册邮箱 |
| 邮箱服务地址 | 你的邮箱服务地址 | cloudflare_temp_email 的访问地址 |
| 邮箱后台口令 | 你的邮箱后台口令 | 使用自建邮箱渠道时一般需要 |
| 邮箱站点口令 | 按实际情况填写 | 邮箱站点启用了访问密码的话填 |
| 接码平台 API Key | 你的接码平台密钥 | 从 Hero SMS 或其他平台获取 |
| 手机号 / activationId | 按实际情况填写 | 手工接码时建议保存 |
| 网络配置 | 按你的环境填写 | 注册机需要代理或自定义网络环境时填 |
| Sub2API 导入配置 | 按你的后台填写 | 自动导入结果需要提前准备 |
| 目标数量 | 先填 1 | 第一次先单账号跑通 |
第一次运行前确认这些事：本地 Chrome 或 Edge 能正常打开目标网站；注册机依赖已经装好；配置文件能被正常读取；邮箱服务地址可以打开；邮箱渠道能创建邮箱或读取已有邮箱；接码平台能拿到手机号和验证码；如果要导入 Sub2API，后台地址、管理员账号和分组名都准备好了；目标数量设为 1。
第一次只跑一个账号，目的是看流程能不能完整走通，不是追求速度。
七、部署并配置 Sub2API
目标是搭一个自己的 AI API 网关，把上游账号或 API 统一管理起来，再给下游工具发可调用的 API Key。
Sub2API 的正确链路：
上游 AI 账号/API Key -> Sub2API 后台 -> 下游 API Key -> 工具或客户端调用它不是给注册机返回网络代理的。它更像一个"AI API 管理后台”：把上游 Claude、OpenAI、Gemini 等资源接进去，Sub2API 负责统一鉴权、转发、调度、用量统计和分发 API Key。
官方仓库：Wei-Shaw/sub2api
站内部署参考：sub2API 部署（Docker Compose 手动部署版）
官方 README 提供了三种部署方式：Docker Compose 适合新手，一次性带 PostgreSQL 和 Redis；脚本安装适合已有 PostgreSQL、Redis 和 systemd 管理经验的 Linux 服务器；源码编译适合开发或自定义改造。新手建议走 Docker Compose，把 PostgreSQL 和 Redis 一起编排好，少踩环境坑。
部署前确认：有一台可以访问的 Linux 服务器；已安装 Docker 和 Docker Compose；服务器防火墙放行了 Sub2API 使用的端口；你知道后台访问地址；管理员账号和密码能保存好；数据目录有持久化，方便以后备份和迁移。
部署完成后，打开 Sub2API 后台，按顺序做几件事：
- 创建或确认管理员账号
- 创建用于接收账号的分组
- 添加上游 AI 账号或 API Key
- 生成下游 API Key，在客户端或工具里填写 base_url 和 API Key
这里的"上游"就是你要接入 Sub2API 管理的账号或 API Key，“下游"就是拿着 Sub2API 生成的 Key 去调用的客户端或工具。
如果注册机支持自动导入 Sub2API，一般需要提前准备 Sub2API 后台地址、管理员账号、密码和分组名，这样注册流程跑完后结果可以直接进 Sub2API 的账号管理。如果没有开启自动导入，注册机通常只会把结果保存到本地文件，后面再手动导入或用脚本补传。
怎么确认做对了：
- Sub2API 后台能打开
- 管理员账号能登录
- 能添加上游账号或 API Key
- 能生成下游 API Key
- 用这个 API Key 能成功请求一次模型
八、单账号跑一次完整流程
前面每一步都单独测过之后，再开始跑注册机。
第一次建议这样测：目标数量设为 1 → 用一个测试邮箱 → 用接码平台获取一个号码 → 跑一次完整注册 → 把注册结果导入 Sub2API → 在 Sub2API 里生成一个下游 API Key → 用这个 Key 测试一次模型请求 → 看日志里卡在哪一步。
完整流程跑通的标志：
- 邮箱验证码能收到
- 短信验证码能收到
- 注册机能进入下一步
- Sub2API 能接入上游资源
- 下游 API Key 能正常调用
- 最终输出成功结果或明确失败原因
失败的时候不要改一堆配置。先判断卡在哪一层：
- 收不到邮件：域名 DNS、邮箱服务、验证码邮件是否被拦截
- 收不到短信：接码平台、国家地区、目标服务支持情况
- 注册机报错：配置文件、接口地址、API Key、日志
- Sub2API 不能登录：服务状态、端口、防火墙、管理员账号
- API Key 调不通：上游账号、模型权限、base_url、鉴权头、额度
常见问题
为什么先小额充值？
接码平台成功率不是固定的。同一个平台，换国家、换服务、换时间段，表现都可能不同。先小额测试可以避免充了钱用不了的尴尬。别问我怎么知道要特别提这一条的。
Cloudflare 已经 Active 了，为什么还是收不到邮件？
Cloudflare Active 只说明域名 DNS 已经托管过去了，不代表邮箱路由已经配好。优先检查 Email Routing 是否启用、邮件 DNS 记录是否下发、Catch-all 是否投递到 Worker。
主域名能收，子域名不能收？
子域名需要单独配置收信链路。主域名的 Email Routing 不会自动覆盖子域名。给子域名重复配置邮件 DNS 记录和 Catch-all 后，再单独发邮件测试。
Sub2API 后台能打开，但 API Key 调不通？
先检查上游账号或 API Key 是否可用，再看 API Key 绑定的分组、模型权限、余额、base_url 是否填对。后台能打开只说明服务启动了，不代表上游调用一定成功。
