​

为了收验证码，多背一台手机，这事我太懂了。

一台主力机，一台工作号，一台海外号，或者一张专门收服务通知的 SIM 卡。卡本身还好，麻烦在每次登录后台、云服务、银行、交易所、开发者账号时，那台手机刚好不在手边。

httpSMS 的思路很直接：把一台旧 Android 手机变成短信网关。手机继续插着 SIM 卡、连着电、放在家里或办公室；你用网页、 API 或 Webhook 收发短信。

它适合开发者、小团队，也适合只想少带一台手机的人。

httpSMS 是一个开源项目，GitHub 仓库是 NdoleStudio/httpsms。项目说明里写得很直白：它可以让 Android 手机充当 SMS Gateway，通过简单的 HTTP API 发送和接收短信。

它有三块东西：

• • Android App：装在插卡手机上，负责真正收发短信
• • Web UI：管理手机、 API Key 、短信记录、 Webhook
• • API 服务：给程序调用，发送短信、查询短信、处理事件

公开仓库显示它采用 AGPL-3.0 许可证。官方服务入口是 https://httpsms.com，文档入口是 https://docs.httpsms.com，API 文档在 https://api.httpsms.com/index.html。

这类工具最适合做两件事。

第一，远程收验证码。旧手机留在固定位置，收到短信后通过 httpSMS 平台或 Webhook 转到你的系统里。

第二，把短信接进自动化流程。比如服务器报警、内部系统通知、表单提交后短信提醒、 CRM 给客户发通知。

它能解决什么痛点

少带一台手机

如果你有一张专门收验证码的卡，可以把它插到旧 Android 上。手机放在家里，保持联网和充电。以后验证码到了，可以在 Web UI 查看，也可以转发到自己的 Webhook 。

这对经常换设备、远程办公、管理多个账号的人很实用。

不再依赖虚拟号码

很多国家或地区买不到好用的虚拟号码。就算可以买，也经常遇到平台拒收、号码被回收、收不到一次性验证码的问题。

httpSMS 走的是你自己的实体 SIM 卡。平台看到的还是这个真实手机号，只是收发短信的入口变成了 HTTP API 。

用 API 管短信

官方 API 支持发送短信、查询短信、创建 Webhook 、管理手机和 API Key 。开发者可以把短信接到自己的业务系统里。

比如发送一条短信，可以调用 /messages/send：

curl -X POST 'https://api.httpsms.com/v1/messages/send' \
  -H 'x-api-Key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "content": "这是一条测试短信",
    "from": "+180****0199",
    "to": "+180****0100"
  }'

这里的 YOUR_API_KEY 换成自己的 Key 。不要把 Key 写进公开仓库，也不要发到群里。

最简单的上手流程

先用官方托管版跑通，不急着自托管。

1. 准备一台 Android 手机

最好选一台不再日常使用的 Android 机。插入要收短信的 SIM 卡，接上电源，连上稳定 Wi-Fi 或移动网络。

系统层面要做几件事：

• • 允许短信读取和发送权限
• • 关闭过度省电策略
• • 允许应用后台运行
• • 如果系统提示“受限设置”，按官方教程放开权限

很多国产 Android 系统会杀后台。收验证码这类场景，后台保活比功能列表更重要。

2. 注册 httpSMS 账号

打开：

https://httpsms.com

登录后进入后台，添加手机。后台会给你后续绑定和 API 使用需要的信息。

3. 安装 Android App

项目 README 里给的 Android App 下载入口是：

https://apk.httpsms.com/HttpSms.apk

也可以从 GitHub Releases 找安装包：

https://github.com/NdoleStudio/httpsms/releases

安装后按提示登录、授权短信权限、绑定手机号。

4. 建一个 API Key

后台里进入 API Key 相关页面，创建一个新的 Key 。建议给 Key 起一个容易识别的名字，比如：

home-otp-phone

然后把 Key 放到自己的密码管理器里。测试时可以临时放在环境变量里：

export HTTPSMS_API_KEY='YOUR_API_KEY'

公开文章里不要贴真实 Key 。团队里也不要把它写死在前端代码里。

5. 先发一条测试短信

确认手机在线后，用 API 发一条测试短信：

curl -X POST 'https://api.httpsms.com/v1/messages/send' \
  -H "x-api-Key: $HTTPSMS_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "content": "httpSMS 测试",
    "from": "+180****0199",
    "to": "+180****0100"
  }'

如果请求被接受，后续发送动作由 Android 手机完成。 README 里的流程是：API 收到请求，推送通知到 Android App，App 拉取消息，再调用系统短信能力发送。

怎么收验证码

收验证码的关键是 Webhook 。

当旧手机收到短信，httpSMS 可以把短信事件转发到你提供的回调地址。你可以把它接到自己的服务器、 n8n 、自动化平台、内部机器人，或者只写一个很小的接收服务。

