NGINX構成の2つの場所に同じルールを設定するにはどうすればよいですか?


153

NGINX構成の2つの場所に同じルールを設定するにはどうすればよいですか?

私は以下を試しました

server {
  location /first/location/ | /second/location/ {
  ..
  ..
  }
}

しかし、nginx reloadがこのエラーをスローしました:

nginx: [emerg] invalid number of arguments in "location" directive**

回答:


239

試す

location ~ ^/(first/location|second/location)/ {
  ...
}

~URLの正規表現を使用することを意味します。^最初の文字からチェックするための手段。これ/により、のいずれかが続き、次に別のが続きます/


37
注:これが頻繁に発生する場合(数千のように)、正規表現の一致によりパフォーマンスが低下します。また、マッチングの順序も大幅に異なります。多くの「小さな」ケースでは、それはあなたが望むように振る舞いますが、これは注意し続けるべきものです。個人的には、Nginxの「場所」が正規表現ルールに依存するのではなく、複数の「=」条件をサポートすることを望んでいます。
Bernard

7
私見、これはもっと効率的なはずです:場所〜(patternOne | patternTwo){...}
スタムスター

2
この解決策は私にはうまくいきませんでした。しかし、@ stamsterのコメントはそうしました。私は走っていますnginx/1.13.2
TJビドル2017

1
proxy_pass作業が必要な場合は、この回答を参照してください:stackoverflow.com/a/46625656/1246870
avs099

1
元のURLがスラッシュで終わっていない場合、これは機能しません
ゴッドファーザー

88

別のオプションは、インクルードファイルを使用して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
";

shared.conf例と場所を追加してください。
ДмитрийКулешов

5
shared.confファイルの例を追加しました。shared.confへの絶対パスを使用するか、nginxディレクトリに置くことができます。この場合は、いくつかのディレクティブが含まれています。
Cole Tierney

40

正規表現とインクルードされたファイルはどちらも良い方法であり、私はそれらを頻繁に使用しています。しかし、もう1つの方法は、「名前付きの場所」を使用することです。これは、多くの状況で、特により複雑な状況で便利なアプローチです。公式ページの「IFが悪である」ショーは、本質的に物事を行うための良い方法として、以下:

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;
    }
}

7

これは短くて効率的で実績のあるアプローチです。

location ~ (patternOne|patternTwo){ #rules etc. }

したがって、同じロケーションブロック/ルールを指す単純なパイプ構文を使用して、複数のパターンを簡単に作成できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.