NGINX設定の2つの場所に同じルールを設定するにはどうすればいいですか?
私は以下を試しました
server {
location /first/location/ | /second/location/ {
..
..
}
}
しかしnginxのリロードはこのエラーを投げました:
nginx: [emerg] invalid number of arguments in "location" directive**
やってみる
location ~ ^/(first/location|second/location)/ {
...
}
~
は、URLに正規表現を使用することを意味します。 ^
は最初の文字からチェックすることを意味します。これは/
とそれに続くいずれかの場所、そして次に別の/
を探します。
もう1つのオプションは、インクルードファイルを使用して2つのプレフィックスの場所でルールを繰り返すことです。接頭辞の場所は設定内では位置に依存しないため、後で他の正規表現の場所を追加するときにそれらを使用すると混乱を防ぐことができます。可能であれば正規表現の場所を避けることで、設定をスムーズに拡大できます。
server {
location /first/location/ {
include shared.conf;
}
location /second/location/ {
include shared.conf;
}
}
これがサンプルのshared.confです。
default_type text/plain;
return 200 "http_user_agent: $http_user_agent
remote_addr: $remote_addr
remote_port: $remote_port
scheme: $scheme
nginx_version: $nginx_version
";
正規表現とインクルードファイルの両方が良い方法であり、私はそれらを頻繁に使います。しかし、もう1つの方法は「名前付き場所」を使用することです。これは多くの状況、特に複雑な状況で有効な方法です。 公式の "If is Evil"ページ は、物事を進めるための良い方法として、基本的に次のことを示しています。
error_page 418 = @common_location;
location /first/location/ {
return 418;
}
location /second/location/ {
return 418;
}
location @common_location {
# The common configuration...
}
これらのさまざまなアプローチには長所と短所があります。正規表現の大きな利点の1つは、マッチの一部をキャプチャしてそれらを使用してレスポンスを変更できることです。もちろん、元のブロックに変数を設定するか、または map
を使用することで、他の方法と同様の結果を得ることができます。正規表現のアプローチの欠点は、さまざまな場所に一致させたい場合には扱いにくくなることです。さらに、 正規表現の優先順位が低い は、場所を一致させる方法には適さないかもしれません。場合によっては、正規表現によるパフォーマンスへの影響があるようです。
ファイルをインクルードすることの主な利点は(私が言うことができる限り)、インクルードできるものについては、もう少し柔軟性があることです。たとえば、フルロケーションブロックである必要はありません。しかし、それはまた、主観的には名前付きロケーションよりも少しぎこちないものです。
また、同様の状況で使用できる可能性がある関連ソリューションがあることにも注意してください。考え方は、非常に一般的な場所から開始し、いくつかの一致候補に共通の設定を適用して、一致させるパスの種類ごとにネストされた場所を個別に設定するというものです。たとえば、次のようにすると便利です。
location /specialpages/ {
# some config
location /specialpages/static/ {
try_files $uri $uri/ =404;
}
location /specialpages/dynamic/ {
proxy_pass http://127.0.0.1;
}
}
これは、短くても効率的で実証済みのアプローチです。
location ~ (patternOne|patternTwo){ #rules etc. }
そのため、同じロケーションブロック/ルールを指す単純なパイプ構文で複数のパターンを簡単に持つことができます。