创建 Webhook 时需要提供：

• • 回调 URL
• • 监听的手机号
• • 事件列表，比如 message.phone.received
• • signing key，用来验证请求签名

一个简化的创建示例：

curl -X POST 'https://api.httpsms.com/v1/webhooks' \
  -H "x-api-Key: $HTTPSMS_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com/httpsms-webhook",
    "phone_numbers": ["+180****0199"],
    "events": ["message.phone.received"],
    "signing_key": "YOUR_WEBHOOK_SIGNING_KEY"
  }'

真正使用时，signing_key 要换成随机长字符串，并且只保存在服务器端。

如果只是自己收验证码，可以先让 Webhook 做一件很简单的事：收到短信后，把“发信号码、收信号码、短信内容、时间”记录到数据库，或转发到你自己的私有通知渠道。

不要把验证码转发到公开群，不要把短信内容直接写进可公开访问的日志。

Python 接收 Webhook 示例

下面是一个最小 Flask 示例，只演示接收流程。生产环境要加签名校验、访问控制和日志脱敏。

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.post('/httpsms-webhook')
def httpsms_webhook():
    payload = request.get_json(force=True)

    event = payload.get('event')
    message = payload.get('message', {})

    if event == 'message.phone.received':
        sender = message.get('from')
        receiver = message.get('to')
        content = message.get('content')
        timestamp = message.get('timestamp')

        print({
            'from': sender,
            'to': receiver,
            'content': content,
            'timestamp': timestamp,
        })

    return jsonify({'ok': True})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

本地测试可以用内网穿透工具临时暴露地址。正式使用时，最好放在 HTTPS 域名后面，并做签名校验。

自托管怎么跑

如果你不想把短信内容经过官方托管服务，可以研究自托管。仓库提供了 docker-compose.yml，会启动 PostgreSQL 、 Redis 、 API 和 Web UI 。

先拉代码：

git clone https://github.com/NdoleStudio/httpsms.git
cd httpsms

复制环境变量模板：

cp web/.env.docker web/.env
cp api/.env.docker api/.env

然后按 README 准备这些外部依赖：

• • Firebase：用于 FCM 推送，让服务器通知 Android App 取消息
• • SMTP：用于账号和通知邮件
• • Cloudflare Turnstile：用于保护搜索接口，减少滥用
• • Android google-services.json：用于构建 Android App

准备好后启动：

docker compose up --build

默认 Web UI 在：

http://localhost:3000

API 在：

http://localhost:8000

自托管的难点不在 Docker，而在 Firebase 、安卓 App 构建、推送链路和后续运维。普通用户只想少带一台手机，先用官方托管版更省事。团队要处理敏感短信，再评估自托管成本。

安全边界要说清楚

httpSMS 很方便，但短信本身并不安全。尤其是验证码短信，里面往往直接关系到账户登录。

使用时至少注意这几件事：

• • 只接自己的手机和自己的 SIM 卡
• • 不要拿它做垃圾短信、骚扰短信或绕过平台规则
• • API Key 放在服务端，不放进前端页面
• • Webhook 必须用 HTTPS
• • Webhook 日志要脱敏，验证码不要长期明文保存
• • 用强随机 signing key，并在服务端校验签名
• • 旧手机要设置锁屏密码，最好只装必要应用
• • 手机长期插电时注意电池老化和安全
• • 运营商套餐、短信频率、当地法规仍然适用

官方 README 还提到端到端加密：可以设置加密 Key，让服务端无法直接看到短信内容。这个能力很有价值，但前提是你自己保管好 Key 。 Key 丢了，别人可能看不到内容，你自己也可能解不开。

它适合哪些人

如果你只是偶尔收一个验证码，手机都在手边，没必要折腾。

如果你有长期放在抽屉里的第二张卡，或者需要把短信接进工作流，httpSMS 就很合适。

典型场景包括：

• • 海外手机号放在家里，人在外面也能收验证码
• • 公司内部系统需要短信通知，但不想买一套短信网关硬件
• • 开发者做短信 API 测试，想用自己的实体手机
• • 小团队把客户短信、系统提醒、表单通知接入自动化工具
• • 旧 Android 手机重新利用，不再只当备用机吃灰

我的建议是先小范围试：一台旧手机、一张低风险 SIM 卡、一个只转发到私有渠道的 Webhook 。跑稳以后，再考虑接更重要的账号。

这类工具省的是“手机必须在手边”的麻烦。至于验证码和账号安全，还是要按高风险信息处理。

来源链接:

• • https://github.com/NdoleStudio/httpsms
• • https://httpsms.com
• • https://docs.httpsms.com
• • https://api.httpsms.com/index.html

阅读原文：点击这里