我们通常使用的一个简单测试是，在 nginx 提供挑战文件的目录中创建一个名为 1234（无扩展名）且内容为“5678”的文件。如果你能通过手机浏览器（使用你的无线服务，而不是你自己的 Wi-Fi）访问该文件，那么 Let’s Encrypt 的身份验证服务器（一个主服务器和三个辅助服务器）通常也能访问。
1 个赞
不过，我应该补充一点，另一台具有相同静态 IP 地址情况的服务器，它不运行 Discourse，但运行 Apache 来托管其他网站（我认为现在使用 certbot，我需要确认一下），一直在顺利续订证书。
2 个赞
就外部基础设施而言，这是一个好迹象。就洋葱而言，这意味着我们正在从路由到 Discourse 框向内搜索到 acme.sh 容器。这个功能已经运行了一段时间但突然失败的事实表明，某种更新或配置更改是可能的原因。
3 个赞
请在您尝试了手动文件创建和访问测试后告知我。这通常是一个非常可靠的试金石。
1 个赞
我们也喜欢使用此工具来检查响应：
地址应如下所示：
http://yourdomain.com/.well-known/acme-challenge/1234
如果从手机测试手动文件 1234 和 https://redirect-checker.org/ 都有效，那么这清楚地表明 ACME 客户端进程使用的脚本/参数是您烦恼的根源。
2 个赞
太棒了！这个问题解决了。根本原因是通过一个提供与 Discourse 论坛关联的单个 IP 地址的隧道连接不佳。虽然通过包括外部网站在内的其他网站进行的测试并未显示此问题，但您推荐的通过移动设备进行的测试（我应该想到的，但由于我进行了所有其他测试，这次我就是没想到）确实显示了性能问题，这显然足以阻止证书续订完成（通过 Let’s Encrypt 使用的路由）。一旦将隧道确定为罪魁祸首，解决这个问题就变得很简单了，重新构建 Discourse 应用后立即获得了更新的证书，因此恢复了全面运行。谢谢 Jonathan 和大家！祝你们新年快乐！
3 个赞
太棒了！
很高兴问题这么快就解决了！
祝您新年快乐！
3 个赞
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.