Introducción

Nginx es uno de los componentes más versátiles y populares del ecosistema de la web moderna. Aunque la mayoría de la gente lo conoce como un servidor web de alto rendimiento, Nginx también brilla como proxy inverso y balanceador de carga. Entender estas tres facetas permite que puedas diseñar arquitecturas más robustas, escalables y eficientes.

Este artículo está pensado para desarrolladores, sysadmins y entusiastas de la infraestructura que buscan un recorrido práctico por las funciones clave de Nginx. A lo largo de las siguientes secciones, vas a aprender:

• Cómo funciona Nginx como servidor web frontal.
• Por qué y cómo se usa como proxy inverso para HTTPS, autenticación y reescritura de URLs.
• Las técnicas de balanceo de carga que distribuyen el tráfico entre múltiples backends.
• Configuraciones reales y ejemplos de esquemas con un diagrama descriptive.
• Mejores prácticas y errores comunes para mantener tus implementaciones estables.

A diferencia de muchos tutoriales genéricos, aquí te presentamos un ejemplo paso a paso que podés ejecutar localmente, junto con un diagrama visual que ilustra cómo Nginx coordina el tráfico entre clientes, proxy e upstream servers.

Para quién es este artículo

• Desarrolladores backend: que necesitan saber cómo configurar un proxy inverso para tus APIs sin comprometer el rendimiento.
• Administradores de sistemas: que quieren simplificar la gestión del tráfico web usando Nginx como balanceador de carga en lugar de HAProxy u otras herramientas.
• Arquitectos de infraestructura: que buscan un solo componente que cubra lo mejor de un servidor web, un proxy inverso y un balanceador de carga.
• Estudiantes o profesionales en capacitación: que buscan un material claro y orientado a la práctica, con código real y una explicación paso a paso.

Qué vas a aprender

1. Fundamentos: El modelo de procesamiento de solicitudes y el ciclo de vida de los trabajadores.
2. Rol como servidor web: Servir archivos estáticos, manejar archivos index, y servir contenido HTTPS con TLS.
3. Rol como proxy inverso: Redirigir solicitudes a servidores backend, agregar/quitar cabeceras, manejo de cookies y autenticación.
4. Rol como balanceador de carga: Aplicación de diferentes algoritmos (round‑robin, weighted, IP‑hash), detección de health checks, stickiness de sesión y separación de HTTP y HTTPS.
5. Diagrama: Un diagrama Mermaid que muestra el flujo de una solicitud típica a través de Nginx y tres servidores upstream.
6. Mejores prácticas: Optimización del número de workers, uso de keep‑alive, resolución de cuellos de botella comunes y consejos de monitoreo.

Con la información aquí presentada, podés diseñar una infraestructura web modular, escalable y con un solo punto de entrada para cualquier cantidad de backends.

Comprender los fundamentos de Nginx

Nginx nació en el año 2004 como servidor web, pero rápidamente se destacó por su arquitectura asíncrona y basada en eventos. En vez de crear un proceso por cada conexión (como Apache con MPM prefork), Nginx mantiene un proceso principal que maneja la configuración y una serie de workers que procesan solicitudes concurrentemente usando un modelo de eventos similar a los servidores web asíncronos.

Cómo funciona la arquitectura

1. Proceso principal: Escucha en los puertos configurados, recarga la configuración (nginx -t && nginx -s reload) y supervisa la salud de los workers.
2. Workers: Escuchan sockets de aceptadores, leen la entrada y la distribuyen a un pool de trabajadores de procesamiento usando una cola. El procesamiento incluye la lectura de archivos, consultas a bases de datos, emisión de respuestas y el envío de datos.
3. Planificador de eventos: Opera en un solo thread por worker, moviéndose a través de las conexiones usando epoll, kqueue o select. Eso da como resultado una sobrecarga muy baja y un alto rendimiento bajo carga.

