Skip to content

Probador de nginx location — por qué gana ese bloque

Qué bloque location de nginx gana — y por qué perdieron los demás. Probador gratuito para =, ^~, ~ y ~*, todo en tu navegador.

Sin rastreo Se ejecuta en el navegador Gratis
Tu configuración se analiza localmente en el navegador y nunca se sube. Las configuraciones de servidor llevan nombres de host de upstream y bloques de autenticación: abre el panel Red y míralo permanecer en silencio — o desconéctate del todo.
Prueba una configuración errónea real
Location seleccionado
~* \.(gif|jpg|jpeg)$

Primera regex, en el orden de la configuración, que coincidió. La longitud es irrelevante.

Contra qué compara nginx realmente
Destino de la petición
/documents/1.jpg
$uri normalizada
/documents/1.jpg
Query string $args
—

La coincidencia se ejecuta solo contra la ruta normalizada. La query string se separa antes y nunca participa.

Por qué ganó ese bloque
Por qué ganó ese bloque
Línea location Etapa Resultado Motivo
2 = / Exacta Sin coincidencia Un location = exige que la URI entera sea igual, no que empiece por él.
3 / Prefijo Coincide pero es más corto Coincide, pero otro prefijo cubrió más caracteres.
4 /documents/ Prefijo Coincide pero es más corto Coincide, pero otro prefijo cubrió más caracteres.
5 ^~ /images/ Prefijo Sin coincidencia La URI no empieza por este prefijo.
6 ~* \.(gif|jpg|jpeg)$ Regex Seleccionado Primera regex, en el orden de la configuración, que coincidió. La longitud es irrelevante.

Modificadores de location en nginx: =, ^~, ~ y ~* comparados

Modificadores de location en nginx: =, ^~, ~ y ~* comparados
Modificador Sintaxis Coincide por Orden Detiene las regex Uso típico
= location = /path Igualdad 1 Sí Rutas muy transitadas como / — la coincidencia más rápida posible.
^~ location ^~ /path Empieza por 2 Sí Directorios que nunca deben acabar en una regex, como los de subidas.
~ location ~ regex Regex PCRE 3 No Enrutamiento por extensión cuando importan las mayúsculas.
~* location ~* regex Regex PCRE 3 No Enrutamiento por extensión cuando no importan las mayúsculas.
(ninguno) location /path Empieza por 4 No Enrutamiento general por ruta.
@ location @name Solo interno — No Fallbacks de error_page y try_files.

La columna de orden no es una clasificación simple. Un location de prefijo solo detiene la evaluación de las regex cuando lleva ^~ y es él mismo la coincidencia más larga — que es exactamente por lo que un bloque ^~ a veces parece no hacer nada.

Prioridad de location en nginx: el orden de resolución

Prioridad de location en nginx: el orden de resolución
# Etapa Termina la búsqueda Qué ocurre
1 Normalizar No Decodificación de porcentajes, resolución de . y .., barras repetidas colapsadas. La query string se separa aquí y nunca participa en la coincidencia.
2 Exacta Sí location = /path, comparado por igualdad. Un acierto termina la búsqueda de inmediato.
3 Redirección automática Sí Un location de proxy cuyo nombre es la URI más una barra. nginx responde 301 y nunca llega a las regex.
4 Prefijo No Cada prefijo que coincide se compara y se memoriza el más largo. El orden en la configuración se ignora.
5 Anidada No Se desciende dentro del prefijo ganador. Una regex anidada se prueba antes que el nivel padre.
6 Regex Sí Las regex se prueban en el orden de la configuración y gana la primera coincidencia. Una regex más larga o más específica escrita después nunca se ejecuta.
7 Fallback Sí Ninguna regex coincidió, así que se usa el prefijo memorizado antes.
El orden de coincidencia, el cortocircuito del ^~, el descenso a los location anidados, el comportamiento de la redirección automática y la normalización de la URI se contrastaron con el propio código fuente de nginx y se confirmaron ejecutando las configuraciones en nginx 1.27.5. — Equipo de Ingeniería de Go Tools · Jul 22, 2026

