TimeAmber
剪藏#ETHTEST . 数脊#剪藏

把短信变成 HTTP：用 Cloudflare Worker 实现跨设备短信转发

2026 年 1 月 29 日 约 1 分钟
分享Twitter / XTelegram微博

一次真正“跨设备”的短信转发实践

用 Cloudflare Worker 把短信安全推送到你的 iPhone

在日常工作中，我们经常遇到这样的场景：

  • 验证码发到了 备用手机 / 安卓手机 / 老设备

  • SIM 卡插在 测试机、值班机、4G 网关

  • 人却不在设备旁边，或者设备不方便查看

如果短信只能停留在“接收设备”上，那它的价值其实被大大限制了。

这篇文章分享一套已经落地验证、可长期运行的方案：

把短信内容通过 HTTP POST 上报到 Cloudflare Worker，再实时推送到 iPhone。

不依赖私有接口、不破解系统、不走灰色路线，

而是用一套标准、可扩展的工程化架构来解决问题。

Notion image

项目地址:

JAVASCRIPT
https://github.com/lengmuning/forwarder-sms

一、整体思路：把“短信”变成一个 Web 事件

这套方案的核心思想其实非常简单：

不要执着于“短信怎么转发”，

而是把短信当成一个“事件”，通过 HTTP 标准接口上报。

一旦短信变成了 HTTP POST 请求，那么它就：

  • 不再绑定某个设备

  • 不再绑定某个平台

  • 可以被任何系统接收、处理、转发

整体架构示意

JAVASCRIPT
短信接收设备
（手机 / 系统 / 服务）
        ↓
HTTP POST（JSON）
        ↓
Cloudflare Worker
        ↓
Bark 推送
        ↓
iPhone 实时通知

在这个架构里：

  • Cloudflare Worker 是统一入口

  • Bark 负责 iPhone 侧通知

  • 各种设备只负责一件事： 👉 把短信内容 POST 上来

二、核心组件说明

1️⃣ Cloudflare Worker：短信上报与分发中心

Worker 在整个系统中扮演的是：

“短信 Webhook 网关 + 通知分发器”

它的职责非常清晰：

  • 接收标准 HTTP POST 请求

  • 解析短信内容

  • 做基本安全校验

  • 调用 Bark API 推送到 iPhone

Worker 的最小接口约定

JAVASCRIPT
{
  "device": "来源设备标识",
  "content": "短信正文",
  "timestamp": 1730000000
}

只要任何设备能满足这个接口约定，就可以接入。

2️⃣ Bark：iPhone 通知接收端

Bark 是一个非常轻量、稳定的 iOS 推送工具：

  • 不需要 Apple 开发者账号

  • 不依赖 APNs 私有能力

  • 支持自建 / 官方服务

在这套方案中，Bark 的角色非常单一但重要：

负责把“已经处理好的短信内容”可靠送达 iPhone

你可以在 iPhone 上：

  • 多设备同时接收

  • 分组展示短信通知

  • 作为后续自动化的触发源

三、部署方式（实战向，不讲调试）

1️⃣ 部署 Cloudflare Worker

部署方式非常轻量：

  • 一个 Worker 服务

  • 可选绑定自定义域名

  • 不需要服务器、不需要公网 IP

基本步骤概览

  1. 创建 Cloudflare Worker

  2. 配置环境变量（API Token、Bark Key）

  3. 部署代码

  4. 获得一个 HTTPS 接口地址

完成后，你会得到一个类似这样的接口：

JAVASCRIPT
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

  • 短信作为业务事件触发自动流程

**它更像一个“短信事件中枢”，而不是一个小工具。 *

七、结语

如果把短信仍然当成“只能在一部手机上看的东西”，

那它的价值就被锁死在设备里。

而一旦你把它抽象成：

“一个可以被系统消费的事件”

短信，就真正进入了你的数字化体系。

原文地址: https://mp.weixin.qq.com/s?__biz=MzkzNTc4NjIwMg==&mid=2247484401&idx=1&sn=dd04c873f69b0498be5b4031f704c395&chksm=c3cd3886d26cbadbe2c299e209cbf5e8fe6ceb5d7f81895bf13a865fb164069019f597f023d2&mpshare=1&scene=1&srcid=0128Is8bJGJo7Ga8GosniAKQ&sharer_shareinfo=354e9541c76a86b734c410d0962f3a5a&sharer_shareinfo_first=354e9541c76a86b734c410d0962f3a5a#rd

相关文章