Featured image of post 我想自建 SMS 接码平台,结果把全网开源方案翻了个底朝天

我想自建 SMS 接码平台,结果把全网开源方案翻了个底朝天

6 路并行搜出 243 个仓库,gh api 拉满活跃度,深挖 33 个开源项目,逐个读 README 和代码。结论很扎眼:没有任何一个开源项目是真正意义上的'接码平台',它们都只解决某一层。

本文所有 star 数、license、最后活跃时间均来自 gh api repos/OWNER/REPO 实测(2026-09-15),并由一轮对抗核验(怀疑者视角逐项复查)修正过 1 处。32 个项目逐个读了 README 与主要代码目录。这是一篇技术调研,不展开任何规避检测或灰产操作教程。

我想自建 SMS 接码平台,结果把全网开源方案翻了个底朝天

起因很简单:我想把自己手里几个号的短信验证码集中管起来——一来多号收码方便,二来不想再受公共接码网站隐私裸奔的气。本以为这种需求开源界早有现成轮子,拉一个 docker-compose 就能跑。结果一通搜下来,扎眼的事实摆在面前:

全网没有一个开源项目是真正意义上的"接码平台"。

所谓真正意义上的接码平台,我给的标准是五件套齐全:号码池管理 + 取号租号 + 收码展示 + 多用户体系 + 计费订单——也就是 sms-activate、5sim、SMSPool 那种对外卖号收码的形态。开源世界里这五件套一个都没有现成的。所有项目都只解决某一层:转发层、设备层、协议层、网关层、上游聚合层。要自建,得自己把这几层拼起来。

怎么搜的

6 路并行扫:GitHub 中英文 gh search repos(接码/短信转发/虚拟号码/sms-activate/virtual number/sms gateway/sim bank 等几十组关键词)、Tavily、Grok、秘塔(metaso)中文源、以及 Hacker News/Reddit/V2EX/Linux.do 社区讨论 + awesome-selfhosted 清单。初筛 243 个仓库,用 gh api 批量拉 stars/last_push/archived 排序分级,top 16 逐项深挖读 README 和代码,再用一个"完整性批判者"agent 补漏,又深挖 8 个低星但疑似平台形态的项目,合计 33 个。最后一轮对抗核验:怀疑者视角逐项复查 stars/license/活跃度/成熟度定性,发现并修正 1 处。另有 226 个低星仓库列入暂缓清单,文末给出链接供自行翻阅。

一张表先看全貌

下表是 19 个与"自建接码"直接相关的项目。✓/✗ 表示有无该能力;“号池”=号码池管理(取号/租号/按号收码调度);“计费”=余额/订单/按条计费。

项目⭐License技术栈短信来源Web UI多用户号池计费APIDocker活跃度成熟度
SmsForwarder27983BSD-2Kotlin/安卓Android 真机✗✗✗✗✓✗活跃生产
android-sms-gateway5719Apache-2Kotlin+GoAndroid 真机✓私服✗✗✗✓✓活跃生产
httpSMS5100AGPL-3Go+Kotlin+TSAndroid 真机✓✓✗✓配额✓✓活跃生产
textbee3096MITTS/Next+NestAndroid 真机✓✓✗✓可选✓✓活跃生产
telegram-sms1957BSD-3KotlinAndroid 真机✗✗✗✗✗✗活跃生产
chenxuuu/sms_forwarding1502MITC++/ESP32SIM卡modem✓设备✗✗✗✗✗活跃简陋
gosms1467GPL-2GoSIM卡modem(发)✓✗✗✗✓✓过时弃坑'21弃坑
playSMS881GPL-3PHP+MySQLGSM modem/SMSC✓✓✗✓✓—活跃生产
SMSSync1214LGPL-3Java/安卓Android 真机✗✗✗✗✗✗弃坑'21弃坑
Jasmin1200Apache-2Python上游SMPP/HTTP✗✓✗✓Redis✓✓活跃'04生产网关
SMSGate1188Apache-2Java/Netty运营商CMPP/SMPP✗✗✗✗✗✗活跃'07协议库
SMSHub(juancresc)276无KotlinAndroid 真机✗✗✗✗✓✗弃坑'21简陋
SMSBazaar333MITReact+Express+SQLite上游接码API(7家)✓✗✗✗✓CF Workers活跃简陋
MaDao29AGPL-3Rust+Tauri2+React19上游接码API(HeroSms/5Sim/SMSBower)✓✗✗✗✓✓停更'05客户端半成品
Kalkun237GPL-2PHP+gammuGSM modem✓✓✗✗✓—活跃'08生产
go-smpp255MITGo上游SMPP✗✗✗✗✗✗活跃'04协议库
smstools35GPL-2CSIM卡modem✗✗✗✗✗✗停更'17历史生产
Kannel(mirror)63类BSDCGSM modem/SMPP✗✓静态✗✗✓✗停更'18历史生产
smshub(profullstack)3未声明Next16+SupabaseTwilio/Telnyx✓✓✗✗✓—新建玩具demo