Las reglas de selección de esta página se verificaron contra un nginx 1.27.5 en ejecución en lugar de tomarlas de artículos de segunda mano, y el motor está cubierto por pruebas unitarias derivadas de esas ejecuciones.

Coincidencia de location en nginx: respuestas rápidas

¿nginx procesa los location de regex antes que las coincidencias de prefijo?

No — los prefijos se comprueban primero, pero una regex que coincida gana igualmente. nginx comprueba primero todos los location de prefijo y memoriza la coincidencia más larga, y luego evalúa los location de regex en el orden en que aparecen en el archivo. Gana la primera regex que coincida. Si ninguna regex coincide, se usa el location de prefijo memorizado. La única excepción es ^~: cuando el prefijo coincidente más largo lo lleva, la fase de regex se omite por completo.

¿Importa el orden de los bloques location en nginx?

Solo para los location de regex. Los location de prefijo — incluidos = y ^~ — se seleccionan por coincidencia más larga, así que su orden en el archivo es irrelevante. Los location de regex se prueban de arriba abajo y gana la primera coincidencia, así que mover un bloque de regex cambia cuál se ejecuta. Una regex más específica colocada debajo de una más amplia nunca se ejecuta.

¿Qué hace realmente el modificador ^~?

Detiene a nginx tras la coincidencia de prefijo en lugar de subir la prioridad. Si el location de prefijo coincidente más largo lleva ^~, nginx omite la fase de regex y usa ese bloque. No hace el prefijo más largo ni lo coloca por encima de otros prefijos — solo suprime la evaluación de las expresiones regulares. Por eso un bloque ^~ parece no hacer nada cuando también coincide un prefijo simple más largo: es el más largo el que queda memorizado, y ese no suprime nada.

¿location /static es lo mismo que location /static/?

No — /static también coincide con /staticfoo. La coincidencia por prefijo es una simple comparación de cadenas, no un límite de segmento de ruta, así que location /static también sirve /staticfiles y /static-backup. Aparte de eso, cuando /static/ se usa con proxy_pass, una petición a /static sin la barra final recibe una redirección 301 a /static/ antes de que se considere ninguna regex.

¿nginx decodifica %2F y colapsa las barras dobles antes de la coincidencia?

Sí — la coincidencia se ejecuta contra la URI normalizada, no contra la petición en bruto. nginx decodifica %XX, resuelve . y .. y comprime las barras repetidas antes de seleccionar un location. Un %2F decodificado se convierte en un separador de verdad y participa en esa resolución, así que /a/b%2F..%2Fzz se compara como /a/zz. La query string se separa antes que nada y nunca participa en la coincidencia.

¿Qué es un bloque location de nginx?

Un bloque location le dice a nginx qué hacer con una petición cuya URI coincide con un patrón. Un bloque server suele contener varios, y lo interesante no es qué hace cada uno sino cuál elige nginx — porque las reglas de selección no son las que casi todo el mundo supone.

Hay cinco formas. location = /path coincide solo cuando la URI entera es igual. location /path coincide con cualquier URI que empiece por esos caracteres. location ^~ /path es la misma comparación de prefijo con un efecto extra. location ~ regex y location ~* regex aplican un patrón PCRE, distinguiendo y sin distinguir mayúsculas. location @name no participa en absoluto en la coincidencia de URI y existe solo como destino de try_files y error_page.

La selección va por etapas. Primero se normaliza la URI: porcentajes decodificados, . y .. resueltos, barras repetidas colapsadas, query string separada. Después, un location = igual a la URI termina la búsqueda de inmediato. Luego se comparan todos los prefijos que coinciden y se memoriza el más largo — aquí el orden en la configuración no juega ningún papel. Si ese prefijo memorizado lleva ^~, nginx se detiene y lo usa. Si no, los location de regex se prueban en el orden en que aparecen en el archivo, y gana la primera coincidencia, por específica que sea una posterior. Si ninguna coincide, se usa el prefijo memorizado.

