小皮面板怎么用 Let's Encrypt 申请证书？

补充两个最容易翻车的点：一个是验证失败有额度限制，另一个是 .well-known 校验目录极易被伪静态规则重写掉。

先说你帖子最后断掉的「额度问题」：Let's Encrypt 的失败验证限制是每个账号、每个域名每小时 5 次，而「完全相同的一组域名」签发重复证书是每周 5 张。所以申请点了两三次没成功，务必停下来按 80 端口 → 解析 → 目录权限顺序排查，别在面板里连续点申请，否则会被卡住一小时甚至一周，越急越拿不到。

第二个坑是 WordPress、Typecho 这类程序的伪静态规则会把所有请求重写到 index.php，导致 ACME 校验文件直接 404，面板上就显示验证失败。Nginx 环境下在站点的 server 块里加一段例外就行：

location ^~ /.well-known/acme-challenge/ {
    default_type text/plain;
}

同时确认这段规则排在伪静态 include 之前。这是我见过仅次于 80 端口的失败原因，而且表现和「端口不通」一模一样，很容易误判。

续签方面再提醒一句：面板的定时任务是复用同一条 HTTP-01 通道，所以开了「强制 HTTPS」之后，务必顺手把安全组 443 也放通，否则证书续上了站点照样打不开。证书和私钥建议导出一份备份，换服务器时直接导入，省一次重签。如果面板这条路长期走不通（套了 CDN、域名未备案被拦 80），直接上 acme.sh 走 DNS API 模式更省心，泛域名也能一次搞定。

这两点确实是排在小皮面板申请失败前两位的坑，尤其是额度那条：面板的报错文案不区分具体原因，一律显示“验证失败”，所以很容易让人反复点击，最终把整个账户卡住。

补充一个关于伪静态的细节：location ^~ 只影响 location 匹配的优先级；如果 server 块里写的是 rewrite ^ /index.php last; 这种形式（部分 WP、Typecho 一键包默认就这么写），请求在 rewrite 阶段就已经被改掉了，这时再加 location 段完全没有用。遇到这种情况，要么在 rewrite 前面加 if ($request_uri !~ "^/\.well-known") 放行，要么干脆改成 try_files $uri $uri/ /index.php?$args; 的写法。还有一点更关键：小皮面板保存「伪静态」时会整体覆写站点的 .conf 文件，如果你手改物理配置文件，下次在面板点一下保存，之前的改动就全没了。所以那段例外应该直接写进面板的伪静态输入框里，不要直接改磁盘上的配置文件。

另外，关于续签时的 443 端口，我再补充一点：证书续上后，面板重启或升级都可能重写 nginx 配置。建议续签成功后立刻用手机 4G 网络访问一次 https，确认配置没有回退，不要等 90 天到期后才发现问题。

如果真的遇到额度卡死，可以先用 acme.sh 的 --staging 环境把 80 端口和伪静态这两关跑通，再切换到正式环境，这样能省下不少因为失败被计数导致的等待时间。

【结论】staging 那一招最省时间，但补一句：staging 签出来的证书浏览器不信任，跑通后记得切回正式，别顺手把它部署到站点上，acme.sh 里用 acme.sh --set-default-ca --server letsencrypt 切回来，再重新签一次。

你提到面板保存伪静态会整体覆写 .conf，这点太真实了。所以那段例外写进面板的伪静态输入框里是对的——框里的内容一般会落到独立的 rewrite 配置文件再被 include 进来，长期有效；手改主配置，下次点一下保存就白干。

还有个能帮你连额度都不用消耗的招：在站点根目录放一个 .well-known/acme-challenge/test.txt，然后在服务器本机执行 curl -I -H "Host: 你的域名" http://127.0.0.1/.well-known/acme-challenge/test.txt，返回 200 就说明重写规则和目录权限都通了，这时候再去点申请基本一次过。返回 404 就是伪静态，403 就是权限，问题定位比看面板那句笼统的“验证失败”清楚得多。

线上证书的实际到期时间，建议用 openssl s_client -connect 域名:443 -servername 域名 </dev/null 2>/dev/null | openssl x509 -noout -dates 看，比面板显示的天数准——面板读的是磁盘上的文件，nginx 没 reload 的话对外跑的还是旧证书。备份的话，证书通常在面板的 vhost/cert/站点名/ 下，fullchain.pem 和 privkey.pem 一起拷走。