注意"号池"那一列:19 个全是 ✗。这就是开头那个扎眼结论的实证——没有任何一个项目把"号码池"当成一等公民来做。计费那一列也只有 httpSMS(配额而非收款)、textbee(可选 Polar)、Jasmin(Redis 计费引擎)、playSMS(信用计费)沾边,且都不是面向终端用户的接码售卖流。

五类分层逐个说

一、转发层:真机/App 当探针,把短信推出来

这是开源最热闹的一层,核心思路一致——一台插 SIM 卡的 Android 备用机跑个 App,收到短信就转发出去。差别只在转发目的地和有没有服务端。

SmsForwarder(27983★, BSD-2) 是绝对王者,28K 星、持续活跃维护。装在备用机上,把短信/来电/通知按规则转发到钉钉、企微、飞书、Telegram、Webhook 等 20 多个通道,V3.0 起还内嵌 HTTP 服务端能远程发短信/查短信,内置 frpc 穿透。但它是单机单号的转发器而非平台:没有 Web 管理面、多用户、号码池、计费,也没有服务端/Docker 形态。它的正确用法是当"短信来源端"——每台备用机跑一个实例,把验证码经 Webhook 推给你自己搭的上层。坑在于:安卓保活是老大难,厂商杀后台会静默丢转发;把远程发短信 API 暴露公网(尤其配 frpc)是高危攻击面,token 泄露即短信被劫持。

进阶版是把"手机→API/Web"做成有服务端的形态,这一档里三个质量都不错:

android-sms-gateway(5719★, Apache-2) 把手机变成 SMS 网关,REST API 收发、webhook 推送、多 SIM 多设备、端到端加密、SMPP v3.4。三种模式:设备本地 HTTP(局域网直连)、官方云、自建私服(Go 写的 server + MySQL + 可选 Web Dashboard,也开源)。私服推送链路依赖 Firebase FCM,国内 GFW 是硬伤。

httpSMS(5100★, AGPL-3) 是这批里最接近"平台"形态的:Go(Fiber)+Postgres/Redis+Nuxt Web+Kotlin App,有 Web UI、多用户/API key 鉴权、webhook 转发收到的短信、端到端 AES-256、发送速率背压,还有商用托管版 httpsms.com 背书。但它的 billing 只是按订阅档位的月度配额限额,没有支付收款流,更没有号码池租售概念——一号一机。自建部署较繁琐:要配 Firebase(FCM)、SMTP、Cloudflare Turnstile,Android App 得自行编译。AGPL-3.0 有传染性,二次开发对外提供服务有开源义务。

textbee(3096★, MIT) 走全 TS 栈(Next.js+NestJS+Mongo+Redis+Kotlin 端),Web 仪表盘、REST API、多用户、多设备、CSV 群发、收信 webhook、甚至有官方 MCP server 供 AI agent 调用,收发双向(能收 OTP)。计费是可选的 Polar 集成。和 httpSMS 一样,自建要自己编译 Android App(配 Firebase、全局替换域名),国内同样撞 FCM 连通性墙。

telegram-sms(1957★, BSD-3) 走极简路线:App 监听短信推到 Telegram Bot,支持聊天命令远程发短信、执行 USSD。无 Web/API/计费,一台手机一个实例。主仓 Release 停在 2021,新版本在独立 nightly 仓,签名不兼容升级需卸载重装会丢数据。