Dado que cada worker atiende muchas conexiones simultáneamente, Nginx puede manejar decenas de miles de solicitudes por segundo, lo que lo convierte en una excelente opción para sitios web con alto tráfico o aplicaciones API.

Flujo típico de una solicitud

Cuando un cliente (por ejemplo un navegador) realiza una solicitud HTTP a Nginx, lo que sucede internamente es:

1. El aceptador del worker recibe el socket de conexión.
2. El lector obtiene los datos de la solicitud.
3. El escritor prepara la respuesta (puede servir un archivo, redirigir a un backend, etc.).
4. La respuesta se escribe de vuelta al socket del cliente.
5. La conexión se cierra o sigue abierta si usás keepalive.

Todo este flujo es asíncrono, lo que significa que mientras un cliente está esperando una respuesta, el worker puede atender otra conexión sin necesidad de threads adicionales.

Nginx como servidor web

El rol clásico de Nginx es servir contenido estático (HTML, CSS, imágenes) directamente, sin necesidad de un script de servidor adicional.

Servir archivos estáticos

El archivo de configuración más básico (/etc/nginx/nginx.conf) incluye un server block que define la raíz (root) del sitio.

# nginx.conf (ejemplo simplificado)
events {}

http {
    server {
        listen 80;
        server_name example.com;
        root /var/www/html;
        index index.html index.htm;

        # Servir un archivo específico
        location = /special {
            alias /var/www/special.html;
        }
    }
}

Cuando un cliente solicita http://example.com/, Nginx mira en /var/www/html/index.html. Si no existe, intenta index.htm. Esta lógica es rápida porque Nginx usa el sistema de archivos directamente sin overhead adicional de proceso.

Manejo de MIME, compresión y cache

Nginx incluye un conjunto de directivas útiles para optimizar el servicio de archivos estáticos:

• types: Define la asociación de extensiones de archivo a tipos MIME.
• gzip on;: Habilita la compresión GZIP para el contenido HTML, JSON, CSS, etc.
• cache_control: Añade encabezados Cache‑Control para un control granular.

server {
    listen 3000;
    server_name api.example.com;

    # Tipos MIME para API JSON
    default_type application/json;

    # Servir JSON desde /data
    location /data {
        root /var/www/json;
        add_header Cache-Control "public, max-age=3600";
    }
}

Estas directivas son especialmente útiles para servir contenido CDN o API estático.

Servir contenido HTTPS

Nginx puede manejar TLS sin necesidad de software adicional gracias a OpenSSL. Configurás un listen 443 ssl y provees ssl_certificate y ssl_certificate_key. También podés habilitar ssl_protocols y ssl_ciphers para una seguridad óptima.

server {
    listen 443 ssl http2;
    server_name secure.example.com;

    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/private.key;

    # Habilitar HTTP/2 y ciphers de alta seguridad
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Servir archivos estáticos
    root /var/www/secure;
    index index.html;
}

HTTPS es transparente para el cliente, pero Nginx desacripterá el payload, lo podrá inspeccionar para load balancing o reescritura de URLs, y luego lo volverá a encriptar al enviarlo a los backends si es necesario.

Nginx como proxy inverso

Un proxy inverso acepta solicitudes de clientes y las reenvía a uno o más servidores backend, ocultando los detalles internos. Las razones típicas para usarlo incluyen:

• Terminación TLS: Una sola IP pública con TLS, detrás de la cual hay múltiples servidores HTTP sin TLS.
• Equilibrio entre servicios: Retrasar el enrutamiento a diferentes microservicios basado en subrutas.
• Seguridad: Agregar autenticación, rate‑limiting o inspección antes de que la solicitud llegue al backend.
• Redirección/reescritura: Normalizar URLs, remover/prefix subrutas, o redirigir a otra ubicación.

Proxy directo simple a un backend

El proxy_pass es la directiva clave que reenvía la solicitud. Un proxy inverso típico se ve así:

