1. Mecánica de coincidencia para las directivas location

La directiva location en Nginx define patrones para coincidir con las URI de las solicitudes. Los modificadores determinan el tipo de coincidencia:

• ~: Coincidencia con expresión regular, sensible a mayúsculas/minúsculas.
• ~*: Coincidencia con expresión regular, no sensible a mayúsculas/minúsculas.
• ^~: Coincidencia de prefijo. Si se encuentra una coincidencia con este modificador, Nginx no buscará coincidencias de expresiones regulares.
• =: Coincidencia exacta y precisa de la cadena.
• @: Define una ubicación con nombre para su uso interno (por ejemplo, con try_files).

Prioridad de coincidencia: La prioridad no depende del orden en el archivo de configuración. Se evalúa en este orden:

1. Las coincidencias exactas (=) se procesan primero.
2. Se evalúan todos los prefijos. Se selecciona el prefijo más largo coincidente. Si este prefijo tiene el modificador ^~, se detiene la búsqueda.
3. Finalmente, se comprueban las coincidencias por expresiones regulares (~ y ~*) en el orden en que aparecen.

Ejemplo de configuración

location = /home {
    # Coincidencia 1: Acceso exacto a /home
}
location = /acceso {
    # Coincidencia 2: Acceso exacto a /acceso
}
location ^~ /recursos/ {
    # Coincidencia 3: Cualquier URI que comience con /recursos/
}
location ~ \.(webp|avif)$ {
    # Coincidencia 4: Archivos con extensión .webp o .avif
}
location ~* \.(jpg|jpeg)$ {
    # Coincidencia 5: Archivos .jpg o .jpeg (no sensible a mayúsculas)
}
location / {
    # Coincidencia 6: Ubicación predeterminada
}

Resultados de la coincidencia:

• /home → Coincidencia 1.
• /acceso → Coincidencia 2. /registro → Coincidencia 6.
• /recursos/estilos/main.css → Coincidencia 3.
• /imagen.webp → Coincidencia 4. /imagen.WEBP → Coincidencia 4. /foto.jpg → Coincidencia 5.
• /cualquier/ruta → Coincidencia 6.

2. Contexto del bloque server

El bloque server define un servidor virtual. Escucha en un puerto/IP específico y procesa solicitudes que coinciden con su server_name. Es el contenedor principal para las directivas de manejo de peticiones.

server {
    listen 80;
    server_name ejemplo.com www.ejemplo.com;
    # Directivas de ubicación y proxy van aquí
}

3. Diferencia entre alias y root

Ambas directivas asignan rutas del sistema de archivos, pero lo hacen de manera distinta.

root: Establece la raíz para una ubicación. La URI solicitada se anexa a la ruta de root.

location /documentos/ {
    root /srv/www/publico;
}
# Solicitud: GET /documentos/informe.pdf
# Ruta de archivo resultante: /srv/www/publico/documentos/informe.pdf

alias: Reemplaza la porción coincidente de la URI con la ruta del sistema de archivos.

location /docs/ {
    alias /srv/www/archivos/publicos/;
}
# Solicitud: GET /docs/2024/resumen.txt
# Ruta de archivo resultante: /srv/www/archivos/publicos/2024/resumen.txt

Casos de uso:

• Usa root cuando la estructura de directorios del servidor se alinea con la estructura de la URI.
• Usa alias cuando necesitas mapear una URI a una ruta de sistema de archivos completamente diferente o con un nombre distinto.

4. Configuración de keepalive en upstream

La directiva keepalive dentro de un bloque upstream establece el número máximo de conexiones de larga duración (keepalive) que se mantenrdán por worker a los servidores de respalod (backends). Esto mejora el rendimiento al reutilizar conexiones TCP.

upstream backend_cluster {
    server 10.0.1.101:8080;
    server 10.0.1.102:8080;
    keepalive 32; # Mantener hasta 32 conexiones inactivas por worker
}

En el bloque location o server que usa proxy_pass hacia este upstream, es necesario establecer los encabezados de conexión HTTP adecuados para aprovechar keepalive:

location /api/ {
    proxy_pass http://backend_cluster;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}