想压到极致硬件成本,看 chenxuuu/sms_forwarding(1502★, MIT):¥28 级的 ESP32C3+ML307R 4G 模组,插一张 Nano SIM,设备固件收短信后通过 Bark/钉钉/飞书等 8 种通道转发,有设备内置 Web 配置页。它是"SIM 卡池网关的最小单元"——一台设备一张卡,多号=多台硬件,无集中管理。README 明确声明"仅用于接收短信",多卡控制、开放 API、自动化"永远不会支持",拿它做接码平台核心会撞墙。默认 Web 凭证 admin/admin123,改密是上线前提。电信卡仅官方成品套件支持,自焊方案仅移动/联通。

二、SIM 卡池 / modem 网关:硬件收发 + web 管理

这一层用 GSM modem(USB 狗蛋、多卡 GoIP 设备)插 SIM 卡,靠 AT 命令收发短信,再叠一个 web 管理面。特点是"能收能发、有 web、有多用户",但同样没有号码池/接码业务逻辑。

playSMS(881★, GPL-3) 是这层最成熟的:老牌 PHP web 短信网关,通过 Gammu/Kannel/Jasmin 等后端连 GSM modem 或外部 SMSC,能收能发,有多用户+信用计费+多域名+API+插件系统,收到的短信可转发到邮箱或用户手机。它离"接码平台"只差"号码池+取号+验证码提取+接码订单"这一坨业务逻辑——而插件系统确实支持你往这个方向扩。PHP 栈较老,安全需自行加固;依赖外部 SMSC 后端才能收码,需自备 GSM 硬件或运营商通道。

Kalkun(237★, GPL-2) 是 playSMS 的同类但更轻量:基于 gammu-smsd,web 管理(收件箱/发件箱/对话/通讯录/定时/模板/群发/多语言),多用户+多 modem+API。没有计费/订阅/投票等业务功能,核心收发+多用户都有。只需"GSM modem 收发+web 管理"时它比 playSMS 更省。

gosms(1467★, GPL-2) Go 写的本地发送网关,串口 AT 驱动 GSM modem 发短信,带队列/重试/节流/HTTP API/简易 Web dashboard。但只发不收,与接码方向不符;2021 年起无人维护,Dockerfile 基于 ubuntu 14.04 基本废掉,只当参考架构。

更底层的历史项目:smstools3(5★, GPL-2) 自 2000 年起的 C 守护进程,AT 命令直连最多 64 台 modem,文件 spool 进出短信靠 eventhandler 脚本扩展,曾在 Linux 生产多年,但本仓只是 2017 年的手工镜像,上游已停更;Kannel(63★, 类 BSD) 1998 年起的老牌 C 网关,在 GSM modem/SMPP/CIMD2/EMI 等协议和 HTTP 接口间路由短信,能收能发但无 web/号码池/计费,镜像停在 2018。这俩今天更常见的选择是直接用 playSMS/Kalkun 或绕开它们。

三、协议层:对接运营商/短信网关的 SMPP/CMPP 栈

当你的上游是运营商或短信服务商的 SMSC(短信中心),就需要协议栈把消息收进来/发出去。这一层离"接码"更远,属于基础设施。

Jasmin(1200★, Apache-2) 是久经考验的开源 A2P SMS 网关:SMPP/HTTP 双协议、多用户+凭据+配额、Redis 计费/费率 API、Failover/Leastcost 企业级路由、Celery+AMQP store&forward、Grafana/Prometheus 监控。它解决"把短信路由并计费",但不提供号码资产——接码场景的号码池、验证码提取、租号订单全要自建。管理靠 Telnet 8990 的 jcli 命令行,无 Web 界面,运营上手成本高;无 SQL 数据库,配置存文件(pickle store)。SMPP 生态门槛:上游需对接运营商或虚拟号服务商的 SMSC,个人玩家拿不到直连资源时只能当 HTTP 转发引擎。

SMSGate(1188★, Apache-2) 是 Java 协议核心库(Maven 依赖 sms-core),基于 Netty 4 实现中国三大运营商企业短信协议 CMPP/SMPP/SGIP/SMGP 的解析,长短信拆分合并、闪信、WAP 短信。前提是你已有运营商提供的企业短信通道账号——这本身有 SP 资质/签名报备门槛,和"接码"(收验证码)是不同场景。需 Netty 基础,作者另有 sms-client(纯发送)和 smsServer(SpringBoot 网关)配套。