server {
    listen 80;
    server_name api.example.com;

    # Redirigir todo el tráfico /api a un servicio Node.js
    location /api {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Explicación de las directivas

• proxy_pass: La URL del servidor backend (puede incluir ruta, por ejemplo http://upstream/). Si la URL incluye una ruta, esa parte se reemplaza.
• proxy_set_header: Añade o sobrescribe encabezados que el backend verá. Es vital enviar X‑Forwarded‑For para depuración.
• proxy_http_version 1.1; y proxy_keepalive_timeout: Mantienen las conexiones alive para reducir la sobrecarga de handshake.

Terminación TLS (HTTPS) + Proxy hacia un backend HTTP

Puedes recibir HTTPS en Nginx y comunicarte con el backend usando HTTP. Esto es común para reducir la carga de CPU en los app servers.

server {
    listen 443 ssl http2;
    server_name secure-backend.example.com;

    ssl_certificate /etc/nginx/certs/tls.crt;
    ssl_certificate_key /etc/nginx/certs/tls.key;

    location / {
        proxy_pass http://localhost:8080; # backend HTTP
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ahora los clientes pueden usar HTTPS, mientras el backend puede seguir usando HTTP simple, reduciendo la overhead de cifrado.

Reescritura y redirección de URLs

Nginx puede reescribir URLs basándose en reglas rewrite. Ten cuidado: rewrite afecta la solicitud actual, mientras que proxy_pass reenvía la solicitud a un backend, así que el orden es importante.

server {
    listen 80;
    server_name example.com;

    # Redirigir /old-path a /new-path internamente sin cambiar la URL para el cliente
    location ^~ /old-path {
        rewrite ^/old-path/(.*) /new-path/$1 break;
        proxy_pass http://backend;
    }
}

La directiva break indica a Nginx que termine el procesamiento de la regla de reescritura y continúe con proxy_pass.

Autenticación (básica y de OAuth2)

Puedes proteger un endpoint con autenticación básica (útil para debugging o interfaces internas).

server {
    listen 80;
    server_name admin.example.com;

    location /admin {
        auth_basic "Restricted Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://admin-service:8080;
    }
}

Para OAuth2 más avanzado, típicamente necesitarás un proveedor externo (Keycloak, Auth0). Nginx puede redirigir el cliente a ese proveedor, pero el flujo es más fácil de manejar con un proxy inverso que actúa como cliente de OAuth (usando auth_request).

Rate limiting y limitación de conexiones

Protege tus backends usando directivas como limit_req (por IP) o limit_conn (conexiones por segundo).

server {
    listen 80;

    # 10 solicitudes por segundo por IP, con burst de 20
    limit_req zone=one burst=20 nodelay;

    location / {
        proxy_pass http://backend;
    }
}

# Definir la zona de limitación anteriormente
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

Estos límites previenen el abuso y evitan que un solo cliente sature tus backends.

Nginx como balanceador de carga

Cuando Nginx se usa como balanceador de carga, su rol es distribuir el tráfico entrante entre múltiples servidores upstream (backend). El balanceo de carga se configura dentro del bloque upstream y luego se hace referencia a ese upstream en un bloque location o server.

Configuración básica de balanceo de carga: round‑robin

upstream web_backend {
    # Nginx usa round‑robin por defecto
    server 10.0.0.2 weight=5;
    server 10.0.0.3 weight=5;
    server 10.0.0.4 down; # marcar como fuera de servicio
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://web_backend;
    }
}

Cada servidor recibe tráfico de forma alterna. Podés weight para inclinar la balanza (mayor peso = más solicitudes).

Algoritmos de balanceo de carga

Nginx soporta varios algoritmos. Podés especificarlos en la directiva upstream usando ip_hash, hash, least_conn o el integrado random.

• ip_hash: Mismo cliente siempre va al mismo backend (útil para sesión sticky).
• hash $request_uri: Distribuye basado en el URI de la solicitud (útil para caché de contenido estático).
• least_conn: Envia las solicitudes al backend con menos conexiones activas (bueno para API lentas).
• random: Aleatoriza (útil para pruebas).

upstream api_cluster {
    ip_hash;
    server svc-a:8080;
    server svc-b:8080;
    server svc-c:8080;
}

Health checks y detección de servidores caídos

Nginx puede comprobar la salud de los backends usando max_fails y fail_timeout. Después de un número dado de errores de conexión, un servidor se marca como caído por un período de tiempo.

upstream monitored {
    server 10.0.0.10 max_fails=3 fail_timeout=30s;
    server 10.0.0.11 max_fails=2 fail_timeout=10s;
}

También podés usar health_check (disponible en la versión comercial de Nginx Plus). Para la versión open‑source, un enfoque popular es usar proxy_next_upstream para reintentar y saltar servidores caídos.

upstream fallback {
    server 10.0.0.10;
    server 10.0.0.11;
}

server {
    location / {
        proxy_pass http://fallback;
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
        proxy_next_upstream_tries 3;
    }
}

Stickiness de sesión con ip_hash

Si tu aplicación mantiene estado por sesión (por ejemplo, tokens en servidor), ip_hash garantiza que una dirección IP específica siempre llegue al mismo backend.

upstream session_backend {
    ip_hash;
    server app1:8080;
    server app2:8080;
}

Ten en cuenta que ip_hash usa un hash del remote_addr, que puede ser la dirección real del cliente si Nginx está detrás de un proxy. Asegúrate de pasar X-Real-IP o X-Forwarded-For (no, espera, ip_hash usa la conexión directa del cliente). Usualmente está bien para la mayoría de las implementaciones.

Separación de tráfico HTTP y HTTPS

Puedes tener un servidor upstream para tráfico HTTP plano (http://backend) y otro para HTTPS (https://secure-backend). Esto es útil si quieres proteger tus backends con TLS en internamente, mientras sirves HTTPS externamente también.

upstream http_backends {
    server backend1.example.com;
    server backend2.example.com;
}

upstream https_backends {
    server backend1.secure.example.com;
    server backend2.secure.example.com;
}

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://http_backends;
    }
}

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/private.key;
    location / {
        proxy_pass https://https_backends;
    }
}

Ejemplo de balanceador de carga completo con todas las características

Un archivo nginx.conf real en un escenario de producción a menudo combina todas las ideas anteriores. Aquí hay un archivo completo y comentado que muestra un servidor web frontal, un proxy inverso para una API y un balanceador de carga para tres nodos de aplicación:

# nginx.conf

user  nginx;
worker_processes  auto;
error_log /var/log/nginx/error.log notice;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    # Tamaño del buffer para streaming de respuesta grandes
    proxy_buffers 16 32k;
    proxy_buffer_size 64k;

    # Zona de limitación de rate‑limiting por IP
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=20r/s;

    # Upstream para la API (balanceo de carga con health checks)
    upstream api_cluster {
        least_conn; # enviar al backend con menos conexiones activas
        server api-node1.internal max_fails=3 fail_timeout=30s;
        server api-node2.internal max_fails=3 fail_timeout=30s weight=2;
        server api-node3.internal down; # inicialmente fuera de servicio
    }

    # Upstream para contenido estático (simple round‑robin)
    upstream static_backend {
        server static1.example.com;
        server static2.example.com;
    }

    # Servidor virtual para tráfico HTTP
    server {
        listen 80;
        server_name example.com;

        # Servir contenido estático
        location ^~ /static/ {
            proxy_pass http://static_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        # Proxy inverso para API bajo limitación de rate
        location /api/ {
            limit_req zone=api_limit burst=40 nodelay;

            proxy_pass http://api_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

            # Reintentar en errores de backend
            proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
            proxy_next_upstream_tries 3;
        }

        # Ruta de health‑check para balanceador externo (si está usando)
        location /health {
            access_log off;
            return 200 "healthy
";
            add_header Content-Type text/plain;
        }
    }

    # Servidor virtual para HTTPS (terminación TLS)
    server {
        listen 443 ssl http2;
        server_name example.com;

        ssl_certificate /etc/nginx/certs/fullchain.pem;
        ssl_certificate_key /etc/nginx/certs/private.key;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers on;
        ssl_ciphers HIGH:!aNULL:!MD5;

        # Misma API que antes pero sobre HTTPS hacia el mismo upstream
        location /api/ {
            proxy_pass http://api_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        # Servir archivos SSL de forma segura (por ejemplo, /robots.txt)
        location = /robots.txt {
            alias /var/www/robots.txt;
            add_header Cache-Control "public, max-age=604800";
        }
    }
}

Este archivo de configuración muestra muchas de las mejores prácticas que vamos a discutir más adelante (secciones siguientes).

Diagrama: Flujo de tráfico con Nginx como proxy inverso y balanceador de carga

A continuación, hay un diagrama Mermaid que captura visualmente el flujo de una solicitud típica a través de Nginx en un entorno de producción con tres servidores backend.

graph TD
    A[Cliente (navegador/cURL)] --> B[Nginx (Puerto 80/443)]
    B --> C[Proxy Inverso / Balanceador de carga]
    C --> D[Servidor Upstream 1]
    C --> E[Servidor Upstream 2]
    C --> F[Servidor Upstream 3]
    D --> G[Base de Datos / Almacén de archivos externo]
    E --> G
    F --> G
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#9f9,stroke:#333,stroke-width:2px
    style C fill:#99f,stroke:#333,stroke-width:2px
    style D fill:#ff9,stroke:#333,stroke-width:2px
    style E fill:#ff9,stroke:#333,stroke-width:2px
    style F fill:#ff9,stroke:#333,stroke-width:2px
    style G fill:#cfc,stroke:#333,stroke-width:2px

Este diagrama enfatiza tres ideas clave:

1. El cliente interactúa con Nginx en los puertos HTTP (80) y HTTPS (443).
2. La lógica de proxy inverso y balanceador de carga es manejada por el bloque proxy_pass/upstream de Nginx.
3. Los tres servidores upstream pueden distribuir la carga y compartir recursos (base de datos, almacenamiento) como se necesite.

El diagrama también deja en claro que Nginx nunca se comunica directamente con la base de datos (a menos que uses un servidor de bases de datos separado); la base de datos está detrás de los servidores de aplicación.

Mejores prácticas y errores comunes

1. Ajusta el número de workers

El número de procesos worker debe reflejar la capacidad de la CPU, no simplemente el número de núcleos. La regla general es usar worker_processes auto;, lo que hace que Nginx use el número de núcleos de CPU. Bajo alta carga, puedes incrementar manualmente.

Error: Asignar miles de workers cuando solo hay un puñado de solicitudes simultáneas, lo que lleva a alta memoria.

2. Usa keep‑alive y timeouts apropiados

• proxy_read_timeout: Evita que las solicitudes colgadas bloqueen un worker.
• proxy_connect_timeout: Evita que las conexiones a backends estancados consuman recursos.
• keepalive_timeout: Mantiene las conexiones persistentes abiertas más tiempo (valor predeterminado 75s).

proxy_connect_timeout  75s;
proxy_send_timeout    75s;
proxy_read_timeout    75s;
keepalive_timeout     75s;

3. Activa HTTP/2 si es posible

El listen 443 ssl http2; habilita HTTP/2, que reduce la latencia de encabezado y permite la multiplexación de streams.

4. Configuración correcta de SSL

• Usa TLSv1.2 y TLSv1.3.
• Deshabilita los cifrados inseguros (!aNULL:!MD5:!3DES).
• Considera habilitar ssl_session_cache para reutilizar sesiones.

5. Health checks para upstream

Para la versión gratuita, max_fails y fail_timeout son decentes. Para monitoreo más avanzado, puedes combinar Nginx con nginx_upstream_check_module o usar un balanceador de carga externo.

6. Reglas de limitación de rate

Define zonas de limitación (limit_req_zone) una vez por servidor o por ubicación. Evita definir zonas repetidas dentro de múltiples bloques server; en su lugar, colócalas en el bloque http.

7. Evita bloquear la CPU con proxy de grandes cargas

Si estás sirviendo archivos grandes, considera establecer proxy_buffering on; y ajustar proxy_buffer_size y proxy_buffers para evitar que la solicitud completa quepa en la memoria del worker.

8. Diferencia entre rewrite y proxy_pass con URI

• rewrite ^/(.*) http://backend/$1; redirige la solicitud al cliente.
• proxy_pass http://backend/$1; reenvía al backend conservando la ruta.

Usar rewrite incorrectamente puede hacer que el cliente vea una URL diferente, lo que a menudo causa problemas de SEO y caché.

9. No expongas información sensible en logs

Por defecto, Nginx registra $remote_addr y $request. Si estás detrás de un proxy, considera usar $proxy_add_x_forwarded_for en logs (log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$proxy_add_x_forwarded_for"';).

10. Mantén la configuración en archivos separados

Grandes proyectos necesitan modularidad: cada server block en su propio archivo dentro de /etc/nginx/sites-available/ y enlaces simbólicos en sites-enabled. Esto hace que las actualizaciones sean más fáciles y reduces el tiempo de reinicio.

Errores comunes y sus síntomas

Conclusión

Nginx es mucho más que un servidor web; es una única puerta de entrada que puede servir contenido estático, actuar como un proxy inverso para enrutamiento seguro y normalizar encabezados, y funcionar como un balanceador de carga sofisticado que distribuye tráfico entre múltiples backends.

Al comprender las tres facetas, podés diseñar una arquitectura limpia y escalable que simplifique muchas capas de infraestructura. El ejemplo de configuración que presentamos muestra cómo combinar múltiples servidores virtuales, un upstream con balanceo de carga, terminación TLS y control de rate-limit en un único archivo de configuración.

El diagrama proporcionado ayuda a visualizar cómo fluyen las solicitudes desde el cliente a través de Nginx y luego se distribuyen entre servidores backend, haciendo que las rutas de tráfico sean claras en el momento de la solución de problemas o al agregar nuevos servicios.

Finalmente, seguir las mejores prácticas, especialmente con respecto a health checks, ajuste de workers, timeouts y límites SSL, te ayudarán a evitar problemas comunes que pueden afectar el rendimiento y la estabilidad. Con un mantenimiento adecuado, Nginx seguirá siendo una herramienta confiable por muchos años, independientemente del tamaño de la aplicación que estés construyendo.

Próximos pasos

• Práctica: Implementa la configuración de ejemplo en una máquina virtual liviana, usa curl para probar rutas estáticas, de API y de proxy inverso.
• Monitoreo: Integra Nginx Plus o herramientas como nginx_exporter para métricas detalladas.
• Escalado: Añade más servidores en el upstream, experimenta con least_conn vs. ip_hash para ver el impacto en la distribución del tráfico.
• Seguridad: Agrega autenticación HTTP básica para endpoints de administración, habilita --with-http_dav_module si necesitas soporte para WebDAV.

Con estos conocimientos, estás listo para aprovechar todo el potencial de Nginx y construir una infraestructura web resilient y de alto rendimiento. ¡Feliz configuración!

# Demostración simple de sintaxis para asegurar la configuración
nginx -t

# Imprimir una breve lista de verificación de configuración
def check_config():
    checks = [
        "worker_processes definido",
        "bloques http y server presentes",
        "escuchando en puerto 80/443",
        "proxy_pass definido para location /api/",
        "health checks en upstream",
        "directivas SSL presentes"
    ]
    for c in checks:
        print(c)

if __name__ == "__main__":
    check_config()

¡Ahora tienes todo lo necesario para comenzar con Nginx como proxy inverso, servidor web y balanceador de carga! ¡Feliz programación! ðº½ï¸