把闲置安卓手机变成可编程SMS网关，用HTTP API收发短信最新版

一、项目概览

NdoleStudio/httpsms 做了一件非常直白的事：把你抽屉里吃灰的那台安卓手机，变成一个可编程的短信网关。你调一个 HTTP 接口，手机就发出一条真实短信；手机收到的短信，则会被转发到你配置的 webhook 上。

不需要买虚拟号码，不需要给 Twilio 交每条 $0.0079，用的就是你自己手机套餐里那条短信通道。

截至 2026 年 10 月 6 日的真实数据：

• Stars：5,863 / Forks：1,063 / Open Issues：4
• 技术栈：Go（后端）+ Kotlin（Android）+ Nuxt/Vuetify（Web）
• 许可证：AGPL-3.0（注意：不是 MIT，有传染性）
• 创建时间：2022-05-29，最近推送 2026-10-05（四年老项目，仍在活跃维护）
• 官网：https://httpsms.com
• 官方数据：23,273+ 用户，平台每月收发超过 50 万条短信

二、为什么会有这个项目

作者的动机写在 README 里，很朴素也很真实：他来自喀麦隆，想用 API 自动收发短信，但很多国家根本不支持购买虚拟手机号，也找不到一个现成的、能用直觉的 HTTP API 通过实体手机收发短信的方案。

这决定了一个关键差异——httpSMS 不是”又一个 Twilio 平替”，它解决的是“我这个地区压根买不到虚拟号”和“我不想为每条短信付费”这两个具体问题。有人在评价区写道：他们国家的短信网关每条要 50 美分以上，httpSMS 是唯一负担得起的选择。

三、工作原理

你的应用 ──HTTP API──▶ httpSMS API ──▶ Push 队列 ──▶ FCM 推送
                            │                              │
                       返回 202 Accepted                    ▼
                                                     Android App
                                                          │
                                                   拉取消息内容
                                                          │
                                              调用 Android SMS API 发出
                                                          │
                            ◀── 发送结果 ──────────────────┤
                            ◀── 送达报告 ──────────────────┘

收到短信 ──▶ Android App ──▶ httpSMS API ──▶ 你的 Webhook 回调 URL

值得注意的是 API 是异步的：调用 /v1/messages/send 会立刻返回 202 Accepted，真正的发送由手机通过推送唤醒后完成。这也解释了为什么”手机离线”是这个方案最大的单点风险——所以项目专门做了离线邮件通知。

官方客户端

• Go：NdoleStudio/httpsms-go
• JavaScript/TypeScript：NdoleStudio/httpsms-node

官网还给出了 PHP、Python、Java、C#、cURL 的示例代码，即使没有官方 SDK 也能直接调。

// Go 发送一条短信
client := httpsms.New(httpsms.WithAPIKey("你的 API Key"))

client.Messages.Send(context.Background(), &httpsms.MessageSendParams{
    Content: "Your verification code is 123456",
    From:    "+18005550199", // 你的安卓手机号
    To:      "+18005550100",
})

四、核心功能

五、技术架构

工程质量有几个细节值得一提：

• README 由 doctoc 自动生成目录，结构规范
• CI 分 Web / API 两条工作流，接入了 Scrutinizer 代码质量与 Better Stack 可用性监控
• 有端到端集成测试：Docker 起 API + PostgreSQL + Redis，再配一个模拟安卓设备的 phone emulator，跑完整的收发生命周期；每次 push/PR 到 main 自动执行
• 有 Contributor Covenant 行为准则、Discord 社区、GitHub Sponsors

六、两种用法：托管 vs 自托管

方案 A：用官方托管服务（5 分钟上手）

1. 在 httpsms.com 注册，Settings 页面生成 API Key
2. 手机装 Android App，用 API Key 登录，授予短信读写权限
3. 关键一步：把 App 的电池优化设为「无限制」，否则手机休眠会漏掉推送
4. 调用 /v1/messages/send 开搞