go-smpp(255★, MIT) 是 Go 的 SMPP 3.4 协议库,Transceiver 绑定、PDU 编解码、GSM 7-bit/UCS-2 文本编解码、测试服务器。纯协议组件,要 HTTP API 需另配作者的 sms-api-server。

四、上游聚合面板:对接 sms-activate 类 API

这一层最接近"接码生态",但本质是比价工具/前端壳,核心取号收码仍调上游。

SMSBazaar(333★, MIT) 聚合了 7 家接码平台(Hero SMS/SMSBower/5sim/NexSMS/GrizzlySMS/SMS Verification Number/SMSPool)的 API,做价格(CNY+USD)+库存实时对比看板,专门针对 OpenAI/ChatGPT 接码场景,支持按国家/平台/状态筛选、四种业务模式(注册 OAuth/绑定 OAuth/推荐国家/WhatsApp),每分钟自动刷新,VPS 和 Cloudflare Workers 双部署。2026-09 仍活跃更新。它不是接码平台本身,而是接码平台的比价层——没有号码池、取号、收码、多用户,只是调上游 API 查价查库存展示给你看。Cloudflare Workers 免费版有 KV 写入限制(1000 次/天)。

profullstack/smshub(3★, 未声明) 2026-09 刚建,技术栈极现代(Next.js 16+React 19+Supabase+Expo+Electron),全平台覆盖,但通过 Twilio/Telnyx 商业 API 收发,无号码池/计费/验证码提取,README 提"Coming Soon: phonenumbers.bot"暗示可能往接码走,目前只是架构精美的玩具 demo。

MaDao(29★, AGPL-3) 应用户补充补入。它是这层里最完整的取号路由客户端:Rust+Tauri 2 桌面应用(也支持 Docker web 控制台 + HTTP API),聚合 HeroSms/5Sim/SMSBower 三家上游,把"按服务/国家/运营商配置路由计划、多轮 failover、价格过滤、取号→轮询 OTP→释放票、webhook 回推验证码、号复用池(TTL/次数上限)、实时仪表盘"这一整套接码客户端业务流都做全了,还有可选的匿名聚合统计(Cloudflare Worker+D1)。但它是客户端、不是平台——自己没有一张号码、没有号码池,所有号都是从上游接码商租来的;计费在上游,本地只做余额展示。AGPL-3 传染性强,2026-05 后基本停更(29★ 小项目,慎用)。想自建"取号+路由+回码"的接码客户端,它是这层最值得参考的开源实现;想自建"平台",它帮不上。

五、排除清单:常被搜到但不属于本类

这些项目在搜索结果里反复出现、星数也不低,但和"自建接码平台"无关,放进表里会误导选型:

  • 云手机/真机农场(无短信能力):docker-android(15848★,Android 模拟器 Docker 化,唯一 SMS 功能是 adb 注入虚拟短信)、redroid(6813★,云安卓容器,短信能力取决于装的 App)、openstf/stf(13941★,真机远程控制农场,全仓搜 sms 为 0,已停更)、DeviceFarmer/stf(4559★,stf 活跃继任者,同样无 sms)、Sonic(2210★,云真机测试平台,全组织 2025 上半年 archived)、phonebox(1★,多租户模拟器云,无 sms)。它们的关联价值仅在于:若你走真机/云手机插卡方案,可借它们管理设备集群并远程看屏幕上的验证码——但那是远程桌面人工看,不是接码自动化,且需大量叠加开发。
  • 发送方向(与接码反向):TextBelt(3386★,email-to-SMS 发送,2024 停更,路线基本失效)、overtrue/easy-sms(3337★,PHP 发送 SDK 聚合 30+ 服务商)、SMS4J(1282★,Java 发送 SDK)。方向相反,但它们的多网关抽象设计可借鉴。
  • OTP 发送验证(反向):otpgateway(549★,发 OTP 并验证用户输入,不收短信)。
  • 爬虫/目录/文章(无代码):tmpsms(1083★,CLI 抓 Upmasked 免费接码网站,作者声明已失效)、sms-jiema(364★,纯 Markdown 接码网站目录)、free-sms-receivers(1138★,推荐 16 个第三方平台的文章)、eSIM-Tools(2113★,Giffgaff/Simyo 的 eSIM 转换工具,无关)。

自建怎么做:三条路线

把上面几层拼起来,针对不同目标有三条可行路线。