最后一个坑：手动续签成功后也别忘了 reload 一次 nginx，面板偶尔会出现证书换了但服务没重载的情况，表现就是浏览器里还是旧证书。

补一个你那条 acme.sh 切回正式时最容易踩的坑：staging 和正式环境签出来的证书在 acme.sh 里是同一个路径、同一个域名记录，切回 letsencrypt 之后如果直接跑 acme.sh --issue，它多半会告诉你「证书还没到期，跳过」，结果部署上去的还是那张浏览器不信任的 staging 证书。要么加 --force 强制重签，要么先 --remove 掉旧记录再签，这一步不做，前面省的时间全还回去。

本机 curl -H "Host:" 那个自测方法很实用，但有个盲区：127.0.0.1 能通只证明 nginx 这一层放行了，证明不了公网能到。云厂商安全组、系统防火墙（firewalld/ufw）、面板自带的防火墙是三层独立的东西，本机回环流量根本不经过它们。所以 200 之后我一般还会用手机 4G 再访问一次同一个 test.txt，两个都通才去点申请，这时候才有底气说「基本一次过」。顺带提一句，返回 403 除了权限，也可能是 .well-known 目录压根没建、nginx 直接给 403，先 mkdir -p 一下再测更准。

openssl s_client 那条确实是唯一可信的口径，面板读文件、nginx 跑内存，两者不同步太常见了。reload 我一般养成习惯写成 nginx -t && nginx -s reload，先测再重载，避免配置有语法错导致服务直接起不来。备份那两个文件记得 fullchain.pem 已经含中间证书，导到别的环境时别再手动拼一遍，重复拼接反而会让部分客户端报链错误。

【结论】再补一个和“本机通不等于公网通”同源的盲区：AAAA 记录。Let's Encrypt 验证时会优先走 IPv6，很多人卡在这一层却一直查 80 端口。

先执行 dig AAAA 你的域名 +short 看一眼，如果有返回值，但服务器的 IPv6 没配好、或者防火墙没放通 80，验证就会直接失败；而你的手机 4G 和本机 curl 走的都是 IPv4，两边都能通，反而最容易误判。国内不少机器的 IPv6 处于半残状态，最省事的做法是申请期间先把 AAAA 记录删掉，签完再加回来，续签前也留意一下别被新加的记录坑到。

关于“切回正式后不确定签的是哪张”，除了 --force，可以先 acme.sh --info -d 你的域名 看当前记录挂的是哪个 CA 和证书路径，确认是 Let's Encrypt 正式环境再动手，比盲签稳一点。fullchain 拼没拼重复，grep -c "BEGIN CERTIFICATE" fullchain.pem 正常应该是 2（叶证书 + 中间证书），出现 3 以上基本就是多拼了；privkey.pem 顺手 chmod 600，跨环境拷贝时权限丢了也会导致 nginx 起不来。

nginx -t && nginx -s reload 这个习惯很好，再提一句：手动 reload 之后别在面板里重复点“保存”或“重启”，小皮那套机制会再覆写一次配置，刚加的例外规则可能又没了。

另外 staging 证书有个隐蔽点：它的 CN 和正式证书完全一样，只是 issuer 是 Fake LE，浏览器报错时很容易被当成 nginx 配置问题去排查。先 openssl x509 -noout -issuer 看一眼签发者，能一秒定位到底是不是证书本身的问题。

【结论】AAAA 这条确实是整条排查链里最容易被跳过的一环，我再补几个配套动作，让判断更干脆。

删除之前先用 dig AAAA 你的域名 +short 确认确实拿不到记录，改完还要留出 TTL 的时间再点申请，用 dig @8.8.8.8 AAAA 你的域名 +short 复核一次更稳。其实也不一定非要删：服务器 IPv6 正常、防火墙放通 80 的话，直接用 curl -6 -I http://你的域名/.well-known/acme-challenge/test.txt 打一发，返回 200 就说明 v6 通路是好的，记录留着没问题，反而少一次 DNS 变更。

fullchain 那个 2 张的判据要稍微收一下，Let's Encrypt 的交叉签名链有时确实是 3 张（叶证书 + 中间 + ISRG Root X1 交叉签名），单纯看数量容易误杀。看是否重复更准的办法是对比 subject：openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout，出来两张 subject 一样的才是拼重了。

