把短信变成 HTTP：用 Cloudflare Worker 实现跨设备短信转发
一次真正“跨设备”的短信转发实践
用 Cloudflare Worker 把短信安全推送到你的 iPhone
在日常工作中，我们经常遇到这样的场景：
-
验证码发到了 备用手机 / 安卓手机 / 老设备
-
SIM 卡插在 测试机、值班机、4G 网关
-
人却不在设备旁边，或者设备不方便查看
如果短信只能停留在“接收设备”上，那它的价值其实被大大限制了。
这篇文章分享一套已经落地验证、可长期运行的方案：
把短信内容通过 HTTP POST 上报到 Cloudflare Worker，再实时推送到 iPhone。
不依赖私有接口、不破解系统、不走灰色路线，
而是用一套标准、可扩展的工程化架构来解决问题。
项目地址:
https://github.com/lengmuning/forwarder-sms一、整体思路：把“短信”变成一个 Web 事件
这套方案的核心思想其实非常简单：
不要执着于“短信怎么转发”，
而是把短信当成一个“事件”，通过 HTTP 标准接口上报。
一旦短信变成了 HTTP POST 请求，那么它就：
-
不再绑定某个设备
-
不再绑定某个平台
-
可以被任何系统接收、处理、转发
整体架构示意
短信接收设备
（手机 / 系统 / 服务）
↓
HTTP POST（JSON）
↓
Cloudflare Worker
↓
Bark 推送
↓
iPhone 实时通知在这个架构里：
-
Cloudflare Worker 是统一入口
-
Bark 负责 iPhone 侧通知
-
各种设备只负责一件事： 👉 把短信内容 POST 上来
二、核心组件说明
1️⃣ Cloudflare Worker：短信上报与分发中心
Worker 在整个系统中扮演的是：
“短信 Webhook 网关 + 通知分发器”
它的职责非常清晰：
-
接收标准 HTTP POST 请求
-
解析短信内容
-
做基本安全校验
-
调用 Bark API 推送到 iPhone
Worker 的最小接口约定
{
"device": "来源设备标识",
"content": "短信正文",
"timestamp": 1730000000
}只要任何设备能满足这个接口约定，就可以接入。
2️⃣ Bark：iPhone 通知接收端
Bark 是一个非常轻量、稳定的 iOS 推送工具：
-
不需要 Apple 开发者账号
-
不依赖 APNs 私有能力
-
支持自建 / 官方服务
在这套方案中，Bark 的角色非常单一但重要：
负责把“已经处理好的短信内容”可靠送达 iPhone
你可以在 iPhone 上：
-
多设备同时接收
-
分组展示短信通知
-
作为后续自动化的触发源
三、部署方式（实战向，不讲调试）
1️⃣ 部署 Cloudflare Worker
部署方式非常轻量：
-
一个 Worker 服务
-
可选绑定自定义域名
-
不需要服务器、不需要公网 IP
基本步骤概览
-
创建 Cloudflare Worker
-
配置环境变量（API Token、Bark Key）
-
部署代码
-
获得一个 HTTPS 接口地址
完成后，你会得到一个类似这样的接口：
https://sms.yourdomain.com/api/sms/forward这个地址，就是整个系统的唯一入口。
2️⃣ iPhone 侧（接收端）
iPhone 只需要做一件事：
-
安装 Bark
-
配置好 Bark Key
后续不管短信来自哪里，只要进入 Worker，就能实时推送到 iPhone。
四、这个系统可以对接哪些“短信来源”？
这是这套方案最有价值的地方。
因为 Worker 只关心 HTTP POST，
所以它天然支持多来源、多平台、多设备。
✅ 1️⃣ Android 手机
Android 是最理想的上报端之一：
-
自动化能力强
-
HTTP 支持完整
-
长期后台运行稳定
常见实现方式：
-
Tasker + 插件
-
自定义 App
-
短信通知监听 → POST
非常适合：
-
工作手机
-
备用机
-
双卡设备
✅ 2️⃣ iOS（新版本）
在较新的 iOS 版本中：
-
可通过快捷指令自动化
-
短信 → HTTP POST → Worker
适合：
-
个人使用
-
临时转发
-
轻量场景
✅ 3️⃣ Linux / 服务器 / 网关设备
如果短信来自于：
-
4G/5G 短信猫
-
工业网关
-
云短信平台
那么可以直接：
-
用脚本
-
用 Webhook
-
用程序
把短信内容 POST 到 Worker。
✅ 4️⃣ 第三方短信平台
很多云短信服务都支持：
-
状态回调
-
内容回调
-
Webhook 通知
这类平台几乎可以零改造接入：
把回调地址指向 Worker 即可。
五、为什么这套方案“值得用在生产环境”
✔ 架构足够干净
-
HTTP + JSON
-
无私有协议
-
无系统破解
✔ 扩展性极强
-
新设备 = 新 POST 源
-
不影响现有系统
✔ 平台解耦
-
设备问题在设备侧解决
-
Worker 永远不变
✔ 长期可维护
-
不依赖系统漏洞
-
不随系统升级失效
六、可以继续演进的方向
这套架构并不止步于“短信转发”：
-
不同短信 → 不同 iPhone
-
验证码自动识别、高亮
-
短信 → 企业微信 / 邮件 / IM
-
短信作为业务事件触发自动流程
**它更像一个“短信事件中枢”，而不是一个小工具。 *
七、结语
如果把短信仍然当成“只能在一部手机上看的东西”，
那它的价值就被锁死在设备里。
而一旦你把它抽象成：
“一个可以被系统消费的事件”
短信，就真正进入了你的数字化体系。