Dos de esas reglas tiran en direcciones opuestas, y ahí es donde vive la confusión: los prefijos se eligen por longitud sin importar el orden, las regex por orden sin importar la longitud. Una configuración que se lee correctamente de arriba abajo aún puede enrutar una petición a donde no querías, y ninguna relectura lo revela. Esta página reproduce la secuencia entera contra tu propia configuración y muestra dónde se cayó cada bloque.

# From the nginx documentation. Which block serves each request?
server {
    location = /                   { }   # A
    location /                     { }   # B
    location /documents/           { }   # C
    location ^~ /images/           { }   # D
    location ~* \.(gif|jpg|jpeg)$  { }   # E
}

#   /                        -> A   exact match, search ends here
#   /index.html              -> B   no regex matched, longest prefix used
#   /documents/document.html -> C   longer prefix than B
#   /images/1.gif            -> D   ^~ won the prefix stage, regex skipped
#   /documents/1.jpg         -> E   regex beats the longer prefix C

# The last two lines are the whole lesson: identical-looking prefixes
# behave differently because only one of them carries ^~.

Características clave

Cada bloque perdedor, con la etapa en la que quedó eliminado

Cada location que escribiste obtiene una fila: coincidió pero es más corto, omitido porque ganó un prefijo ^~, inalcanzable porque una regex anterior coincidió, o simplemente ninguna coincidencia. Saber por qué perdieron los demás suele ser lo que de verdad resuelve la duda.

La cadena de decisión de cuatro etapas, reproducida

Normalización, coincidencia exacta, memoria del prefijo más largo, el cortocircuito del ^~, las regex en el orden del archivo y el fallback aparecen como pasos separados sobre tu propia configuración, en vez de descritos en abstracto.

El cortocircuito del ^~ hecho visible

Cuando un prefijo ^~ suprime la fase de regex, cada regex omitida se etiqueta como omitida en lugar de desaparecer sin más — y cuando el ^~ no llega a aplicarse porque ganó un prefijo simple más largo, eso también se muestra.

Location anidados resueltos, no aplanados

nginx desciende dentro del prefijo ganador y busca entre sus hijos, así que una regex anidada se ejecuta antes que las del nivel padre. Los bloques anidados conservan su indentación en la tabla para que la estructura siga siendo legible.

Sintaxis exclusiva de PCRE detectada de entrada

Los navegadores ejecutan regex de ECMAScript, no PCRE. Grupos atómicos, cuantificadores posesivos, clases POSIX y escapes como \A y \K se marcan en vez de evaluarse mal en silencio, para que nunca se presente como un hecho una respuesta equivocada y segura de sí misma.

No se sube nada — se ejecuta en tu navegador

Las configuraciones de servidor llevan nombres de host de upstream, puertos internos y reglas de autenticación. El análisis es simple trabajo sobre cadenas, sin dependencias y sin llamadas de red, verificado por una prueba de contrato automatizada en cada build.

Otras formas de responder a esta pregunta

nginx -T

Línea de comandos

Vuelca la configuración completamente resuelta, lo que es valiosísimo para saber qué hay cargado de verdad. No te dirá qué location selecciona una URI dada — ese es el hueco que llena esta página.

error_log ... debug

Servidor en marcha

La respuesta más autorizada que existe: la línea «using configuration» nombra el bloque que nginx eligió realmente. Requiere root, un reload y un servidor al que puedas llegar — así que responde después del despliegue, no antes.

Verificadores de sintaxis de configuración

Servicio alojado

Fuertes en el lint del archivo completo y en reglas de seguridad. Suelen ejecutarse en el servidor, lo que significa subir una configuración que contiene nombres de host internos y rutas de certificados.

Leer la documentación

Referencia