方案 B：Docker 自托管（完全免费、数据自控）

git clone https://github.com/NdoleStudio/httpsms.git
cd httpsms
cp web/.env.docker web/.env
cp api/.env.docker api/.env
# 填入 Firebase / SMTP / Cloudflare Turnstile 配置
docker compose up --build

之后 Web 在 localhost:3000，API 在 localhost:8000。

自托管的三个前置依赖（都要自己准备）

1. Firebase 项目：FCM 推送 + Email/Password 登录 + service account 凭据 + Android 的 google-services.json。README 还贴心地提醒了一个坑——Firebase 的 email/password 登录有个 bug，需要关闭 email enumeration protection 才能正常登录
2. SMTP 邮件服务：用于手机长时间离线的告警（开发可用 Mailtrap）
3. Cloudflare Turnstile：/v1/messages/search 路由用它做人机校验防滥用

还有一个必须手动做的步骤：系统需要在 users 表里插一个 system user 来异步处理事件，且 ID 和 API Key 要和 .env 里的 EVENTS_QUEUE_USER_ID / EVENTS_QUEUE_USER_API_KEY 一致，改完还要重启 API 容器：

INSERT INTO users (id, api_key, email)
VALUES ('your-system-user-id', 'your-system-api-key', '[email protected]');

最后，Android App 要在 Android Studio 里把 google-services.json 换成你自己的，否则 FCM 不通。

七、适用场景

• 2FA / OTP 验证码：给自己开发的应用加短信验证，不买虚拟号
• 小商家预约提醒：用已有套餐的无限短信额度发本地营销
• IoT / 服务器告警：服务器宕机时走实体 SIM 卡发带外告警
• 隐私敏感通信：AES-256 端到端加密，服务端也读不到
• 虚拟号不可用的地区：这是作者最初要解决的核心场景

八、局限与风险（说在前面）

1. 仅 Android，没有 iOS。架构决定了必须能调系统短信 API，iPhone 上实现不了。
2. 手机就是单点。关机、断网、被系统杀后台 = 发不出短信。生产环境务必准备备用机 + 离线告警。
3. 运营商风控。短时间内大量发短信会被运营商判定为垃圾短信甚至停号——这就是 Back Pressure 限速功能存在的原因，别关掉它。
4. 只支持 SMS，不支持 MMS，也没有内置号码供给能力。
5. 自托管门槛不低。Firebase + SMTP + Turnstile 三件套，加上手动建 system user、重新编译 Android App，对非开发者不友好。
6. AGPL-3.0 许可。这是强 copyleft：如果你修改后对外提供网络服务，需要向用户提供源代码。想做商业二次开发的话，这条比 MIT 严格得多，务必先评估。
7. 合规提醒：批量短信在多数国家和地区都受监管（如中国的《通信短信息服务管理规定》、美国的 TCPA），需取得接收方同意并提供退订方式；请勿用于垃圾营销、验证码轰炸或任何未经授权的群发。

九、同类项目对比

十、总结

httpSMS 的价值主张极其清晰：用你已经付过费的短信额度，换一个可编程的短信 API。它不是要取代 Twilio，而是给”买不到虚拟号”和”不想按条付费”这两类人一个可行解。

四年的持续维护、5,863 Stars、1,063 Forks、完整的集成测试与端到端加密设计，让它的工程质量明显高于同类玩具项目。而 AGPL-3.0 + Docker 自托管，也让在意数据主权的团队有退路。

适合谁：独立开发者、小型商户、IoT/运维告警场景、虚拟号不可达地区的开发者。

不适合谁：需要 99.9% SLA 的生产关键业务（手机是单点）、iOS 用户、想把代码闭源商用的团队（AGPL 传染性）。

参考来源：GitHub 仓库 README 与元数据（AGPL-3.0）、httpsms.com 官网功能与定价页、docs.httpsms.com 文档、第三方评测与用户反馈。文中 Star 数与时间为 2026 年 10 月 6 日实际抓取数据。