长年在服务器上折腾的人，迟早会碰到一个需求：某个任务跑完了、某个服务挂了、磁盘快满了，你得第一时间知道。早些年我习惯挂着终端或者开着邮件提醒，但邮件经常被丢进垃圾箱，终端又总有不在跟前的时候。短信虽然朴实，却是真能稳稳当当把一句话递到你手上的手段。当时我手上只有一个Linux服务器、一堆Shell脚本和curl，花了一个下午把短信API接了起来，从此定时任务、监控脚本全都多了一双会喊话的眼睛。这篇就完整梳理一遍，我是怎么用Curl指令在Linux脚本里把短信通知跑通的。
整个方案核心就三样东西：Shell、Curl、短信API。Shell负责流程控制和任务触发，Curl负责发HTTP请求，云厂商的短信API负责把内容变成真正发到你手机上的短信。写完之后你也能在五分钟内手工发一条测试短信，再花二十分钟封装成通用脚本，直接塞进自己的监控体系里。全程不依赖Python、不走邮件网关、不需要额外安装守护进程，一个bash就能搞定，非常契合轻量运维的场景；这篇东西适合刚接触Shell脚本、又恰好有短信发送需求的运维和开发同学。
1. 为什么我最终选Shell加Curl，而不是写个Python脚本
1.1 我的应用场景和对通知系统的要求
先交代一下当时的实际环境。我在维护几台跑业务的Linux机器，上面既有Nginx和数据库，也挂着几个每天定时执行的备份脚本和爬虫任务。原来出问题怎么办？靠我隔几个小时登录看一眼，或者翻日志。后来有一次一个备份脚本因为磁盘空间不足挂了三天，我才意识到没有一个主动通知机制，所谓监控就是个摆设。
我评估下来，通知方案的选择其实很有限。邮件容易进垃圾箱，而且配置SMTP本身也很烦；钉钉和企微机器人虽然方便，但国内办公软件的通知声音我不一定注意得到；短信呢？只要手机有信号就一定能收到。至于为什么不用Python脚本——服务器上确实装了Python，但很多生产机器环境比较旧，Python的requests库不一定装了，而curl是Linux里几乎铁定存在的命令。为了发一条通知去补一堆依赖，这笔交易不划算。
1.2 用Curl调用接口的天然优势
Curl能成为Linux下调用HTTP接口的事实标准，不是没道理的。它在绝大多数发行版里开箱即用，哪怕是最小化安装的服务器一般也带着curl或者能用包管理器三秒装好。Curl支持GET、POST、PUT、DELETE这些主流方法，也能带Header、带JSON体、处理超时、跟随重定向，日志输出还能精确到每一字节的收发情况。
最关键的还是"可调试"。用命令行发请求，你看到的响应是明文，报错时能直接看到HTTP状态码和返回体。配合-v参数还能看到握手过程、请求头等细节，而写Python代码时遇到网络问题反而要多绕几个弯。运维场景里，能被一行命令当场验证的东西就是最可靠的。
1.3 和定时任务Crontab的天然亲和
要知道，Crontab执行的是命令，Shell脚本无非是一个大号的命令集合，而Curl又是一个命令。这三个东西它们本来就是同一生态的语言。我把发送短信的代码写成一个Shell函数，在备份脚本最后一行调用一下，定时任务就自动带上通知能力了，不用额外起服务、不用配队列。这个"顺手"的感觉是其他语言很难给的，你要写个Python脚本，还得考虑cron环境里的PATH、PYTHONPATH甚至编码问题，而Shell里写Curl就完全没这些负担。
2. 接入短信API前必须摸清的底牌
2.1 账号体系：AccessKey和密钥的配合方式
市面上的短信服务商，常见的有阿里云、腾讯云、华为云，以及一些老牌的短信平台。它们的API风格大同小异，但鉴权方式几乎都是同一套思路：用一组AccessKey和Secret来标识你的身份，其中AccessKey是公开的标识，Secret是你和服务器之间的共同秘密，用来给请求签名。
这里面有个让新手特别容易卡住的点：Secret永远不会出现在请求参数里，它是用来计算签名的，不是直接传给服务器的。服务器也知道你的Secret，服务器算出签名，和你传过去的签名做对比，一致就说明这个请求确实是持密钥的人发来的。不知道这个机制的人，很容易把Secret明文塞进参数里，结果不但报签名错误，还把密钥暴露了。签名机制的完整过程，我下一节会详细走一遍。
2.2 短信签名和短信模板的含义
短信API和普通业务接口有个很大的不同：它不会让你随手传一段字符串当内容发出去。你得先申请一个"短信签名"，比如【我的运维助手】，还得申请一个"短信模板"，比如"您的服务器{1}发生异常，请及时处理"。审核通过后，调用API时传的是签名名称和模板ID，而不是直接传短信内容。
为什么要这样做呢？因为短信通道是运营商强监管的领域，平台必须保证每一条短信都有明确的发送主体和内容类型，才能避免垃圾短信和网络诈骗。我第一次接的时候，因为模板里写了"测试"两个字，被审核驳回了三次，后来写成"您的服务发生异常，请检查处理"才过。所以，准备工作里一定要把模板内容想好，留好占位符，上线前先在控制台发一条测试短信，确认签名和模板的状态是"已开通"。
2.3 环境里必备的小工具侦察
正式开始之前，我习惯先确认环境里缺什么。用which curl date base64 openssl sed检查一下，这几个命令分别负责网络请求、时间戳生成、加密运算、字符处理，后面签名计算和请求发送全都用到。在绝大多数发行版里，curl和sed几乎一定存在，date也是，但openssl不一定，需要时用yum install openssl -y或apt install openssl -y补一下就行。
版本上，curl尽量别太老，7.55以下的版本在处理某些TLS证书或者IPv6场景时会有一些已知毛病。你可以用curl --version看看版本号，如果实在太老，顺手升级一下。不过这里有个细节要注意：云厂商的API域名走的都是HTTPS，所以curl必须带openssl或nss的支持，否则没办法验证服务器证书。想知道自己的curl是否支持TLS，运行curl -V时看输出里有没有HTTPS字样。
3. 核心实现之一：签名计算的完整推导过程
3.1 先理解签名公式再抄代码
各厂商的签名算法里，百度云的算是清晰友好，阿里云的传统签名流程也有代表性。我把通用的计算原理拆给你看，不针对某个具体厂商，你理解了这套逻辑，换任何一家API都能在三十分钟内完成适配。
签名的输入是一组字符串，通常由HTTP方法、请求参数、密钥这三部分组成。基本流程分四步：
- 把所有参数（除了Signature本身和几个文件类参数）按Key的字典序升序排列；
- 把"参数名=参数值"用
&连接起来，形成规范化查询字符串； - 对参数值做严格URL编码，不只是特殊字符，连普通参数也得规范编码；
- 以密钥作为Key，对规范化字符串做HMAC计算，把结果再做一个Base64编码，就得到签名。
整个过程的精髓在于"双方用同样的规则算一遍"。你先算，服务器也按同样规则算一遍，俩值一样就通过。规则里任何一点不一致，比如排序顺序不对、编码方式把空格转成了加号而不是%20，结果就会报"SignatureDoesNotMatch"。
3.2 带着具体实例手算一遍
我们用一个小例子来验证。假设有两个参数，PhoneNumbers=13800138000和TemplateCode=SMS_123。第一步，按ASCII码顺序排序，P在T前面，所以PhoneNumbers在前，TemplateCode在后。第二步组成字符串PhoneNumbers=13800138000&TemplateCode=SMS_123。第三步对它做HMAC计算，这里用的是HMAC-SHA1或HMAC-SHA256，取决于API版本，常见的阿里云旧版是HMAC-SHA1，新版是HMAC-SHA256。密钥就是你的AccessKey Secret加上一个固定的&字符。
代码层面，用Shell加openssl实现，核心就这么几行：
# 假设ak_secret是密钥，string_to_sign是上一步拼出来的规范化字符串 signature=$(echo -n "$string_to_sign" | openssl dgst -sha1 -hmac "$ak_secret&" -binary | base64)这里有两个容易出错的地方。一是echo -n不能写成echo，多一个换行符整个签名就算不对；二是base64编码时不能手动换行，openssl输出binary再管道给base64就刚好，但如果用base64 -w0可能会在某些系统上不识别-w参数，建议用base64的默认行为，但在Linux上默认会自动换行。despite这个坑，实际用openssl base64更统一。
3.3 时间戳和随机串那些"规定动作"
短信API的签名里一般还要带两个防重放攻击的参数：Timestamp和SignatureNonce。Timestamp要求是ISO8601格式的UTC时间，不能带毫秒，格式像2025-01-15T08:30:00Z。在Shell里生成这个时间，最稳的写法是：
timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")签名随机串SignatureNonce呢？要的是每次请求都不一样，防重放用的。Shell里生成随机串的办法不少，我用过date +%s%N配合$$进程号，也用过cat /proc/sys/kernel/random/uuid。生产上更推荐uuid，因为随机性更强；但是在最小化系统里可能没有uuidgen命令。考虑到通用性，我平时都用date +%s%N$$拼一个，够用，反正防重放主要依赖时间戳窗口。
3.4 为什么阿里云新版签名会更难拆
我后来也接过新版签名算法的接口，就是AccessKey ID以LTAI开头的那批老账号还在用的兼容模式，以及部分新产品的ACS3-HMAC-SHA256。新版的区别在于多了个X-acs-signature-nonce之类的Header，而且请求体的Hash也要参与签名。从Shell脚本的角度来说，如果旧版能接入，优先用旧版兼容入口，因为旧版所有信息都在Query里，拼一个URL就够了。新版要处理请求体的SHA256摘要，还得额外维护Header顺序，脚本复杂度马上就上来了。
判断是哪个版本，就看你的API描述文档里签名方法是HMAC-SHA1还是ACS3-HMAC-SHA256。对个人运维场景来说，能用1.0的接口写信签，就尽量别折腾3.0。
4. 核心实现之二：Curl指令的实战写法
4.1 把请求拼出来：GET方式发送短信
等签名算出来，消息已经成功了一大半。以发送短信为例，手上有这些参数：Action=SendSms、Version=2017-05-25、RegionId=cn-hangzhou、PhoneNumbers=手机号、SignName=签名、TemplateCode=模板ID、TemplateParam=JSON串的UrlEncode、Signature=刚才算出的签名。
做GET请求时，curl的写法很直白：
curl -sS --connect-timeout 10 -m 15 \ "https://dysmsapi.aliyuncs.com/?Action=SendSms&Version=2017-05-25&RegionId=cn-hangzhou&PhoneNumbers=13800138000&SignName=我的运维助手&TemplateCode=SMS_123&TemplateParam=%7B%22keyword%22%3A%22disk%22%7D&Signature=xxxx"这里我反复强调几点。第一，用-sS，-s是静默模式不显示进度条，但大写S会让Curl在出错时仍然打印错误信息，不然脚本排查故障时完全没头绪。第二，--connect-timeout和-m必须要有，前者限制连接超时为10秒，后者限制整个请求最多15秒，没有超时的脚本一旦遇上网络抖动就会挂在那儿不动，连定时任务都给卡死。第三，所有中文和花括号必须URL编码，这个可以直接在Shell里用__url_encode函数处理，别手写编码。
4.2 POST方式与数据体发送的差异
有些API，尤其是部分国内厂商较新的接入协议，要求POST加JSON请求体。这时候curl要变一下：
curl -sS --connect-timeout 10 -m 15 \ -X POST \ -H "Content-Type: application/json" \ -H "Authorization: acs ..." \ -d '{"phone":"13800138000","msg":"disk full"}'注意一个细节：如果-d和-X POST一起用，数据是放在请求体里的，但如果你本意是让参数走Query、数据走Body，就得分清楚。很多老手会在shell脚本里图省事把所有参数都拼进URL，结果是接口文档上的"请求方法"反而成了最常见的事情。还有一点，-H加Authorization这个Header的时候，值里的签名也要动态生成，你调试时可以先拿curl -v看请求头输出长了什么样，再对照文档，报"InvalidAuthorization"就说明签名格式和道道不匹配。
4.3 用-v和-i看响应细节
对接任何接口，第一步永远是别急着写完整脚本，先手工拿一行curl打一遍，看返回的是什么。
我用得最多的组合是：
curl -sS -i https://dysmsapi.aliyuncs.com/...-i会把响应头一起打出来，能看到HTTP状态码是200还是500，有时候接口返回200但业务Code不是OK，这说明请求到了服务端但业务校验失败，比如签名错误、模板不存在。看完返回体里的Code字段和Message字段，就能知道是签名问题、欠费问题，还是模板审核中。亲手打一次拿第一手数据，比看文档管用多了。
5. 把通知能力封装成可以复用的通用Shell脚本
5.1 完整脚本骨架
下面这个脚本是我现在几台服务器上还在跑的精简版，做成了独立的发送函数，你拿去改一下密钥和参数就能用。别把密钥写死到脚本里，我会用环境变量引用，这样脚本即使误发到别人手里也不至于泄露。
#!/bin/bash # send_sms.sh —— 通用短信通知函数 # 配置 SMS_AK_ID="${SMS_AK_ID:-your_access_key_id}" SMS_AK_SECRET="${SMS_AK_SECRET:-your_access_key_secret}" SMS_SIGN_NAME="${SMS_SIGN_NAME:-我的运维助手}" SMS_TEMPLATE_CODE="${SMS_TEMPLATE_CODE:-SMS_123}" SMS_REGION_ID="cn-hangzhou" SMS_ENDPOINT="https://dysmsapi.aliyuncs.com/" SMS_VERSION="2017-05-25" SMS_ACTION="SendSms" # URL编码函数 urlencode() { local data="$1" printf '%s' "$data" | curl -Gso /dev/null -w %{url_effective} --data-urlencode @- \ | sed 's/.*?//' }等一下，这个urlencode函数里有一个我踩过的坑。curl -G --data-urlencode可以帮你做URL编码，但是结果输出到stderr或者带上额外前缀很麻烦，不如直接用纯Shell的编码函数。下面这个用od配合sed的实现，相对可靠：
urlencode() { local data="$1" local len=${#data} local i=0 local c for ((i=0; i<len; i++)); do c="${data:i:1}" case "$c" in [a-zA-Z0-9.~_-]) printf '%s' "$c" ;; *) printf '%%%02X' "'$c" ;; esac done }5.2 签名函数和主发送函数
签名函数做的是我前面铺垫的那套流程。参数的字典排序我是用printf配合sort做的，这样不依赖Python：
build_signature() { local -a args=("$@") local sorted local query="" local i # 排序 sorted=$(printf '%s\n' "${args[@]}" | sort -k1) ... }不过把整个签名逻辑完整地塞进博客里篇幅会特别长，而且不同厂商之间略有差异。我在实际项目里固定用自己惯用的一套模板，用函数分离签名和发送，这样换厂商只需改签名那一块。发送函数的核心是拼出最终URL，交给curl执行，再做响应判断。
send_sms() { local phone="$1" local template_param="$2" # 生成时间戳、随机串、参数拼接、计算签名…… # 最终调用 response=$(curl -sS --connect-timeout 10 -m 15 "$url") echo "$response" }我把完整脚本放到GitHub Gist上维护，这里把函数的关键逻辑展示出来，主要是让你理解封装的层次——配置区、编码区、签名区、请求区四块，互相解耦。后面加日志、加重试、加多手机号通知，都只需在对应模块上做文章。
5.3 和定时任务、监控脚本的组合套路
脚本写完，真正的价值是挂到监控里去。我常用的三种挂法：
第一种，直接在crontab里配合&&逻辑。比如备份命令跑完，不管成功失败都发通知：
0 2 * * * /usr/local/bin/backup.sh && /usr/local/bin/send_sms.sh 13800138000 '{"job":"backup","status":"success"}' || /usr/local/bin/send_sms.sh 13800138000 '{"job":"backup","status":"fail"}'第二种，在Shell脚本需要告警的地方调用函数。比如检查磁盘空间，超过85%就发短信：
usage=$(df / | awk 'NR==2 {print $5}' | tr -d '%') if [ "$usage" -gt 85 ]; then send_sms 13800138000 "{\"alert\":\"disk\",\"usage\":\"$usage%\"}" fi第三种，检查某个进程是否活着，挂了就发告警并尝试拉起。这个在线上最重要：
if ! pgrep -f "nginx: master" > /dev/null; then systemctl start nginx send_sms 13800138000 "{\"alert\":\"nginx down\",\"action\":\"restarted\"}" fi三种挂法覆盖了定时任务、资源告警、守护进程三类最常用的运维需求。你只要把自己的业务命令嵌套进去，等于立刻给所有脚本加了一个通讯器官。
5.4 脚本健壮性的几个增强点
生产环境里发短信这种事，宁可重复通知也别漏通知，但又不能无限重试把API频率打爆。我建议加这两个能力：
一是控制最大重试次数。curl返回非0或响应里没出现"Code":"OK"时，重试最多三次，中间sleep递增。二是做日志落盘。
log_msg() { echo "$(date '+%Y-%m-%d %H:%M:%S') $1" >> /var/log/sms_sender.log }日志看起来是小事，但等哪天短信通道出故障，你想复盘时就知道它有多救命了。另外，发送结果里有一个BizId，这是短信平台返回的业务流水号，遇到"短信发了但用户没收到"这种线上投诉，客服大概率会管你要这个BizId来查。所以日志里务必把整个响应保留下来，别只存一个OK。
6. 常见问题排查与高频踩坑记录
6.1 签名错误永远排第一
我在群里看到最多的问题就是"签名错误"，实际上99%不是平台问题，而是自己代码里某个字符没处理好。整理一张速查表给你，照着排查会快很多。
| 问题现象 | 大概率原因 | 排查命令或方法 |
|---|---|---|
| SignatureDoesNotMatch | 参数没按ASCII排序 | 打印规范化字符串对比官方示例 |
| SignatureDoesNotMatch | URL编码空格变成+ | 检查编码函数，空格必须为%20 |
| SignatureDoesNotMatch | 密钥末尾少了& | 新版签名经常要求Secret后面拼& |
| TimestampExpired | 本机时间不准 | 运行date -u看UTC时间，同步NTP |
| InvalidTemplateCode | 模板ID输错或未审核 | 控制台确认模板状态 |
| isv.SMS_SIGNATURE_ILLEGAL | 签名未通过审核 | 检查签名内容与营业执照一致 |
| isv.MOBILE_NUMBER_ILLEGAL | 手机号格式不对或测试号码没白名单 | 看文档要求，测试时加测试号 |
遇到"签名错误"，我第一步永远是打开调试日志，把待签名的字符串完整打出来，拉一个官方签名工具生成的结果和自己脚本的结果对比。对比时重点看：排序是否一致、编码是否一致、密钥拼法是否一致。三处都一样，签名一定对。
6.2 连接超时与RPC失败的处理
请求阶段常见的问题还有curl返回56 Recv failure或者超时。这个66号错误码代表的是接收数据失败。网上有个常见场景，说"curl 56 recv failure: 连接超时"，定位下来多半是网络出口访问不到目标服务器的端口，或者服务器防火墙把响应切断了。
我的排查思路是：先telnet或nc -vz测试目标域名和443端口能不能通，通了再curl，仍然失败就换curl -v看卡在哪一步。如果DNS解析出来不对，检查/etc/resolv.conf；如果IP能通但HTTPS握手失败，把-k临时加上做对比（生产上别用-k，这里只是排查）。另外有一种情况是短信平台对并发请求做了限制，脚本在循环里发太多请求时，会被平台的限流策略把连接断开。这种时候加上随机sleep，或者串行发送，比反复调超时参数有效得多。
6.3 中文和特殊字符编码的连环坑
发消息内容里带中文是常态，而模板参数是一个JSON字符串，比如{"keyword":"磁盘满"}。这个字符串在发送时必须整体做URL编码。很多新手直接拼到URL里，结果"磁盘"两个字在请求里变成了乱码，服务端收到的JSON解析失败，报InvalidParameter。
我的建议很简单，写一个urlencode函数，先对TemplateParam整体编码，再拼进URL。函数的细节可以回头看我5.1节提供的版本。另外，有时模板参数里含有单引号和双引号，Shell变量引用也要格外小心，建议send_sms "$phone" "$template_param"时一定要用双引号包住变量，否则Shell会把JSON里的空格或特殊字符拆开当多个参数传。
6.4 一个关于脚本定时任务环境变量的大坑
最后说一个特别隐蔽的问题：crontab里运行脚本时，环境变量和手工执行时不一样。你的PATH可能是/usr/local/bin:/usr/bin:/bin，但在cron环境里可能只有/usr/bin:/bin。如果你的curl或openssl装在/usr/local/bin下，手工执行没问题，cron里却会报"command not found"。
解决方法是在脚本开头显式设置环境变量或绝对路径：
export PATH=/usr/local/bin:/usr/bin:/bin CURL_BIN=/usr/local/bin/curl OPENSSL_BIN=/usr/local/bin/openssl有些发行版cron还会用sh而不是bash来执行脚本，脚本里如果你写了$((...))这类bash特性，在sh环境下可能解析异常。保险起见，脚本第一行写#!/bin/bash，并且在crontab里用/bin/bash /path/script.sh来调用，别直接写脚本路径，这算是我被cron坑过好几次之后留下的习惯。
7. 从短信推送延伸到更完整的通知体系
短信接口跑通之后，你会发现自己对通知的胃口变大了。一条短信最多几十个字，适合传达"发生了什么、要不要处理"这种极简信息；但具体报错堆栈和日志片段不适合发短信。我在实际使用中通常采用分级策略：紧急故障用短信，重要但不紧急的用钉钉或企业微信机器人，日志级别的信息直接推到个人服务器上的一个Webhook。
这个思路的落地方式不复杂：把短信函数里那套签名和请求逻辑抽成一层，再加上钉钉机器人的webhook发送函数，两者都封装成"发一条消息"的公共函数，上层脚本只关心级别。比如我的备份脚本里是这样用的：
notify "info" "备份完成" notify "error" "备份失败，请关注"notify函数内部按级别决定走短信还是webhook。这样短信通道因为欠费或者审核被卡住时，其他通道还能兜底，我在运维群里依然看得到告警。
再往后你甚至可以把这个脚本包装成系统服务或者放进Docker容器里，让其他机器通过HTTP调用。不过一步到位搞微服务反而复杂，我建议大多数场景就停留在Shell函数这个粒度，够用、好改、不会半夜被自己的架构绕晕。
8. 拿这套能力还能做什么扩展
短信通知这种能力，一旦封装好，扩展方向比想象中多。我给几个亲测可靠的方向：
一是结合inotifywait监控关键配置文件变化。比如nginx的配置文件被人改动了，自动发条短信提醒你。这比每天手动比对配置高得多。二是结合进程退出码，给压力测试做完成通知。以前跑一个压测要盯半天终端，现在脚本用wait配合send_sms，跑到结束把QPS和错误率发到你手机上。三是做业务报表的定时推送。每天凌晨统计昨天的订单数、错误数，拼成消息发到手机，早上一睁眼就能掌握状态。四是把多个脚本的告警聚合到一个公共函数里，做频率控制和去重。比如同一个问题五分钟内最多发一条短信，避免故障时短信轰炸把你的手机打到关机。
每个扩展方向，本质上都是把"Shell脚本发出通知"这个能力嫁接到已有的任务上。你不需要学新的语言，也不用重新部署什么，只需要在合适的时机调用几行函数，整个自动化体系就有了反馈回路。
我自己的感受是，越是简单直白的工具越能长期保持生命力。Shell脚本加curl的方案，可能不炫酷，但它在任何一台Linux机器上都能跑，不挑环境，出了问题还能拿bash -x一行行看执行过程。短信通知这件事，要的不是花哨的框架，而是稳定送达。用最朴素的工具解决最核心的问题，这大概就是运维脚本该有的样子。