路线一:自用收码,轻量省钱。 你只想把自己几个号的验证码集中起来,不对外服务。最省的是 chenxuuu/sms_forwarding 的 ¥28 ESP32+4G 模组方案,一卡一设备,N 台设备堆起来,自己写个 webhook 聚合把各设备推送收拢进一个库;或者更省事用 SmsForwarder 装在几台旧 Android 备用机上,webhook 推到你的 Telegram/自建接口。号码池调度?自用场景不需要,一个号一个频道就够了。

路线二:可对外服务、但号码自有。 你想做成有 Web 界面、多用户、API 的平台,但短信来自你自己买的实体 SIM。底座选 httpSMS 或 textbee——它们的多手机接入、多用户、API、webhook 都现成,你只需自建号码池/订单/计费层叠在上面。最大坑是 FCM 依赖(国内硬伤)和一号一机的扩展性(堆真机),以及 Android 保活漏发。AGPL(httpSMS)还要注意开源义务。

路线三:SIM 卡池硬件路线。 你手里有 GSM modem 池(多卡 GoIP/狗蛋设备),想用 modem 直收直发。选 playSMS 或 Kalkun 当 web 管理 + Gammu/smstools3/Kannel 当 modem 收发引擎,Jasmin 可选做 SMPP 路由计费。这条路维护最重(modem 驱动、运营商风控、3G/4G 下部分纯 GSM SMS 通道在退网),但号源完全自有、不依赖 FCM。接码业务逻辑(号码池/取号/验证码提取)仍要自己写插件。

路线四(灰边,只点不展开):对接上游 API。 直接对接 sms-activate/5sim/SMSPool 等接码平台的 API,用 SMSBazaar 当比价层,自建前端取号+收码+计费——这是真正"接码平台"形态的最快上线路径,但号码是上游的、非自有,且上游号源多为灰色。这条路的技术栈最轻,合规风险最重,详见下一节。

合规与风险边界(必须说清)

这一节不展开任何操作,只划线。接收你自己名下号码的短信是合法的——你给自己的号收验证码,天经地义,本文路线一二三都落在这边。

但运营一个公共接码平台、把号码租给他人批量注册账号,性质完全不同:它违反几乎所有平台的服务条款,在中国语境下涉及《刑法》第二百八十七条之二"帮助信息网络犯罪活动罪"(帮信罪)等刑事风险——只要明知他人利用信息网络实施犯罪仍提供帮助,号源、技术支持都算。接码平台的上游号源本身就大量来自黑灰产(盗号、实名冒用、境外黑卡),运营商和平台的风控近年越来越严,云手机方案还有 App 侧容器环境检测封号风险。所以本文定位是技术调研:哪些开源项目能解决哪一层、怎么拼。至于把它拼成对外卖号的接码服务并落地运营——那是另一回事,不是本文要教的。

选型结论(分场景)

  • 自用几号收码 → SmsForwarder(旧手机)或 chenxuuu/sms_forwarding(¥28 硬件),自写 webhook 聚合即可,别想平台化。
  • 想做成有 Web/多用户/API 的平台、号源自有 → httpSMS 当底座(最接近平台形态),自建号码池/订单/计费层;受不了 AGPL/FCM 就看 textbee。
  • 有 modem 池、走硬件收发 → playSMS/Kalkun + Gammu,接码业务逻辑自写插件。
  • 只想要 SMPP/CMPP 协议栈对接运营商 → Jasmin(成熟网关)或 SMSGate(国内协议栈),号码资产自备。
  • 想比价接码上游 → SMSBazaar(聚合 7 家 API),但认清它只是看板不是平台。

一句话收束:开源世界没有现成的接码平台,只有一地零件。 路线一二三都能在合法自用边界内落地;想直接抄一个 sms-activate 出来对外卖号,开源界没这个轮子,而那条路本身的灰色属性,比有没有轮子更值得先想清楚。


暂缓的 226 个低星仓库(含 gammu、pysim、otpgateway、Kalkun、SMSHub 各变体、asterisk-chan-dongle、GoIP 系等)完整链接清单已随调研存档,篇幅所限不逐一点评,有需要的可按文中关键词自行 gh search repos 复现。本文 star 数采样于 2026-09-15,开源项目星数与活跃度随时间变化,选型前请重新 gh api 复核。