La documentación de nginx enuncia el algoritmo con precisión y vale la pena leerla una vez. Aplicarlo a mano a ocho bloques y una URI es donde se cuelan los errores, porque dos de las reglas apuntan en direcciones opuestas.

Ejemplos de coincidencia de location en nginx

Una expresión regular vence a un prefijo más largo

location /documents/  ·  location ~* \.(gif|jpg|jpeg)$  ·  GET /documents/1.jpg
~* \.(gif|jpg|jpeg)$ wins

El prefijo /documents/ coincide y es el prefijo más largo del archivo, así que nginx lo memoriza — y aun así evalúa las expresiones regulares y entrega la petición a la primera que coincida. La longitud pierde frente a la fase de regex. Si ese prefijo se hubiera escrito ^~ /documents/, ninguna regex se habría ejecutado. Este es el ejemplo de la documentación de nginx, y es el más útil de interiorizar.

El directorio de subidas que ejecuta PHP

location /uploads/  ·  location ~ \.php$ { fastcgi_pass ... }  ·  GET /uploads/evil.php
~ \.php$ wins — the upload lands in the interpreter

El prefijo /uploads/ coincide, pero un prefijo simple no detiene la fase de regex, así que un archivo que subió cualquiera va directo a PHP-FPM. Escribir location ^~ /uploads/ cortocircuita la fase de regex y cierra la puerta. No es un caso hipotético: es la forma que hay detrás de una larga lista de informes de subida-a-RCE, y entre vulnerable y seguro hay dos caracteres.

Un ^~ que en silencio no hace nada

location ^~ /a/  ·  location /a/b/  ·  location ~ \.php$  ·  GET /a/b/x.php
~ \.php$ wins — the ^~ never applied

^~ solo suprime la fase de regex cuando él mismo es el prefijo coincidente más largo. Aquí /a/b/ es más largo, así que es el que nginx memoriza, y su modificador simple deja que la fase de regex se ejecute. El bloque ^~ sigue en el archivo, sigue pareciendo protector y no tiene ningún efecto sobre esta petición. Leer una configuración de arriba abajo no lo revela; comparar longitudes de prefijo sí.

/static también captura /staticfoo

location /static  ·  location /static/  ·  GET /staticfoo
/static wins

La coincidencia por prefijo compara caracteres, no segmentos de ruta. /staticfoo empieza por /static, así que coincide, y /static/ no coincide en absoluto porque la URI no tiene barra en esa posición. Todo lo accesible bajo una ruta que simplemente empieza con las mismas letras lo sirve ese bloque — así es como una regla /static acaba sirviendo /static-backup.

Gana la primera expresión regular, no la mejor

location ~ ^/a  ·  location ~ ^/a/b/c$  ·  GET /a/b/c
~ ^/a wins; ~ ^/a/b/c$ is unreachable

Las expresiones regulares se evalúan en el orden en que aparecen en el archivo y la primera coincidencia termina la búsqueda. El segundo bloque es más específico y coincide exactamente con esta URI, y nunca se ejecutará — para ninguna petición. Los location de prefijo se eligen por longitud sin importar el orden; los location de regex se eligen por orden sin importar la especificidad. Confundir esas dos reglas es el motivo habitual de que una regla «deje de funcionar» después de que alguien ordenara el archivo.

El traversal codificado se resuelve antes de la coincidencia

location /a/  ·  location /b/  ·  GET /a/b%2F..%2Fzz
$uri becomes /a/zz, so /a/ wins

nginx decodifica los porcentajes, resuelve . y .. y colapsa las barras repetidas antes de consultar cualquier location. %2F se decodifica como un separador de verdad y entonces participa en esa resolución, de modo que este destino no se queda dentro de /a/b/ — cae en /a/zz. Comparar contra el destino que escribiste en lugar del $uri normalizado da aquí la respuesta equivocada.

