Как я могу использовать одно правило для двух местоположений в конфигурации NGINX?

Ответ 1

Пытаться

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

~ Означает использование регулярного выражения для URL. ^ Означает проверку по первому символу. Это будет искать / затем одно из мест и затем другое /.

Ответ 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
";

Ответ 3

И регулярное выражение, и включенные файлы - хорошие методы, и я часто использую их. Но другой альтернативой является использование "именованного местоположения", что является полезным подходом во многих ситуациях, особенно в более сложных. Официальная страница "Если есть зло" показывает, как хороший способ сделать что-то:

error_page 418 = @common_location;
location /first/location/ {
    return 418;
}
location /second/location/ {
    return 418;
}
location @common_location {
    # The common configuration...
}

У этих различных подходов есть свои преимущества и недостатки. Одним из больших преимуществ регулярного выражения является то, что вы можете захватывать части матча и использовать их для изменения ответа. Конечно, вы обычно можете достичь аналогичных результатов с другими подходами, либо установив переменную в исходном блоке, либо используя map. Недостатком подхода регулярных выражений является то, что он может стать громоздким, если вы хотите сопоставлять различные местоположения, плюс низкий приоритет регулярного выражения может просто не соответствовать тому, как вы хотите сопоставлять местоположения - не говоря уже о том, что, очевидно, это влияет на производительность от регулярных выражений в некоторых случаях.

Основное преимущество включения файлов (насколько я могу судить) состоит в том, что он немного более гибок в отношении того, что именно вы можете включить - например, он не должен быть полным блоком местоположения. Но это также субъективно немного более громоздко, чем названные локации.

Также обратите внимание, что есть связанное решение, которое вы можете использовать в подобных ситуациях: вложенные местоположения. Идея состоит в том, что вы должны начать с очень общего местоположения, применить некоторую конфигурацию, общую для нескольких возможных совпадений, а затем иметь отдельные вложенные местоположения для различных типов путей, которые вы хотите сопоставить. Например, может быть полезно сделать что-то вроде этого:

location /specialpages/ {
    # some config
    location /specialpages/static/ {
        try_files $uri $uri/ =404;
    }
    location /specialpages/dynamic/ {
        proxy_pass http://127.0.0.1;
    }
}

Ответ 4

Это короткий, но эффективный и проверенный подход:

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

Таким образом, можно легко иметь несколько шаблонов с простым синтаксисом канала, указывающим на один и тот же блок/правила местоположения.

Ответ 5

В случае наследования:

location /first {
    # do some stuff here, and than go to /base
    try_files /base;
}

location /second {
    # do some other stuff here, and than go to /base
    try_files /base;
}

location /base {
    # base stuff here
}