curl -I -f -m 10 是检测网站存活的最小可靠组合：-I只取响应头降耗，-f使4xx/5xx返回非零码，-m 10强制10秒超时，再配合grep "200 OK"精准判断业务可用性。
curl -I -f -m 10 是检测网站存活的最小可靠组合
只用 curl https://example.com 判断网站是否“活着”完全不可靠——它连上就返回 0，哪怕后端返回 502、404 或空白页也当成功。真正业务可用，必须确认 HTTP 状态码是 200 OK，且响应不超时、不卡死。
实操建议：
-
-I：只取响应头，避免下载整个 HTML，大幅降低资源消耗和超时风险 -
-f：关键！让 curl 在收到 4xx/5xx 时返回非零退出码，否则$?永远是 0，脚本无法识别失败 -
-m 10：强制 10 秒超时，防 DNS 解析卡住或后端进程僵死拖垮整个计划任务队列 - 配合
grep "200 OK"做精准匹配，而不是只看curl是否返回内容
正确命令示例：
curl -I -f -m 10 https://example.com/ 2>/dev/null | head -1 | grep "200 OK" >/dev/null
宝塔计划任务里 mail 命令发不出邮件？大概率没装 mailx 或没配 MTA
写完检测脚本，加一句 mail -s "down" admin@x.com 就以为能告警，结果收不到信——这不是邮箱配置错，而是服务器压根没 <code>mail 命令，或者装了但没本地邮件传输代理（MTA）。
实操建议：
- Debian/Ubuntu 运行
apt install mailutils；CentOS/RHEL 运行yum install mailx（注意不是mail包） - 即使装了，
mail默认依赖sendmail或postfix，而宝塔默认关掉这些服务；别折腾本地 MTA，直接换更稳的方案 - 推荐改用 Python 脚本调
requests发钉钉/企业微信，或用ssmtp配 SMTP 直连；若坚持用mail，务必先在终端执行echo test | mail -s "test" your@em.ail验证通路
怎么避免网络抖动误报？别在单次脚本里 sleep，用时间窗口统计历史状态
一次 curl 失败就发告警，等于把 CDN 回源延迟、DNS 短暂抖动、SSL 握手慢都当成宕机。真要区分故障和抖动，得靠多次检测的时间维度判断，但又不能让一个计划任务跑好几秒等重试。
实操建议：
- 每次计划任务只做一次检测，把结果（成功/失败 + 时间戳）追加写入一个日志文件，比如
/www/server/panel/logs/site_health.log - 格式统一为：
$(date +%s) 200或$(date +%s) 0，方便后续 awk 解析 - 脚本开头用
awk '$1 > (systime() - 300) && $2 == "0" {c++} END{exit c 统计最近 5 分钟失败 ≥2 次才触发告警 - 不用数据库、不依赖外部服务，纯文件 + shell 就能实现带时间窗口的状态聚合
Python 脚本比 Shell 更适合复杂检测场景，但必须用宝塔内置环境
当你要验证 HTTPS 证书有效期、解析 JSON 接口返回的健康字段、或调用宝塔 API 查站点 SSL 状态时，Shell 就力不从心了。Python 的 requests 和 ssl 模块天然支持这些。
实操建议：
- 别用系统 Python，宝塔面板自带 Python（路径通常是
/www/server/python/bin/python），所有依赖必须用它安装：/www/server/python/bin/python -m pip install requests - 脚本中调用宝塔 API 时，记得用面板设置里的 API
key和id，并注意 URL 中的端口（如http://127.0.0.1:8888） - 权限和路径全按
www用户视角写：日志写到/www/wwwlogs/下，临时文件放/tmp/，别碰/root/或需要 root 权限的路径 - 宝塔计划任务运行脚本时，环境变量极简，
PATH可能不含/www/server/python/bin，所以脚本第一行必须写完整解释器路径：#!/www/server/python/bin/python
真正的难点不在写逻辑，而在确保脚本在宝塔的沙箱环境里能被正确加载、有权限、有依赖、有上下文——漏掉任意一环，它就在后台静默失败。