Cómo usar el probador de location de nginx

  1. 1

    Pega el bloque server

    Suelta ahí un bloque server entero, o solo los bloques location sobre los que estás razonando. Los location anidados se entienden, y los números de línea originales se conservan para que la tabla encaje con tu archivo.

  2. 2

    Introduce la URI de la petición

    Escribe la ruta tal como llega por el cable, incluida cualquier codificación por porcentaje y la query string. Las tres filas de encima de la tabla muestran cómo se normaliza antes de la coincidencia.

  3. 3

    Lee al ganador y luego a los perdedores

    La tarjeta de veredicto nombra el bloque seleccionado y el motivo en una línea. La tabla de decisión de abajo explica cada uno de los demás bloques: en qué etapa quedó eliminado y por qué.

  4. 4

    Revisa los diagnósticos

    Regex sin anclar, prefijos sin barra final, un ^~ que lleva un patrón de regex, duplicados inalcanzables y directorios de subidas alcanzables por una regex de PHP se informan todos.

  5. 5

    Comparte el estado exacto

    Copiar enlace codifica la configuración y la URI en el fragmento de la URL, para que un compañero abra exactamente lo que estás mirando. Los fragmentos nunca se transmiten a un servidor.

Errores comunes con location en nginx

Esperar que ^~ se imponga a un prefijo más largo

^~ solo se consulta en el prefijo que ya ganó por longitud. Un prefijo simple más largo gana primero, y la fase de regex se ejecuta después como si el ^~ no estuviera.

✗ Incorrecto 
location ^~ /a/ { }
location /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ~ \.php$
✓ Correcto 
location ^~ /a/ { }
location ^~ /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ^~ /a/b/

Un prefijo sin barra final que atrapa a los hermanos

La coincidencia por prefijo compara caracteres en vez de segmentos de ruta, así que el bloque sirve también toda ruta hermana que empiece con las mismas letras.

✗ Incorrecto 
location /static { root /var/www; }
# also serves /staticfoo and /static-backup
✓ Correcto 
location /static/ { root /var/www; }
location = /static { return 301 /static/; }

Poner la regex específica debajo de la amplia

Las regex se prueban en el orden del archivo y la primera coincidencia termina la búsqueda, así que el bloque más preciso no se ejecuta nunca, para ninguna petición.

✗ Incorrecto 
location ~ ^/api { }
location ~ ^/api/v2/users$ { }
# the second is unreachable
✓ Correcto 
location ~ ^/api/v2/users$ { }
location ~ ^/api { }

Escribir una regex después de ^~

^~ toma un prefijo literal. nginx carga el archivo sin quejarse y el bloque sencillamente no coincide nunca con nada, lo que lo hace difícil de detectar en revisión.

✗ Incorrecto 
location ^~ "\.php$" { deny all; }
✓ Correcto 
location ~ \.php$ { deny all; }

Suponer que la query string participa en la coincidencia

La query string se separa durante la normalización, así que un location nunca puede coincidir por ella. Lee $arg_name dentro del bloque.

✗ Incorrecto 
location /search?q= { }
# never matches anything
✓ Correcto 
location /search {
    if ($arg_q = "") { return 400; }
}

Qué puedes hacer con el probador de location de nginx

Comprobar una configuración antes de que llegue a producción
Razona sobre el enrutamiento de un bloque server que has editado pero no desplegado. El fallo que esto atrapa es el que solo aparece con una forma concreta de URI, justo el tipo que un smoke test tras el reload suele dejar pasar.
Averiguar por qué una regla dejó de funcionar
Una regex que antes se ejecutaba y ahora no casi siempre es víctima del orden: algo coincidió antes, o apareció un ^~ por encima. La tabla marca el bloque como inalcanzable y nombra el bloque que se llevó la petición.
Auditar un directorio de subidas o de medios
Carga el preajuste que reproduce el patrón de subida-con-ejecución y luego pega tus propias rutas. Si una regex de PHP está tomando peticiones dentro de un directorio con escritura, el diagnóstico lo dice y nombra los dos bloques.
Zanjar un comentario de revisión con pruebas
Copiar enlace captura la configuración y la URI exactas en el fragmento de la URL. Dejarlo en una pull request sustituye una discusión sobre precedencia por una tabla de decisión que cualquiera puede reejecutar.
Enseñar el algoritmo de selección
Las dos tablas de referencia son material estático e indexable al que puedes apuntar, y los chips de preajuste demuestran cada trampa sin necesidad de romper un servidor. El ejemplo del ^~ en particular suele cerrar el debate rápido.