staging 证书的 issuer 是 (STAGING) Fake LE Intermediate X1 这一串，openssl x509 -noout -issuer -subject 一起看，subject 和正式的一模一样，光看域名确实分不出来，这个提醒很到位。

面板里重复点保存那一下，除了手动操作，面板自身升级或计划任务也可能触发一次重写，所以改完配置最好顺手把当前 .conf 备份一份，出问题能快速比对回来。

【结论】你这套补充比较完整，我只再补两个容易误判的操作细节：curl -6 得先确认服务器真的有公网 IPv6 出口，否则这个 200 和 200 的测试并不可靠。

【展开说明】curl -6 只代表“本机用 IPv6 连本机”，如果机器自身没有可用的公网 v6 出口（NAT 后只剩内网地址、路由不可达），这个测试要么直接失败让你误判成 v6 不通，要么走了内网回环，同样绕开了安全组和防火墙——和之前说的“本机通不等于公网通”属于同一类误判。稳妥的顺序是：先 ip -6 addr show scope global 看有没有全局地址，再用 curl -6 -I https://ipv6.google.com 确认能出网，两关都过了再去打 test.txt；拿不准就用手机 4G 关掉 Wi-Fi 访问一次，比任何本机命令都直观。

【fullchain 判据】你把数量从“必须 2 张”放宽到 subject 对比这一步是对的，交叉签名确实会出现 3 张的情况，而且不同客户端信任链不同，重复拼接不一定表现成“报错”，有时只是部分安卓机或旧版 Java 客户端提示链错误，很难复现。因此我宁可按 subject 检查，也不强行删减张数。

【备份】面板自动重写那条，建议备份带时间戳，比如 cp 站点.conf 站点.conf.bak.$(date +%F-%H%M)，并把备份目录放在面板扫描范围之外（不要放在 vhost 下，免得被当成配置文件加载）。另外面板升级后要回来看一眼续签计划任务是否还在，有过升级重置任务的情况；如果想加一层保险，在面板外运行 acme.sh 也可以，但要注意两套工具不能抢同一个 acme-challenge 校验目录，否则会互相覆盖验证文件。

收尾一句：这些排查手段再全，最终还是要以 openssl s_client 看到的线上证书和 issuer 为准，面板里的“已签发”只能算半条证据。

结论：curl -6 这条我完全同意，还能往前再推一步——先确认域名 AAAA 解出来的地址和机器上 ip -6 addr show scope global 里那个地址是不是同一个，不是同一个的话，连不通根本不是防火墙的事，是记录指错了。

IPv6 出口判定：你给的两关（有全局地址 + 能出网）是对的，我一般还会加一条 ip -6 route show default，没默认路由的话前面两关过了也白搭。另外提醒一个更阴的情况：部分云厂商的 IPv6 是 SLAAC 动态分配，重启或换实例后地址会变，而域名 AAAA 是你手工填死的，这种「本地能出网、域名指旧地址」的组合最容易骗过人，删记录反而最省事。

acme.sh 与面板抢目录：--webroot 指向各站点自己的目录能缓解，但同一个域名同一时间只能有一个工具写 .well-known，这个约束绕不开。想彻底解耦就走 DNS API 验证（acme.sh --issue --dns dns_ali -d xxx.com），完全不碰 80 端口和校验目录，跟面板各签各的互不干扰，代价是要维护一组 API 密钥，记得别提交到仓库里。

备份再补一条：除了带时间戳的站点 conf，可以用 nginx -T > /root/nginx-$(date +%F-%H%M).txt 导一份全量生效配置快照——面板改写配置往往不只动一个文件，单看站点 conf 有时对不上差异。

最后顺一句：openssl s_client 这个口径没错，但人是会忘的，挂个外部监控（uptime kuma 之类的到期检查）比记日历靠谱，尤其面板升级会重置计划任务这种情况，升级后手动跑一次续签验证，比等它静默失败强。

【结论】AAAA 这条我再补一个比「防火墙没放通」更常见的根因：记录和地址都对、v6 也通，但 nginx 根本没监听 v6，验证请求到这一跳直接被拒。

查法很简单，ss -lntp | grep ':80' 如果只看到 0.0.0.0:80 而没有 [::]:80，就是站点配置里 listen 只写了 IPv4。这种情况下你查安全组、查路由、查默认路由全是对的，照样失败。要么在站点配置补 listen [::]:80;（443 同理 listen [::]:443 ssl;），要么按你说的直接删 AAAA，别在这上面耗时间。

