通常使用する簡単なテストは、nginxがチャレンジファイルを配信するディレクトリに、拡張子なしで「1234」という名前のファイルを作成し、その中に「5678」という内容を記述することです。そのファイルを携帯電話のブラウザ（自宅のWi-Fiではなく、モバイル通信を使用）からアクセスできれば、通常はLet’s Encryptの認証サーバー（プライマリ1つとセカンダリ3つ）もアクセスできます。
「いいね！」 1
ただし、Discourseは実行しないものの、他のサイトのためにApacheを実行している（おそらくcertbotを使用していたと思いますが、確認が必要です）同じ静的IPアドレスの状況にある2台目のボックスは、問題なく定期的に証明書を更新していることも付け加えておくべきです。
「いいね！」 2
外部インフラストラクチャに関しては、それは良い兆候です。オニオンに関しては、ルートからディスコースボックス、そして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アプリの再構築ですぐに更新された証明書が取り込まれ、完全な運用に戻りました。ジョナサン、そして皆さん、ありがとうございました！良い新年をお迎えください！
「いいね！」 3
素晴らしい！
すぐに解決してよかったです！
良いお年をお迎えください！
「いいね！」 3
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.