Cómo funciona la selección de location en nginx

La normalización ocurre antes de consultar ningún location
La URI se decodifica de los porcentajes, los segmentos . y .. se resuelven y las barras repetidas se colapsan, y solo entonces se elige un location. Un %2F decodificado se convierte en un separador de verdad y participa en esa resolución, así que /a/b%2F..%2Fzz se compara como /a/zz. Tres caracteres decodificados son la excepción y se quedan literales: %25, %23 y %3F — por eso /a%3Fx=1 tiene un signo de interrogación en su ruta y la query string vacía. Aquí un + no es un espacio; solo %20 lo es. El traversal por encima de la raíz y un escape inválido se rechazan ambos con 400 antes de que empiece la coincidencia.
Decide la longitud del prefijo, no el orden en la configuración
Cada location de prefijo que coincide se compara y gana el más largo, aparezca primero o último en el archivo. La comparación es por caracteres, no por segmentos de ruta, así que /static coincide con /staticfoo. El ganador se memoriza en vez de usarse al momento, porque la fase de regex todavía puede pasarle por encima.
^~ suprime las regex; no sube la prioridad
El modificador solo se consulta en el prefijo que ya ganó por longitud. Si también coincide un prefijo simple más largo, es ese el que queda memorizado y la fase de regex se ejecuta como siempre — el bloque ^~ no tiene ningún efecto sobre la petición. Poner ^~ en un location anidado no protege frente a una regex declarada en el nivel exterior, y nunca suprime las regex anidadas dentro de su propio bloque.
Las regex se ejecutan en el orden del archivo y la primera coincidencia termina la búsqueda
nginx mantiene los location de regex en el orden en que se escribieron y no los ordena. La especificidad, la longitud y el anclaje no influyen en cuál se prueba primero, así que un patrón preciso colocado debajo de uno amplio es configuración muerta. En un location de regex que coincidió también se desciende, así que sus location anidados se recorren a continuación.
PCRE y ECMAScript no son el mismo lenguaje
nginx compila las regex de location con PCRE, sin modo UTF ni multilínea, así que los patrones operan sobre bytes y ^ ancla solo al principio de la URI. Una diferencia tiene peso de seguridad: el $ de PCRE también coincide justo antes de un salto de línea final, así que una URI que termina en %0A sigue satisfaciendo \.php$ aunque un motor de JavaScript lo rechazaría. Ese comportamiento se emula aquí y se informa, porque es una forma conocida de colarse por reglas basadas en la extensión del archivo.

Buenas prácticas de location en nginx

Protege los directorios con escritura usando ^~, no un prefijo simple
Todo directorio que acepte subidas necesita location ^~ /uploads/ para que la fase de regex no pueda entregar un archivo guardado a un intérprete. Un prefijo simple parece equivalente y no lo es.
Dale barra final a los prefijos de directorio
Escribe location /static/ en lugar de location /static, salvo que quieras deliberadamente que /staticfoo y /static-backup los sirva el mismo bloque. Añade un location = /static aparte cuando la ruta desnuda también haya que atenderla.
Ordena las regex de la más específica a la menos específica
Gana la primera coincidencia, así que un patrón amplio por encima de uno preciso vuelve inalcanzable al preciso. Tener pocas regex y ordenarlas a propósito se mantiene mejor que razonar a posteriori sobre solapamientos.
Ancla las regex que deben coincidir con un prefijo de ruta
location ~ /admin busca en cualquier punto de la URI y coincide con /public/admin/x. Escribe ~ ^/admin cuando te refieras al principio. Anclar solo al final es normal y correcto para el enrutamiento por extensión.
Revisa el enrutamiento después de cualquier reordenación
Mover bloques es seguro para los prefijos y cambia el comportamiento de las regex. Como un diff que solo reordena líneas parece inofensivo en revisión, reejecutar las URI afectadas es la forma más barata de detectarlo.

