コンテナの再起動でSSLが反映されるまで約60分ほどラグがあるようだ

Ubuntu24.04LTSがアップデートされると「再起動せよ」と出るので一旦すべてのコンテナをDownして再起動させてからup -dするのだけれども、その際にSSLで接続できない時間が60分ほどできてしまう。httpでは問題なく接続できるのだが….

一応SSLテスト（https://www.ssllabs.com/ssltest/）ではA+の判定なんだが、どうしてこの現象が起きるのだろう。

なんか60分経てば接続できるんだけど何か気持ち悪。詳しく調べてみよ

LOGを確認したらletsencryptの起動に失敗しているみたいでこれが原因ぽい。letsencryptとNginxのSSL証明書の受け渡しができてないのでSSLでは接続できないがHTTPでは接続できるという事のようだ。このエラーメッセージは、通常Let’s EncryptからSSL証明書を更新または取得しようとしたときによく発生します。これは、検証サーバーが指定された IP アドレス (219.161.118.112) のサーバーに接続できず、必要なチャレンジ (通常は HTTP または DNS チャレンジ) を実行できなかったことを示します。この問題を解決するには、サーバーのネットワーク構成を確認し、ポート 80/443 の着信接続に関するファイアウォールルールをチェックし、Web サーバーと ACME クライアントの設定が正しいことを確認します。との事だけど、ufwの設定は問題ないからログにあるacme.shをマウントしてないのが原因だろうか？

lets-encrypt | Warning: ‘/etc/acme.sh’ does not appear to be a mounted volume.
lets-encrypt | Warning: /app/letsencrypt_service_data not found, skipping data from containers.

nginx-proxy | Warning: TRUST_DOWNSTREAM_PROXY is not set; defaulting to “true”. For security, you should explicitly set TRUST_DOWNSTREAM_PROXY to “false” if there is not a trusted reverse proxy in front of this proxy.
nginx-proxy | Warning: The default value of TRUST_DOWNSTREAM_PROXY might change to “false” in a future version of nginx-proxy. If you require TRUST_DOWNSTREAM_PROXY to be enabled, explicitly set it to “true”.

lets-encrypt | [Sat Nov 8 07:08:37 UTC 2025] Pending. The CA is processing your order, please wait. (1/30)
lets-encrypt | [Sat Nov 8 07:08:40 UTC 2025] plusload.net: Invalid status. Verification error details: 219.161.118.112: Fetching http://plusload.net/.well-known/acme-challenge/***********: Error getting validation data
lets-encrypt | [Sat Nov 8 07:08:40 UTC 2025] Please check log file for more details: /dev/nulllets-encrypt | Reloading nginx proxy (a*****************************)…
lets-encrypt | Generated ‘/etc/nginx/conf.d/default.conf’ from 6 containers
lets-encrypt | Reloading nginx proxy (9*****************************)…
lets-encrypt | Contents of /etc/nginx/conf.d/default.conf did not change. Skipping notification ”
lets-encrypt | Sleep for 3600s

ちょうど1時間スリープしてるし。どうもdefault.confが更新されないのに再起動を試みたんで以降の処理をスキップして3600秒（1時間）letsencriptでの処理を停止するということらしい。lets-encryptの問題なんだな。
通常の場合で証明書の確認・更新された場合は

lets-encrypt Account update success for https://acme-v02.api.letsencrypt.org/acme/acct/2——9.
lets-encrypt ACCOUNT_THUMBPRINT=’x*************36******m’.
lets-encrypt Creating/renewal plusload.net certificates… (plusload.net).
lets-encrypt Domains not changed.
lets-encrypt Skipping. Next renewal time is: 2026-01-06T07:29:47Z.
lets-encrypt Add ‘–force’ to force renewal.
lets-encrypt Sleep for 3600s

となって、3600秒毎にSSL証明書の有効期限をチェックしてるみたいなので失敗すると同様に3600秒待機するので。なんかスッキリした。が、相変わらずコンテナを再起動すると60分SSL証明書が無効になってHTTPS接続ができなくなる。HTTPではいけるんだが…なんか解決方法はないんか？

Geminiに来てみたら

letsencrypt-nginx-proxy-companion（Nginx Proxy Companion）コンテナを再起動した際に、SSL証明書が無効になりHTTPS接続ができなくなる現象は、主にコンテナの起動シーケンスと証明書の再生成タイミングのズレ、あるいはボリュームの永続化不備が原因です。

60分間無効になる、という具体的な時間経過は、Let’s EncryptのAPI制限（Rate Limits）や、コンテナが再試行（retry）を行う設定値に関係している可能性が高いです。

以下の対策と確認事項を実施してください。

原因と対策

1. ボリュームが永続化されていない (Certificates not persisted)

最も多い原因は、取得した証明書がDockerコンテナの再起動によって削除されてしまっていることです。

対策: letsencrypt-nginx-proxy-companion コンテナの /etc/nginx/certs がホストディレクトリに永続的にマウントされているか確認してください。

確認点:

yaml

# docker-compose.yml の例
volumes:
  - /path/to/certs:/etc/nginx/certs # ここが重要
  - /var/run/docker.sock:/var/run/docker.sock:ro

2. Nginxコンテナの再読込遅延

nginx-proxy (Nginxコンテナ) が新しい証明書を認識する前にコンテナが起動し、古いまたは存在しない証明書を参照している可能性があります。

対策: 起動順序を正しくする。コンテナ再起動後にNginxが設定を再読み込みするまで少し待つ必要がある場合があります。

3. Let’s Encrypt のAPI制限 (Rate Limits)

短時間に再起動を繰り返すと、Let’s Encryptから「同一ドメインへの証明書発行回数過多」と見なされ、1時間（またはそれ以上）ブロックされることがあります。

対策: 60分経過して復旧したなら、これが原因である可能性が高いです。再起動の頻度を下げてください。

4. 証明書のパス不整合

nginx-proxy と companion コンテナ間で、証明書を共有するボリュームのマウントパスが一致していない。

対策: 両方のコンテナで certs ボリュームが同じ場所（例: /etc/nginx/certs）を参照していることを確認する。

とのこと。60secで復旧するのでLet’s Encrypt のAPI制限 (Rate Limits)に該当しているっぽいね…再起動の頻度を下げるのはどうすんだろ…

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル