API与数据库迁移至新服务器的SSL配置及迁移方案咨询

安全阿岳

2026-4-20

首先得说，你找到的certbot certonly --manual --preferred-challenges=dns -d a.com这个方法完全靠谱！域名还没指向新服务器的时候，HTTP验证（就是你之前卡壳的.well-known那套）肯定过不去，因为ACME服务器会去解析a.com的IP，然后访问对应服务器的验证文件，这时候它找的还是旧服务器，自然失败。而DNS验证是直接通过域名的DNS记录来验证你对域名的控制权，跟服务器在哪完全没关系，刚好适配你现在提前在新服务器部署证书的需求。

不过有个小提醒：手动DNS验证获取的证书，续期的时候也得手动去加TXT记录，时间长了容易忘。既然你用的是DigitalOcean，他们的DNS有官方API，你可以试试Certbot的certbot-dns-digitalocean插件，这样就能实现证书自动续期了。步骤大概是：

在DigitalOcean控制台生成一个带DNS权限的API密钥
创建一个配置文件（比如~/do-dns.ini），内容是：
```
dns_digitalocean_token = 你的DO API密钥
```

用这个命令获取/续期证书：

certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/do-dns.ini -d a.com -d api.a.com

这样后续证书到期前Certbot会自动通过API添加TXT记录完成验证，不用你手动操作了。

再聊聊你的迁移方案，整体思路是稳的，但可以加几个小优化来降低风险：

提前同步数据库：正式切换前，先把旧服务器的数据库做增量同步到新服务器（比如MySQL主从复制，或者每天跑一次增量备份恢复），这样切换的时候新服务器的数据和旧服务器几乎一致，不会出现用户数据断层。
双写测试：如果业务允许，切换前1-2天让旧API同时把数据写入旧库和新库，验证新数据库的写入逻辑是否正常，避免切换后出现数据丢失或异常。
灰度切换：不要一次性把所有流量切过去，可以先给a.com和api.a.com的A记录设置权重，比如旧服务器设为90，新服务器设为10，让10%的用户先访问新服务器，观察半天到一天，确认没问题再逐步调高新服务器的权重，直到完全切换。DigitalOcean的DNS支持权重记录，刚好能用。
快速回滚预案：提前把旧服务器的IP记好，一旦切换后发现新服务器有严重问题，立刻把A记录切回旧IP，同时停止新服务器的写入操作，把影响降到最小。

另外，你说要给旧服务器的用户发通知，其实可以在旧服务器的Nginx配置里加个规则，当用户访问时直接返回维护页面或者跳转到新服务器：

server {
    listen 443 ssl;
    server_name a.com api.a.com;
    # 旧证书配置保留
    ssl_certificate /path/to/old/cert.pem;
    ssl_certificate_key /path/to/old/key.pem;

    location / {
        return 302 https://b.com$request_uri; # 或者返回一个维护页面
        # 或者用root指向一个维护页面目录，然后try_files $uri /maintenance.html;
    }
}

这样用户访问旧服务器时会自动转到新服务器，体验更顺畅。

备注：内容来源于stack exchange，提问作者DaraJ