Como posso ter a mesma regra para dois locais na configuração do NGINX?

Como posso ter a mesma regra para dois locais na configuração do NGINX?

Eu tentei o seguinte

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

mas o nginx reload lançou este erro:

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

Experimentar

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

Os ~meios para usar uma expressão regular para o URL. Os ^meios para verificar a partir do primeiro caractere. Isso procurará um /seguido por um dos locais e depois por outro /.

Outra opção é repetir as regras em dois locais de prefixo usando um arquivo incluído. Como os locais de prefixo são independentes da posição na configuração, usá-los pode economizar alguma confusão, à medida que você adiciona outros locais de regex posteriormente. Evitar locais regex, quando possível, ajudará sua configuração a ser dimensionada sem problemas.

server {
    location /first/location/ {
        include shared.conf;
    }
    location /second/location/ {
        include shared.conf;
    }
}

Aqui está uma amostra 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
";

O regex e os arquivos incluídos são bons métodos, e eu os uso com frequência. Mas outra alternativa é usar um "local nomeado", que é uma abordagem útil em muitas situações - especialmente as mais complicadas. A página oficial "If is Evil" mostra essencialmente o seguinte como uma boa maneira de fazer as coisas:

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

Existem vantagens e desvantagens nessas várias abordagens. Uma grande vantagem de uma regex é que você pode capturar partes da correspondência e usá-las para modificar a resposta. Obviamente, você geralmente pode obter resultados semelhantes com as outras abordagens, definindo uma variável no bloco original ou usando map. A desvantagem da abordagem regex é que ela pode ficar pesada se você deseja combinar uma variedade de locais, além da baixa precedência de uma regex simplesmente não se encaixar na maneira como você deseja combinar locais - sem mencionar que aparentemente há impactos no desempenho de regexes em alguns casos.

A principal vantagem de incluir arquivos (até onde eu sei) é que ele é um pouco mais flexível sobre exatamente o que você pode incluir - não precisa ser um bloco de localização completo, por exemplo. Mas também é subjetivamente um pouco mais desajeitado do que locais nomeados.

Observe também que há uma solução relacionada que você pode usar em situações semelhantes: locais aninhados. A idéia é que você comece com um local muito geral, aplique alguma configuração comum a várias das correspondências possíveis e, em seguida, tenha locais aninhados separados para os diferentes tipos de caminhos que deseja corresponder. Por exemplo, pode ser útil fazer algo assim:

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

Essa é uma abordagem curta, porém eficiente e comprovada:

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

Assim, pode-se facilmente ter vários padrões com sintaxe de canal simples apontando para as mesmas regras / bloco de localização.