# 自建 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 里的这个帖子：。这个帖子在 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](https://github.com/Wei-Shaw/sub2api)。 ## 整体流程 先看总路线，后面再展开： 1. 买一个域名 2. 把域名接入 Cloudflare 3. 部署 cloudflare\_temp\_email 4. 配置主域名邮箱和子域名邮箱 5. 注册接码平台并拿到 API Key 6. 部署或配置 Sub2API，提前建好接收账号的分组 7. 准备注册机，检查配置 8. 先单账号跑一次注册流程 9. 把注册结果导入 Sub2API 10. 在 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://github.com/dreamhunter2333/cloudflare_temp_email) - 部署文档： - 站内 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 的无限域名电子邮箱转发。 零基础可以按这个最小路径走： 1. 确认域名在 Cloudflare 里显示 Active 2. 在 Cloudflare 的 Email Routing 里启用邮件路由 3. 按 Cloudflare 提示添加或确认邮件 DNS 记录 4. 部署 cloudflare\_temp\_email 的后端 Worker 5. 创建并绑定项目需要的 D1 数据库 6. 部署前端 Pages，或者按项目文档把前端资源挂到 Worker 7. 在 Email Routing 里把 Catch-all 地址投递到这个 Worker 8. 打开邮箱页面，创建或输入一个测试邮箱 9. 先用常用邮箱发一封普通邮件测试 10. 再找一个低风险场景测试验证码邮件 先让邮箱服务本身跑起来，再去接注册机。不要同时改 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 入口是 。注册后先找到余额、服务选择、号码获取和 API Key 页面。不同平台的菜单名称会变，但逻辑基本一样：充值余额 → 选择目标服务 → 获取号码 → 等待验证码 → 把 API Key 填到注册机里。 接码测试流程： 1. 登录接码平台 2. 选择国家或地区 3. 选择目标服务 4. 获取手机号 5. 记录手机号和订单 / activationId 6. 在目标服务里填写手机号 7. 等待短信验证码 8. 确认平台能显示验证码 怎么确认做对了： - 能获取手机号 - 能收到短信验证码 - 验证码没有明显超时 - 平台余额扣费符合预期 如果注册机支持手工手机号模式，建议同时保存 activationId。有些脚本后续需要根据 activationId 查询短信状态，只保存手机号的话脚本可能要反查订单，反查失败就会卡住。 常见问题的优先排查方向： - 获取不到号码：检查目标服务、国家地区、平台余额 - 有号码但收不到验证码：号码是否已被使用、目标服务是否支持该地区 - 验证码很久才到：平台延迟、运营商延迟、目标服务限流 - 扣费异常：平台订单状态、取消规则、余额流水 ## 六、准备并检查注册机 目标是拿到注册机，但先别急着跑。 我用的是 linux.do 里的这个帖子：。这个帖子在 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](https://github.com/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 后台，按顺序做几件事： 1. 创建或确认管理员账号 2. 创建用于接收账号的分组 3. 添加上游 AI 账号或 API Key 4. 生成下游 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 是否填对。后台能打开只说明服务启动了，不代表上游调用一定成功。