Preguntas frecuentes sobre el probador de location de nginx

¿Cómo averiguo qué location seleccionó nginx?
Pega la configuración y la URI de la petición en este probador para ver el bloque ganador y por qué se eliminó cada uno de los demás. En un servidor en marcha, añade error_log /var/log/nginx/debug.log debug; y busca la línea «using configuration», que nombra el location seleccionado. Los dos enfoques responden preguntas distintas: el log cuenta lo que hizo un servidor vivo, y esta página cuenta lo que haría una configuración que aún no has desplegado.
¿Por qué no funciona mi expresión regular de location en nginx?
Normalmente por uno de tres motivos, y la tabla de decisión dice cuál. Una regex anterior ya coincidió, así que la tuya nunca se ejecutó — las regex se prueban en el orden del archivo y gana la primera coincidencia. O el prefijo coincidente más largo lleva ^~, que omite la fase de regex por completo. O la regex está bien pero la URI no es la que crees: la coincidencia se ejecuta contra la ruta normalizada, después de decodificar los porcentajes y resolver los .., y con la query string eliminada.
¿Por qué no se dispara mi coincidencia exacta?
Un location = exige que la URI entera sea igual, no que empiece por el patrón. location = /a/ no coincide con /a, y location = /a no coincide con /a/b. Aquí las barras finales son caracteres corrientes, así que las dos formas son cadenas distintas. Cuando un location exacto coincide, la búsqueda se detiene de inmediato y nada más llega siquiera a compararse.
¿nginx compara la query string en un bloque location?
No. La query string se separa durante la normalización y la selección de location se ejecuta solo contra la ruta. Por eso location = /a coincide con una petición a /a?x=/b. Si necesitas ramificar por un parámetro tienes que leer $arg_name o $args dentro del bloque. Una sutileza que conviene conocer: %3F se decodifica como un signo de interrogación literal que permanece en la ruta, así que /a%3Fx=1 tiene la query string vacía y una ruta que contiene ?.
¿Puedo usar la sintaxis de regex de JavaScript en un location de nginx?
No — nginx usa PCRE, y las diferencias importan. Esta página se ejecuta en tu navegador, donde solo existen las expresiones regulares de ECMAScript, así que las construcciones exclusivas de PCRE se detectan y se marcan en lugar de evaluarse mal en silencio: grupos atómicos, cuantificadores posesivos, modificadores en línea como (?i), clases POSIX como [[:alpha:]] y escapes como \A y \K que JavaScript lee tranquilamente como letras corrientes. Cuando un location queda marcado, los candidatos restantes se siguen evaluando en el orden de nginx, pero el veredicto de ese bloque hay que comprobarlo en un servidor real. Si estás escribiendo el patrón en sí, el probador de expresiones regulares cubre a fondo la sintaxis de ECMAScript.
¿Las coincidencias de prefijo de location en nginx distinguen mayúsculas y minúsculas?
En Linux, sí — location /Static/ no coincide con /static/x. En sistemas de archivos que no distinguen mayúsculas, como macOS y Cygwin, nginx compara los prefijos sin distinguirlas y además fuerza a que todo location de regex se comporte como ~*. Esta página modela el comportamiento de Linux, que es lo que los servidores de producción ejecutan casi siempre. Si desarrollas en Mac y despliegas en Linux, esa diferencia puede ocultar una regla rota hasta que llega a producción.
¿try_files cambia qué bloque location se seleccionó?
No. La selección de location termina primero; try_files se ejecuta después, dentro del bloque que ya ganó. Si una petición nunca llega al bloque que contiene tu try_files, la directiva es irrelevante — la causa habitual es una regex ~ \.php$ que se lleva la petición antes de que el bloque de prefijo con el fallback pueda actuar. Una redirección interna emitida más tarde sí reinicia la coincidencia, así que una URI reescrita se resuelve otra vez contra la lista de location desde el principio.
¿Por qué nginx devuelve 301 cuando pido un directorio sin barra?
Lo producen dos mecanismos distintos. Si un location cuyo nombre termina en / lleva proxy_pass u otra directiva *_pass, una petición a la misma ruta sin la barra se responde con un 301 durante la selección de location — antes de evaluar ninguna regex. Aparte de eso, el módulo de archivos estáticos emite un 301 cuando la ruta se resuelve en un directorio real en disco. El primero se ve aquí; el segundo depende de tu sistema de archivos. Añadir location = /path suprime el primero.
¿Los bloques location anidados cambian el resultado?
Sí, y de una manera fácil de pasar por alto. nginx desciende dentro del location de prefijo ganador y busca entre sus hijos, así que una regex anidada se prueba antes que las regex del nivel padre. Un ^~ en el bloque exterior no lo protege de sus propias regex anidadas, y el anidamiento puede volver inalcanzable un prefijo globalmente más largo cuando un hermano del nivel exterior gana primero. Aquí los bloques anidados se modelan con la misma indentación con la que los escribiste.
¿Se sube mi configuración de nginx a alguna parte?
No. El análisis y la coincidencia ocurren localmente en tu navegador con simples operaciones sobre cadenas — no hay ninguna llamada a servidor y no se conserva nada. Aquí importa más que en la mayoría de las herramientas, porque un bloque server real contiene nombres de host de upstream, puertos internos, rutas de certificados y reglas de autenticación. No tienes que creernos: abre las herramientas de desarrollo del navegador y observa cómo el panel Red se mantiene en silencio mientras escribes, o desconéctate del todo y sigue probando. La ausencia de cualquier petición externa también la impone una prueba de contrato automatizada en cada build, así que no puede degradarse sin que nadie se entere.

