私はこのようなサーバーファイルを持っています
server {
listen 80;
server_name subdomain.example.com;
return 301 https://$server_name$request_uri;
location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}
}
Sudo letsencrypt renew
を試してみます。それがスローされ、.well-known/acme-challenge
が見つからないというエラーが表示されます。しかし、コメントするとすぐにreturn 301
行がサーバーを再起動し、動作しました。
ここで、場所を最初にしてreturn 301ステートメントにコメントを付けずに再テストしたいのですが、certificate not due for renewal
と表示されています。問題は、ファイルが読み取られる順序ですが、重要ですか?そして、私にとってこの理由のため、それは自動的に更新されません。更新を行う人は、この状況をどのように処理しますか?
この場合、それはそれほど順序ではありません(場所と正規表現がどのように評価されるかについての良い説明はここにあります: https://www.digitalocean.com/community/tutorials/understanding-nginx- server-and-location-block-selection-algorithms )。
ロケーションブロックなどの場合、短いバージョンは最初の一致ではなく、ベストマッチの勝利です。
ただし、あなたの場合、return
を使用しているため、注文は重要です。 https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return :
処理を停止し、指定されたコードをクライアントに返します。非標準コード444は、応答ヘッダーを送信せずに接続を閉じます。
ここで重要なのは、return
がすぐに処理/評価を停止するということです。そのため、nginxがreturn
の下を見ていません。
したがって、そのreturn
句をロケーションブロックの下に移動するだけです。
テストに関しては、--test-cert
をコマンドラインに追加します( https://certbot.eff.org/docs/using.html#certbot-command-line-options を参照)。
これにより、本番サーバーを使用しようとしたときに発生する「問題」を回避できます。これにより、有効な証明書があり、現在新しい証明書は必要ありません。
return
ディレクティブをlocation
ブロックに含める必要があります。その後、通常のlocation
ブロックマッチングルールが使用されます。
server {
listen 80;
server_name subdomain.example.com;
location / {
return 301 https://$server_name$request_uri;
}
location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}
}
answering for the idea of line orders in nginx config files
はい。Nginxがサポートするさまざまなコンテキスト内で指定されたさまざまなディレクティブに依存します。素人の言葉で言えば、nginxはやるべきことのスタックを保持し、best match
を念頭に置いて特定のアルゴリズムをそれぞれ適用します。
Nginxはselection algorithm
を使用してserver
コンテキストで決定を行います。主に2つのディレクティブvizに基づいています。 listen
およびserver_name
。
複数のロケーションコンテキストを定義できます。各ロケーションは、特定のタイプのクライアント要求を処理するために使用されます。各ロケーションは、selection algorithm
を介してロケーション定義をクライアント要求と照合することによって選択されます。
upstream
コンテキストは、デフォルトでround-robin
を使用して、リクエストを渡す特定のサーバーを決定します。