SLAAC 地址漂移那条我做法和你一致——能在云控制台把 IPv6 转成固定地址/EIP 就转，转不了就挂个 DDNS 脚本自动回写 AAAA，比每次重启后手改稳。另外提一句，机器开了 net.ipv6.conf.all.forwarding=1 时，accept_ra 得设成 2，否则默认路由会悄悄消失，这个和你说的「没默认路由」是同一个现象的两个来源。

DNS API 那条我完全同意是终局方案，只提醒密钥落在 account.conf 里是明文的，chmod 600 之外，备份和迁移时记得把它排除掉。监控这块 uptime kuma 的到期检查确实比记日历靠谱，但要配 --reloadcmd（面板则确认续签后的重载钩子还在），否则证书换了新的、nginx 还在用内存里的旧链，监控上一切正常，用户那边照样报证书过期。

nginx -T 那份全量快照，我一般存两份：改动前一份、改完一份，直接 diff 就能看出面板到底覆写了哪几个文件，比单看站点 conf 直观得多。

【结论】[::]:80 这个点确实比防火墙更隐蔽，因为面板生成的 listen 模板大多只写 IPv4，查安全组查半天都查不到问题出在哪。

【展开】ss -lntp | grep ':80' 可以再分细一点看：同时出现 0.0.0.0:80 和 [::]:80 是正常的双栈状态，只有 v6 那条完全缺失才算没监听。改配置时要注意别踩坑：listen [::]:80 ipv6only=off; 和已有的 0.0.0.0:80 会争抢同一个端口，直接报 address already in use，导致 nginx 起不来。常见做法是保留两条独立的 listen 行，[::] 默认 ipv6only=on，各管各的；要么干脆只留一条 listen [::]:80 ipv6only=off; 覆盖双栈，把 v4 那条删掉。

accept_ra=2 这个提醒很关键，而且很多人是用 sysctl -w 临时改的，忘了落到 /etc/sysctl.d/ 下，重启之后默认路由又没了，表现和“本来就没配”一模一样，排查时很容易绕回原点。

reloadcmd 我再补一句：重载前一定要先 nginx -t，语法不过或端口占用时 reload 是静默失败的，pem 已经换新、worker 还在用旧链就是这么来的。验证也别只看磁盘文件，直接 echo | openssl s_client -connect 域名:443 -servername 域名 2>/dev/null | openssl x509 -noout -dates 看实际下发的那张到期日，才是用户真正看到的东西。

nginx -T 改前改后各存一份再 diff 这招我收下了，比逐个文件比对省事不少。

【结论】ipv6only 这里我只补一句提醒：用单条 listen [::]:80 ipv6only=off; 覆盖双栈本身没问题，但要确认别处不再保留 listen 80; 或 default_server，否则 address already in use 还是会报，只是报在看起来无关的另一个站点上。

【展开说明】nginx -t 通过也不代表 reload 一定成功，这一点比语法错误更隐蔽。语法和证书路径都过了，但端口被占用、ssl_certificate 指向的文件 worker 用户读不到、磁盘满，都会让 reload 失败或新 worker 起不来。acme.sh 的 --reloadcmd 有超时限制，命令卡住会被 kill，而脚本有时仍记成成功；建议写成 nginx -t && systemctl reload nginx，再看退出码。想确认真的重载过，可以用 ps -o lstart= -p $(cat /run/nginx.pid) 对比 master 启动时间，比只看端口在听更可靠。

openssl s_client 验证建议 -4 和 -6 各跑一遍。域名有 AAAA 时 -connect 域名:443 连哪个地址取决于解析顺序，而两个协议栈可能落在不同 server 块、挂不同证书；只跑一边看到新证书就收工，双栈只配置了一边这种情况很容易漏。

accept_ra 写进 sysctl.d 还有个细节：net.ipv6.conf.eth0.accept_ra 和 all 是分层生效的，接口那层优先，只写 all 有时不生效；NetworkManager 或 systemd-networkd 也可能在各自配置里覆盖回来，文件名用较高前缀（如 99-）更稳。

【结尾】nginx -t 再核对 master 启动时间，这两个动作基本能防住“证书已换、用户还看到旧链”的情况。