Herramientas relacionadas

Ver todas las herramientas →

Generador y constructor de comandos cURL

Web & API

Construye comandos curl en tu navegador: define método, cabeceras, autenticación y cuerpo, y obtén el comando listo para copiar al instante. Presets para Bearer, POST JSON y subida de archivos. Gratis, privado, sin registro.

Generador htpasswd — bcrypt, Apache MD5 (apr1) y Basic Auth

Web & API

Genera entradas htpasswd con bcrypt, Apache MD5 (apr1), SHA-1 y más. Obtén configuración lista para pegar en Apache, nginx y Docker. 100% en tu navegador — sin subidas.

Generador de etiquetas meta y Open Graph

Web & API

Genera etiquetas meta Open Graph, Twitter Card y SEO con vista previa en vivo de Google, Facebook y X. 100% gratis, en el navegador, sin registro — copia y pega el código.

Decodificador traceparent — W3C Trace Context

Web & API

Deja de contar dígitos hex. Decodificador traceparent gratis y online — todo en tu navegador, sin subidas. Trace ID, span ID, 8 bits trace-flags, tracestate, Datadog/X-Ray/B3.

Descifrado AES — Compatible con OpenSSL y CryptoJS

Herramientas de Seguridad

Descifra AES en línea — GCM/CBC/CTR, frase de contraseña o clave sin procesar, detecta automáticamente el formato "U2FsdGVkX1" de OpenSSL y CryptoJS. 100 % en el navegador, las claves nunca salen de la página.

Herramienta de Cifrado AES — GCM, CBC y CTR

Herramientas de Seguridad

Cifrado AES online y gratuito — AES-128/192/256, GCM/CBC/CTR, frase de contraseña (PBKDF2) o clave sin procesar. Se ejecuta 100 % en tu navegador; nada se sube a un servidor.