2026 年 7 月 28 日，我发现英文站 en.shuijingwanwq.com 出现了一个比之前更加严重的问题。
此前英文文章偶尔会在第一次打开时出现 5XX，例如 522、525，但刷新一次或者几次之后通常能够恢复为 200。因此，我之前决定暂时不继续深入分析这些偶发错误。
但这一次不一样。
访问刚刚发布的英文文章时，页面持续返回：
526 Invalid SSL certificate
而且反复刷新仍然无法恢复。
Cloudflare 页面显示：
Browser Working
Cloudflare Working
Host Error
最开始我一度怀疑，这是否与前一天刚刚进行的 Cloudflare URL Rewrite 配置有关。
最终排查下来，真正原因却完全在另一个地方：
服务器上同时存在 RSA 和 ECC 两套
www.shuijingwanwq.com的 acme.sh 证书记录，它们包含的域名范围不同，却共同安装到同一组 Nginx 生产证书文件。旧 RSA 证书在自动续期后，将包含en.shuijingwanwq.com的 ECC 证书覆盖，最终导致 Cloudflare Full (strict) 回源验证失败并返回 526。
整个问题甚至可以精确定位到：
2026-07-28 00:55:54 +0800
下面记录完整排查过程。
一、故障现象：从偶发 5XX 变成持续 526
英文站地址：
https://en.shuijingwanwq.com/
当天发布的新文章：
https://en.shuijingwanwq.com/2026/07/28/20502/
打开后首先看到浏览器提示：
此网站似乎存在问题
en.shuijingwanwq.com 的服务器发回一个错误：
526 No Reason Phrase
Cloudflare 的错误页面则更加明确：
Invalid SSL certificate
Error code 526
页面同时显示：
Browser Working
Cloudflare Working
Host Error
这与此前偶发的 522、525 已经明显不同。
这次刷新多次依然无法恢复。
二、最开始怀疑昨天的 Cloudflare Rewrite
前一天刚刚调整过英文站 Cloudflare URL Rewrite。
主要目标是把类似：
/2026/07/14/19522/?abc=123
转换为：
/2026/07/14/19522/
也就是：
保留文章 Path，只删除 Query String。
由于 526 恰好第二天出现，因此第一反应自然是：
会不会昨天的 Cloudflare 操作影响了英文站？
不过 526 本身已经提供了很强的排查方向。
TLS 建立发生在 HTTP Rewrite 之前。
整个链路大致是：
浏览器
↓
Cloudflare
↓ HTTPS / TLS
源站 Nginx
↓
WordPress
Cloudflare 必须先成功与源站建立 HTTPS 连接，才能继续处理后面的 HTTP 请求。
因此 URL Rewrite 本身并不能直接把一张有效证书变成无效证书。
于是先不回滚 Rewrite，而是直接检查源站 SSL。
三、第一次检查：Nginx 到底返回了什么证书？
直接绕过 Cloudflare，在服务器本机使用 SNI 请求：
echo | openssl s_client \
-connect 127.0.0.1:443 \
-servername en.shuijingwanwq.com \
2>/dev/null \
| openssl x509 \
-noout \
-subject \
-issuer \
-serial \
-dates
结果：
subject=CN = www.shuijingwanwq.com
issuer=C = AT, O = ZeroSSL GmbH, CN = ZeroSSL RSA DV SSL CA 2
serial=6E24CF545939B4D5D892B22EAB842122
notBefore=Jul 27 00:00:00 2026 GMT
notAfter=Oct 25 23:59:59 2026 GMT
证书 CN 是：
www.shuijingwanwq.com
这一点本身并不一定有问题，因为证书还可以通过 SAN 覆盖其他域名。
于是继续检查：
echo | openssl s_client \
-connect 127.0.0.1:443 \
-servername en.shuijingwanwq.com \
2>/dev/null \
| openssl x509 -noout -text \
| grep -A2 "Subject Alternative Name"
结果：
X509v3 Subject Alternative Name:
DNS:www.shuijingwanwq.com, DNS:shuijingwanwq.com
问题已经非常明显。
证书只包含：
www.shuijingwanwq.com
shuijingwanwq.com
却没有：
en.shuijingwanwq.com
四、严格验证失败，但忽略证书以后 WordPress 正常
为了进一步确认问题是不是只存在于 SSL 层，我做了两个测试。
首先正常验证证书：
curl -sS \
--max-time 20 \
--resolve en.shuijingwanwq.com:443:127.0.0.1 \
-o /dev/null \
-w 'HTTP=%{http_code}\n' \
https://en.shuijingwanwq.com/
结果：
HTTP=000
curl: (51) SSL: no alternative certificate subject name matches target host name 'en.shuijingwanwq.com'
然后使用 -k 忽略证书验证：
curl -k -sS \
--max-time 20 \
--resolve en.shuijingwanwq.com:443:127.0.0.1 \
-o /dev/null \
-w 'HTTP=%{http_code}\n' \
https://en.shuijingwanwq.com/
结果：
HTTP=200
至此可以确认：
WordPress：正常
PHP-FPM：至少能够正常处理该请求
Nginx HTTP：正常
英文站内容：正常
真正的问题就在：
SSL hostname verification
也就是说：
Cloudflare 请求
en.shuijingwanwq.com时，源站却给出了一张不包含en.shuijingwanwq.com的证书。
这正好可以解释 526。
五、继续检查 Nginx：三个域名确实共用一张证书
检查 Nginx 配置：
grep -RniE \
'server_name[[:space:]].*en\.shuijingwanwq\.com' \
/usr/local/nginx/conf \
/etc/nginx \
2>/dev/null
以及：
nginx -T 2>&1 \
| grep -n -B20 -A40 \
'server_name[[:space:]].*en\.shuijingwanwq\.com'
得到：
listen 443 ssl http2;
ssl_certificate /usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt;
ssl_certificate_key /usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key;
server_name www.shuijingwanwq.com shuijingwanwq.com en.shuijingwanwq.com;
也就是说：
www.shuijingwanwq.com
shuijingwanwq.com
en.shuijingwanwq.com
本来就是共用：
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key
这种方案本身没有问题。
前提是证书 SAN 必须同时包含三个域名。
然而当前证书只有：
www
根域名
因此 en 必然失败。
六、为什么以前正常？关键线索来自 7 月 10 日
这时我想起：
2026 年 7 月 10 日，在把英文站从：
www.shuijingwanwq.com/en/
迁移到：
en.shuijingwanwq.com
时，我曾经手动重新签发过证书。
当时申请的是包含三个域名的 ECC 证书：
www.shuijingwanwq.com
shuijingwanwq.com
en.shuijingwanwq.com
因此英文站迁移以后一直能够正常访问。
问题就变成：
既然 7 月 10 日已经申请过包含 en 的证书，为什么 7 月 28 日 Nginx 又变成了一张不包含 en 的 RSA 证书？
继续检查 acme.sh。
七、服务器竟然同时存在两套 www 证书
执行：
grep -RHE \
"^(Le_Domain|Le_Alt)=" \
/root/.acme.sh/*/*.conf \
2>/dev/null \
| grep 'shuijingwanwq\.com'
发现：
/root/.acme.sh/www.shuijingwanwq.com/www.shuijingwanwq.com.conf:
Le_Domain='www.shuijingwanwq.com'
Le_Alt='shuijingwanwq.com'
同时还存在：
/root/.acme.sh/www.shuijingwanwq.com_ecc/www.shuijingwanwq.com.conf:
Le_Domain='www.shuijingwanwq.com'
Le_Alt='shuijingwanwq.com,en.shuijingwanwq.com'
也就是说，服务器里面其实存在：
RSA 证书
/root/.acme.sh/www.shuijingwanwq.com/
覆盖：
www.shuijingwanwq.com
shuijingwanwq.com
ECC 证书
/root/.acme.sh/www.shuijingwanwq.com_ecc/
覆盖：
www.shuijingwanwq.com
shuijingwanwq.com
en.shuijingwanwq.com
此时已经非常接近根因。
八、真正的问题：两套证书写入同一个生产文件
继续查看两套 acme.sh 配置。
RSA：
Le_Keylength='2048'
Le_RealKeyPath='/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key'
Le_RealFullChainPath='/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt'
ECC：
Le_Keylength='ec-256'
Le_RealKeyPath='/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key'
Le_RealFullChainPath='/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt'
也就是说：
RSA 与 ECC 两套证书，虽然 SAN 不一样，却都把自动续期后的证书安装到完全相同的生产路径。
结构实际上变成：
RSA
www + root
\
\
→ www.shuijingwanwq.com.crt
→ www.shuijingwanwq.com.key
/
/
ECC
www + root + en
谁最后执行自动续期安装，谁就会占据 Nginx 使用的证书。
这就是隐藏了半个月的问题。
九、证据闭环：00:55:54 正好发生了 RSA 自动续期
查看当前生产证书文件时间：
stat \
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt \
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key
得到：
最近更改：
2026-07-28 00:55:54 +0800
再看 RSA acme.sh 配置：
Le_CertCreateTimeStr='2026-07-27T16:55:54Z'
换算为北京时间：
2026-07-28 00:55:54 +0800
完全一致。
然后检查 Cron：
crontab -l | grep -i acme
得到：
51 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
即：
每天 00:51
自动运行 acme.sh。
整个事故链终于完整闭环：
2026-07-28 00:51
acme.sh Cron 启动
↓
检测到旧 RSA 证书需要续期
↓
重新签发 RSA 证书
↓
SAN 仍然只有：
www.shuijingwanwq.com
shuijingwanwq.com
↓
2026-07-28 00:55:54
安装到生产：
www.shuijingwanwq.com.crt
www.shuijingwanwq.com.key
↓
覆盖原来的 ECC 三域名证书
↓
Nginx 加载新 RSA 证书
↓
en.shuijingwanwq.com 不再属于 SAN
↓
Cloudflare Full (strict) 验证失败
↓
526 Invalid SSL certificate
十、为什么 7 月 10 日之后一直没有出问题？
因为 7 月 10 日手动申请了新的 ECC 证书：
www
root
en
然后把它安装到了生产位置。
因此从 7 月 10 日到 7 月 27 日期间，Nginx 一直正常使用 ECC 三域名证书。
但问题在于：
当时只是新增了 ECC 证书，却没有处理服务器上原来存在的 RSA 自动续期记录。
旧 RSA 依然存在：
www + root
并且依然拥有生产证书文件的安装路径。
所以从表面看：
7 月 10 日：问题已经解决
实际上只是：
ECC 暂时覆盖在 RSA 上面
真正的冲突一直潜伏着。
直到旧 RSA 下一次自动续期。
十一、先恢复英文站：重新安装 ECC 三域名证书
确认根因后，没有重新签发证书。
因为 7 月 10 日那张 ECC 证书仍然有效：
notBefore=Jul 10 00:00:00 2026 GMT
notAfter=Oct 8 23:59:59 2026 GMT
于是先备份当前生产证书：
ts="$(date +%Y%m%d-%H%M%S)"
cp -a \
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt \
"/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt.bak-$ts"
cp -a \
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key \
"/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key.bak-$ts"
然后重新安装 ECC：
/root/.acme.sh/acme.sh --install-cert --ecc \
-d www.shuijingwanwq.com \
--key-file /usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key \
--fullchain-file /usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt \
--reloadcmd "nginx -t && nginx -s reload"
输出：
Installing key to:
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key
Installing full chain to:
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt
nginx: configuration file syntax is ok
nginx: configuration file test is successful
Reload success
十二、确认生产文件已经恢复为 ECC
查看生产证书：
openssl x509 \
-in /usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt \
-noout \
-subject \
-issuer \
-serial \
-dates \
-ext subjectAltName
得到：
issuer=C = AT, O = ZeroSSL GmbH, CN = ZeroSSL ECC DV SSL CA 2
X509v3 Subject Alternative Name:
DNS:www.shuijingwanwq.com
DNS:en.shuijingwanwq.com
DNS:shuijingwanwq.com
继续比较 SHA-256：
sha256sum \
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt \
/root/.acme.sh/www.shuijingwanwq.com/fullchain.cer \
/root/.acme.sh/www.shuijingwanwq.com_ecc/fullchain.cer
结果：
66c521... /usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt
58bab2... /root/.acme.sh/www.shuijingwanwq.com/fullchain.cer
66c521... /root/.acme.sh/www.shuijingwanwq.com_ecc/fullchain.cer
生产证书已经与 ECC 完全一致。
十三、连续验证 Nginx 实际提供的证书
为了避免刚 reload 后的瞬间状态造成误判，又连续测试 6 次：
for i in 1 2 3 4 5 6
do
echo | openssl s_client \
-connect 127.0.0.1:443 \
-servername en.shuijingwanwq.com \
2>/dev/null \
| openssl x509 \
-noout \
-issuer \
-serial \
-ext subjectAltName
sleep 1
done
6 次全部返回：
ZeroSSL ECC DV SSL CA 2
SAN 也全部包含：
www.shuijingwanwq.com
en.shuijingwanwq.com
shuijingwanwq.com
随后再连续验证 HTTPS：
for i in 1 2 3 4 5 6
do
curl -sS \
--max-time 20 \
--resolve en.shuijingwanwq.com:443:127.0.0.1 \
-o /dev/null \
-w "第${i}次：HTTP=%{http_code} SSL_VERIFY=%{ssl_verify_result}\n" \
https://en.shuijingwanwq.com/
sleep 1
done
得到：
第1次：HTTP=200 SSL_VERIFY=0
第2次：HTTP=200 SSL_VERIFY=0
第3次：HTTP=200 SSL_VERIFY=0
第4次：HTTP=200 SSL_VERIFY=0
第5次：HTTP=200 SSL_VERIFY=0
第6次：HTTP=200 SSL_VERIFY=0
证书恢复完成。
十四、只恢复还不够：必须解决自动续期冲突
如果只做到这里，那么问题以后还会再次出现。
因为当时两份证书的下次续期时间分别是：
ECC：
2026-09-07T02:56:34Z
RSA：
2026-09-24T16:55:54Z
假如保持不变：
9 月 7 日
ECC 自动续期
↓
生产证书包含 en
↓
正常
9 月 24 日
RSA 再次自动续期
↓
重新覆盖生产证书
↓
en 再次从 SAN 消失
↓
526 再次出现
所以真正的修复不能只是：
重新安装一次 ECC
而应该消除：
RSA / ECC 同时控制同一个生产证书
十五、将旧 RSA 证书移出自动续期
操作之前，acme.sh --list 显示：
www.shuijingwanwq.com "2048"
SAN: shuijingwanwq.com
www.shuijingwanwq.com "ec-256"
SAN: shuijingwanwq.com,en.shuijingwanwq.com
也就是说，两条 www 记录同时存在。
先备份 RSA 配置目录：
ts="$(date +%Y%m%d-%H%M%S)"
cp -a \
/root/.acme.sh/www.shuijingwanwq.com \
"/root/.acme.sh/www.shuijingwanwq.com.backup-$ts"
本次备份：
/root/.acme.sh/www.shuijingwanwq.com.backup-20260728-122113
然后把旧 RSA 证书移出自动续期：
/root/.acme.sh/acme.sh --remove \
-d www.shuijingwanwq.com
输出：
www.shuijingwanwq.com is removed,
the key and cert files are in
/root/.acme.sh/www.shuijingwanwq.com
You can remove them by yourself.
我没有继续删除这些历史文件。
保留下来反而方便以后追溯这次事故。
十六、最终只剩 ECC 三域名证书
重新执行：
/root/.acme.sh/acme.sh --list
此时 www 只剩：
www.shuijingwanwq.com
KeyLength: ec-256
SAN:
shuijingwanwq.com,en.shuijingwanwq.com
检查 ECC 自动续期配置：
Le_Domain='www.shuijingwanwq.com'
Le_Alt='shuijingwanwq.com,en.shuijingwanwq.com'
Le_Keylength='ec-256'
Le_NextRenewTimeStr='2026-09-07T02:56:34Z'
Le_RealKeyPath='/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key'
Le_RealFullChainPath='/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt'
并且 reload 命令已经调整为：
nginx -t && nginx -s reload
最终结构变成：
ECC
www.shuijingwanwq.com
shuijingwanwq.com
en.shuijingwanwq.com
↓
唯一的 www 自动续期记录
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.crt
/usr/local/nginx/conf/ssl/www.shuijingwanwq.com.key
不再存在两套证书争抢生产文件的问题。
十七、中途出现一次 HTTP 超时
完成证书修复以后，有一次本机测试出现：
HTTP=000 SSL_VERIFY=0
curl: (28) Operation timed out after 20000 milliseconds
这里的：
SSL_VERIFY=0
非常重要。
它说明：
SSL 校验已经成功，这次已经不是 526 证书问题。
因此没有再回头修改证书，而是继续区分：
Nginx / 静态资源
和：
WordPress 动态请求
十八、静态文件完全正常
连续测试 jQuery：
for i in 1 2 3
do
curl -sS \
--connect-timeout 5 \
--max-time 30 \
--resolve en.shuijingwanwq.com:443:127.0.0.1 \
-o /dev/null \
-w "第${i}次：HTTP=%{http_code} SSL=%{ssl_verify_result} CONNECT=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
https://en.shuijingwanwq.com/wp-includes/js/jquery/jquery.min.js
sleep 1
done
得到：
第1次：HTTP=200 SSL=0 TTFB=0.033743s
第2次：HTTP=200 SSL=0 TTFB=0.052860s
第3次：HTTP=200 SSL=0 TTFB=0.031175s
说明：
TCP
TLS
Nginx
静态资源
都正常。
十九、WordPress 首页也恢复 200
继续连续访问首页：
第1次：
HTTP=200
TTFB=9.024422s
第2次：
HTTP=200
TTFB=0.540921s
第3次：
HTTP=200
TTFB=0.020553s
第一次比较慢，但后面迅速降低到：
0.54 秒
0.02 秒
从现象上看，更像首次动态生成或缓存 MISS 后逐渐进入缓存状态。
这与本次 526 已经不是同一个问题，因此没有继续扩大排查范围。
二十、最终从公网验证 Cloudflare
最后回到本地电脑，不再使用：
--resolve ... 127.0.0.1
而是真正通过公网 Cloudflare 访问最开始发生 526 的文章：
for i in 1 2 3
do
echo "========== 第 ${i} 次 =========="
curl -sS \
--connect-timeout 10 \
--max-time 30 \
-o /dev/null \
-D - \
https://en.shuijingwanwq.com/2026/07/28/20502/ \
| grep -Ei '^(HTTP/|server:|cf-ray:|cf-cache-status:|age:|location:)'
sleep 2
done
结果：
第 1 次
HTTP/2 200
server: cloudflare
cf-cache-status: MISS
cf-ray: ...-LAX
第二次：
HTTP/2 200
server: cloudflare
age: 3
cf-cache-status: HIT
cf-ray: ...-LAX
第三次：
HTTP/2 200
server: cloudflare
age: 6
cf-cache-status: HIT
cf-ray: ...-LAX
这是最终最重要的一组结果。
第一笔：
MISS
意味着 Cloudflare 真正执行了回源。
而它能够得到：
HTTP/2 200
说明：
Cloudflare
↓
源站 TLS
↓
证书验证
↓
Nginx
↓
WordPress
已经全部正常。
随后两笔：
HIT
说明页面也已经正常进入 Cloudflare 缓存。
二十一、最终根因
这次问题并不是：
Cloudflare URL Rewrite 配置错误
也不是：
WordPress 故障
PHP-FPM 故障
文章发布异常
真正根因是：
2026 年 7 月 10 日为了迁移英文子域，手工新增了一张包含
en.shuijingwanwq.com的 ECC 证书，但服务器原来的 RSA 两域名证书仍然保留自动续期配置，而且 RSA 和 ECC 两份证书都安装到同一组 Nginx 生产证书路径。
最终形成：
RSA
www + root
\
→ 同一个 crt/key
/
ECC
www + root + en
7 月 28 日凌晨，旧 RSA 自动续期：
00:51 Cron 启动
↓
00:55:54 RSA 新证书生成并安装
↓
覆盖 ECC
↓
en 从 SAN 中消失
↓
Cloudflare Full (strict)
↓
526 Invalid SSL certificate
二十二、这次排查最值得记住的几个经验
1. 手动补发证书以后，要检查旧自动续期记录
手工重新签发证书成功，并不意味着未来续期也一定正确。
尤其是从：
www + root
扩展成：
www + root + en
时，必须确认旧证书任务是否仍然存在。
否则很可能出现：
现在正常
↓
几个月后自动续期
↓
旧配置重新覆盖
↓
故障突然回来
2. 同一个生产证书文件最好只存在一个“写入者”
这次真正危险的不是：
同时存在 RSA 和 ECC
而是：
两者都拥有：
Le_RealKeyPath
Le_RealFullChainPath
而且目标完全相同。
也就是说，两套证书都可以改生产文件。
这种配置非常容易形成隐藏的竞争关系。
3. 证书的 notBefore 与实际部署时间不是一回事
最开始看到：
notBefore=Jul 27 00:00:00 2026 GMT
容易理解成：
7 月 27 日证书已经部署
但真正有决定意义的是生产文件：
mtime
这次：
2026-07-28 00:55:54 +0800
与：
Le_CertCreateTimeStr
转换后的北京时间完全一致。
这才真正把证书续期和生产故障串了起来。
4. curl -k 是非常有效的分层工具
这次有一个非常关键的对比：
正常：
HTTP=000
certificate hostname mismatch
忽略证书：
HTTP=200
仅仅两条请求，就把问题从：
WordPress？
PHP？
Nginx？
SSL？
迅速缩小到：
SSL
对于 Cloudflare 526，这种测试非常实用。
5. Cloudflare Full (strict) 不应该因为 526 就关掉
解决 526 的一种“快速方式”可能是降低 SSL 校验强度。
但这实际上只是绕过问题。
这次如果直接修改 Cloudflare SSL 模式，页面可能暂时恢复，但：
源站依然拿错证书
RSA / ECC 冲突依然存在
下次续期依然不可控
真正应该修的是：
证书本身
+
自动续期生命周期
因此这次没有修改 Cloudflare Full (strict)。
二十三、关于此前偶发的 522 / 525
在这次持续 526 之前，英文站其实已经偶尔出现过：
522
525
而且经常：
第一次失败
第二次刷新正常
这次排查曾一度让我怀疑，两者是不是存在直接联系。
不过现在能够明确确认的只是：
7 月 28 日持续出现的 526，直接原因就是 RSA 两域名证书覆盖 ECC 三域名证书。
至于此前偶发 522 / 525 是否还有其他链路问题，目前没有继续扩大排查。
因此暂时保持原计划：
先不分析偶发 522 / 525。
等以后如果它们再次稳定复现，再单独排查，避免把两个问题混在一起。
二十四、最终结果
修复完成以后：
源站证书：
ZeroSSL ECC DV SSL CA 2
SAN：
www.shuijingwanwq.com
shuijingwanwq.com
en.shuijingwanwq.com
本机源站：
HTTP=200
SSL_VERIFY=0
公网 Cloudflare：
MISS → HTTP/2 200
HIT → HTTP/2 200
HIT → HTTP/2 200
acme.sh 中旧 RSA 自动续期记录已经移除。
现在负责生产环境的只剩：
www.shuijingwanwq.com
ec-256
SAN:
shuijingwanwq.com
en.shuijingwanwq.com
至此，这次 Cloudflare 526 故障正式解决。
总结
这次故障最有意思的一点，在于：
真正的问题并不是当天新产生的配置错误，而是半个月前留下的一处证书生命周期冲突，直到旧证书自动续期时才真正爆发。
7 月 10 日迁移英文子域时，我确实已经正确签发并部署了包含：
en.shuijingwanwq.com
的 ECC 证书。
因此英文站能够连续正常运行十多天。
但服务器原来的 RSA 证书并没有消失。
它仍然：
自动续期
+
拥有相同生产安装路径
于是到了 7 月 28 日凌晨：
一次完全“成功”的自动续期
反而造成了生产故障。
这也让我再次意识到：
自动化配置最危险的情况，并不一定是“任务执行失败”，反而可能是“旧任务继续成功执行”。
因为从 acme.sh 的角度：
证书申请成功
文件安装成功
Nginx 重启成功
整个流程没有任何异常。
真正的问题只是：
它成功安装了“不再适合当前架构”的旧证书。
最终解决方案也不只是重新部署一次正确证书，而是把旧 RSA 自动续期任务移除，只让 ECC 三域名证书拥有生产证书文件的控制权。
这样，这次修复才算真正完成。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复