funciona - restart nginx

¿Cómo puedo tener la misma regla para dos ubicaciones en la configuración de NGINX?

Question

¿Cómo puedo tener la misma regla para dos ubicaciones en la configuración de NGINX?

He probado lo siguiente

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

pero nginx reload arrojó este error:

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

Answer 1

Este es un enfoque breve, pero eficiente y probado:

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

Por lo tanto, uno puede tener fácilmente múltiples patrones con una sintaxis de tubería simple que apunta al mismo bloque de ubicación / reglas.

Answer 2

Otra opción es repetir las reglas en dos ubicaciones de prefijos utilizando un archivo incluido. Dado que las ubicaciones de los prefijos son independientes de la posición en la configuración, usarlas puede ahorrar cierta confusión al agregar otras ubicaciones de expresiones regulares más adelante. Evitar las ubicaciones de expresiones regulares cuando pueda ayudará a que su configuración se escale sin problemas.

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

Aquí hay una muestra 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
";

Answer 3

Tanto la expresión regular como los archivos incluidos son buenos métodos, y los uso con frecuencia. Pero otra alternativa es utilizar una "ubicación con nombre", que es un enfoque útil en muchas situaciones, especialmente en las más complicadas. La página oficial "If is Evil" muestra esencialmente lo siguiente como una buena manera de hacer las cosas:

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

Hay ventajas y desventajas de estos diversos enfoques. Una gran ventaja de una expresión regular es que puedes capturar partes de la partida y usarlas para modificar la respuesta. Por supuesto, generalmente puede lograr resultados similares con los otros enfoques ya sea configurando una variable en el bloque original o utilizando el map . La desventaja del enfoque de expresiones regulares es que puede volverse difícil de manejar si desea hacer coincidir una variedad de ubicaciones, además de la baja precedencia de una expresión regular podría no coincidir con la forma en que desea hacer coincidir las ubicaciones, sin mencionar que aparentemente hay impactos en el rendimiento de expresiones regulares en algunos casos.

La principal ventaja de incluir archivos (por lo que puedo decir) es que es un poco más flexible sobre exactamente lo que puede incluir: no tiene que ser un bloque de ubicación completo, por ejemplo. Pero también es subjetivamente un poco más complicado que las ubicaciones con nombre.

También tenga en cuenta que existe una solución relacionada que puede usar en situaciones similares: ubicaciones anidadas. La idea es que comience con una ubicación muy general, aplique alguna configuración común a varias de las posibles coincidencias y luego tenga ubicaciones anidadas separadas para los diferentes tipos de rutas que desea hacer coincidir. Por ejemplo, podría ser útil hacer algo como esto:

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

Answer 4

Tratar

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

El ~ significa usar una expresión regular para la url. El ^ significa verificar desde el primer carácter. Esto buscará un / seguido de cualquiera de las ubicaciones y luego otro / .