高铁上花三小时，我部署了全自动SSL证书同步脚本
上午10点41分，G字头高铁准时驶出石家庄站。这次要去唐山出差，三个小时的旅途，足够看完一部电影，或者发完一整天的呆。
车厢里很安静，邻座的大叔在刷短视频，外放的声音像某种昆虫的振翅。我戴上耳机，打开社交APP，漫无目的地翻看那些关于AI的新奇分享。有人用AI写歌，有人用AI画画，还有人用AI预测股市——虽然我觉得最后那个多半是骗人的。
突然我刷到了一句暴论：
「如果不是AI，我都不知道nginx已经是过去式了，可以全部改为Caddy。」
我盯着这行字看了很久，nginx是过去式？那我这十几年在干嘛——考古吗？
但不得不承认，这句话像一根刺，戳中了我的好奇心。Caddy这名字我听过，据说配置特别简单，还能自动搞定网站的安全证书。对于一个每次证书到期都要手动折腾的人来说，这听起来像是某种救赎。
我截了图，发给手机上的Kimi。
1. 手机上的漫长对话
「我有一个Hexo博客，能不能换Caddy？」
Kimi很耐心地给我讲了迁移步骤，从安装到配置文件，讲得头头是到。我像一个认真记笔记的学生，一边看一边点头——虽然对面座位的大叔正在打瞌睡，口水流到了衣领上。
但聊着聊着，问题开始变形。
Kimi问我：「你的博客部署在哪？」我说阿里云的对象存储，就是那个OSS。Kimi沉默了一秒——如果AI有沉默的话——然后说：「Caddy只能解决服务器本身的证书问题，OSS那边的证书绑定是阿里云控制台层面的操作，Caddy帮不上忙。」
我突然意识到，我要解决的不是「换不换Caddy」，而是「宝塔自动续期后，证书怎么自动同步到OSS」。
这就好比本来想去买个新冰箱，结果发现自己家的电费单出了问题。
2. 从手机到电脑
聊了大概半小时，我意识到光靠手机是搞不定的。有些操作需要登录服务器，需要复制粘贴命令，需要在终端里看报错信息——这些在手机上简直是一种酷刑。
于是我从包里掏出了笔记本电脑。
Kimi方便的地方在于，移动端和网页端无缝衔接，我从手机版Kimi切换到网页版Kimi，无需再复述上下文，只需在网页端找到相应的历史对话记录，接着跟Kimi对话就行。Kimi给了我几个方案：
方案 A：用阿里云自带的免费证书，一年一换，可以一键部署到OSS。听起来不错，直到我发现——阿里云免费证书在2024年后也改成了三个月有效期。和原来一样，一年要操作四次。
方案 B：用阿里云的CDN加速服务，证书可以自动续期。但CDN要额外花钱。我的博客那点流量虽然花不了几块，可这种「明明可以不花」的感觉让我很不舒服。
方案 C：写个自动化脚本。宝塔续期后自动触发，调用阿里云的接口，上传证书，绑定到OSS。零费用，全自动。
我不禁想起多年前第一次配置服务器的时候，那时候我觉得写脚本是一件特别酷的事，像电影里那些黑客一样，手指在键盘上飞舞，屏幕上滚过一串串绿色的代码。现在嘛，更像是一种被迫的成熟。
我决定选方案C。
3. 说方案容易，动手很难
Kimi把方案讲得特别清楚：创建一个专门的用户账号、配置权限、写一段Python脚本、设置定时任务。每一步都有截图指引，每一个参数都有说明。
但我进入了一种奇特的工作流：Kimi说一步，我操作一步；遇到报错，我截图发回网页，Kimi分析原因，我再修改。整个过程像是在玩一个回合制游戏，只不过对手是阿里云的各种权限策略和接口文档。
创建那个专门的用户账号还算顺利。但当我看到「请创建自定义策略并绑定到用户」的时候，我突然理解了什么叫「层层加码」。我只是一个想让自己的博客证书自动续期的人，却要像申请银行贷款一样填写各种表单。
更要命的是，高铁上的网络时断时续。每次信号消失的时候，我就盯着那个转圈的加载图标发呆，想象那些数据包在华北平原的农田上空迷失了方向。
折腾了大概一个小时，网页端的工作流让我疲惫不堪。不是说Kimi不够好，而是「你说我做」这种模式，对于一个不是程序员的人来说，每一步都是未知的深渊。你不知道下一个报错会是什么，也不知道自己刚才的操作会不会把服务器搞坏。
无力的我把电脑放到小桌板上，打开了Kimi Code CLI。
4. 换个搭子
Kimi Code CLI和网页版不一样。网页版像一个耐心的老师，一步步教你。CLI更像一个直接动手的搭子——你说「部署这个脚本」，它就开始执行。
我给了它服务器的登录信息，还有脚本文件。它先把脚本传到服务器上，然后运行。
第一个报错来得很快：连不上服务器。原来是命令行工具在自动流程里没法输入密码，需要一个叫sshpass的小东西来帮忙。感觉像是在跟服务器谈判：「我知道你不想让我进，但我有钥匙。」
然后遇到了第一个真正的坑。阿里云有一个叫CAS的证书服务，它不认识我写的「北京」这个地区代码。查了半天才知道，这个服务的接口入口是不分地区的，全国统一叫一个名字。别的服务都按城市分，偏偏这家叫总店。
改完这个，接口名称又错了。网页版Kimi给的方案里用的是某个名字，实际要叫另一个名字。阿里云工程师改名的时候，大概没想过有多少人的脚本会悄无声息地失败。
证书终于上传成功了，系统返回了一个编号。我正要高兴，对象存储那边又炸了——那个专门创建的用户账号没有访问存储空间的权限。我又回到阿里云控制台，给那个叫「cert-sync-oss」的账号加权限。加完证书服务的权限，再加对象存储的权限，像是在玩某种特别枯燥的填表游戏。
等权限终于加好了，最后一个坑出现了。对象存储的命令行工具不认我用的那个接口名称。它认的是另一个名字，还要配一个XML格式的文件。
那一刻，我突然理解了为什么有人会选择手动更新证书。手动虽然烦，但至少你知道自己在干嘛。自动化就像养了一只猫，它大部分时间很乖，但偶尔也会在你最忙的时候把花瓶推下桌子。
5. 技术最温柔的样子
当终端里终于出现那行「绑定成功」的时候，我抬头看了一眼窗外。列车已经过了天津，远处的天际线在灰蒙蒙的天空下若隐若现。
我没有想象中的兴奋，只有一种「终于不用再管这件事了」的空虚感。
也许这就是成年人的快乐——不是「得到了什么」，而是「不用再做什么」。
脚本现在每天凌晨两点会自动跑一次。如果宝塔续了新证书，它就会悄悄同步到阿里云的证书服务和对象存储，然后在日志里写一行「同步完成」。不会发邮件通知我，不会弹窗，就是安安静静地干完活。
我想起刚开始在手机上问Kimi的时候，我们还在讨论要不要把整个架构都迁到另一个平台。现在呢，我只想把这个小脚本安静地放在那里，让它自己跑。
这大概是技术最温柔的样子。
6. 那句暴论到底对不对
回到开头的那句话：「nginx已经是过去式了，可以全部改为Caddy。」
折腾了这么一圈，我的nginx还在跑着——服务器上的评论系统和订阅插件依然依赖它。Caddy确实配置更简单，自动证书很香。但对于我的场景来说，真正的痛点从来不是 nginx 本身，而是证书在不同云服务之间的同步。
那句话的问题在于，它把「AI 推荐的更现代工具」等同于「旧工具已淘汰」。但技术选型从来不是非黑即白的。nginx在 2026 年依然支撑着全球半数以上的网站，Caddy更适合个人项目快速部署。
就像我在这个过程中领悟的：有时候不需要换掉整个架构，只需要写一个小脚本，让一个烦人的重复劳动消失。
7. 这样做到底值不值
列车开始减速，唐山站的站牌从窗外掠过。我合上电脑，把它塞回包里。
写这篇文章的时候，我又看了一眼那个定时任务。每天凌晨两点，一个小脚本在阿里云的服务器上醒来看看我的证书。如果变了，就默默同步过去。如果没变，就回去继续睡。
从高铁上刷到的一句暴论，到手机上和Kimi的漫长对话，再到命令行工具的动手部署——这个过程绕了一个大圈。但如果有人问我值不值得？
放在10年前，我觉得技术是冷冰冰的。但现在觉得，技术其实很有人情味，只要你愿意花时间去跟它对话。
当然，对话的过程还是挺折磨人的。