Las 50 principales preguntas y respuestas de la entrevista de Nginx (2026)

Por: Bryce León Bryce León
Hours Actualizado

Las mejores preguntas y respuestas de la entrevista de Nginx

Prepararse para una entrevista de Nginx requiere previsión, claridad y conocimiento de cómo los entrevistadores evalúan el conocimiento operativo real hoy en día. Las preguntas de entrevista de Nginx revelan profundidad, capacidad de toma de decisiones, resolución de problemas y preparación para la producción.

Estos puestos abren caminos en la infraestructura de la nube, la ingeniería de rendimiento y la seguridad, donde las configuraciones prácticas son cruciales. Los empleadores valoran la experiencia técnica, el conocimiento del dominio y el análisis adquiridos en el trabajo de campo, ayudando a principiantes, ingenieros de nivel medio y profesionales sénior a aplicar habilidades básicas y avanzadas dentro de los equipos bajo la guía de gerentes y líderes de equipo. Leer más ...

👉 Descarga gratuita de PDF: Preguntas y respuestas de la entrevista de Nginx

Las mejores preguntas y respuestas de la entrevista de Nginx

1) Explique qué es NGINX y por qué se utiliza ampliamente en la infraestructura web.

NGINX es un servidor web de código abierto de alto rendimiento que también funciona como proxy inverso, balanceador de carga y caché HTTP. Es compatible con los protocolos HTTP, HTTPS, SMTP, POP3 e IMAP. Su arquitectura utiliza una event-driven, asynchronous model Esto le permite gestionar decenas de miles de conexiones simultáneas con un bajo consumo de memoria y CPU. Esta escalabilidad hace que NGINX sea especialmente adecuado para aplicaciones web de alto tráfico, microservicios y arquitecturas distribuidas. Por ejemplo, las empresas con cargas de trabajo de alto tráfico (como plataformas de contenido o puertas de enlace API) suelen preferir NGINX para gestionar conexiones simultáneas y la entrega de contenido estático de forma eficiente.

2) ¿Cómo maneja NGINX las solicitudes HTTP internamente (arquitectura basada en eventos)?

La fortaleza principal de NGINX reside en su event-driven, non-blocking architectureEn lugar de generar un hilo o proceso independiente para cada solicitud (como los servidores tradicionales), NGINX utiliza un pequeño conjunto de procesos de trabajo que utilizan bucles de eventos asíncronos. Cada proceso de trabajo puede gestionar miles de conexiones esperando las notificaciones de disponibilidad del sistema operativo y procesando los eventos cuando ocurren. Al no bloquearse en las operaciones de E/S, NGINX puede servir contenido estático y proxy con recursos mínimos. Este modelo es ideal para casos de uso de alta concurrencia, lo que lo hace más eficiente que los servidores basados ​​en procesos con cargas elevadas.

3) ¿Cuáles son las principales diferencias entre NGINX y Apache?

Si bien tanto NGINX como Apache son servidores web populares, difieren en arquitectura, rendimiento y objetivos de diseño:

Aspecto Nginx APACHE
Modelo de concurrencia Impulsado por eventos (asincrónico, no bloqueante) Basado en procesos/hilos (bloqueo)
Uso de la memoria Bajo por conexión Más alto por conexión
Mejores casos de uso Alto tráfico, contenido estático, equilibrio de carga Contenido dinámico y rico ecosistema de módulos
Global Escala con menos recursos Requiere más hardware debido a los procesos
Manejo del módulo Módulos seleccionados en tiempo de compilación Dinámico en tiempo de ejecución

El diseño de NGINX optimiza el rendimiento bajo carga, mientras que Apache proporciona una mayor flexibilidad con módulos dinámicos y un amplio soporte de lenguaje.

4) ¿Cuáles son los componentes clave de un archivo de configuración NGINX?

Un archivo de configuración NGINX (ruta predeterminada: /etc/nginx/nginx.conf) consta de bloques de directivas estructuradas que determinan cómo se comporta NGINX:

  • Contexto principal: configuraciones globales como worker_processes, error_log y pid
  • Bloque de eventos: Gestiona las conexiones de los trabajadores y el multiprocesamiento.
  • Bloqueo HTTP: Contiene configuraciones para el manejo de HTTP (compresión, almacenamiento en caché, gzip, etc.)
    • Bloque de servidor: define hosts virtuales (dominios y puertos)
    • Bloque de ubicación: Define reglas de enrutamiento y cómo se manejan URI específicos

Estos bloques trabajan juntos para enrutar solicitudes, definir configuraciones de proxy y configurar SSL/TLS y almacenamiento en caché.

5) ¿Cómo recargar de forma segura la configuración de NGINX sin tiempo de inactividad?

Para recargar NGINX con configuraciones actualizadas without interrupting active connections, utiliza el siguiente comando:

nginx -s reload

o en sistemas que utilizan systemd:

sudo systemctl reload nginx

Este comando indica al proceso maestro que vuelva a leer los archivos de configuración y reinicie correctamente los trabajadores sin interrumpir las conexiones existentes. Saber cómo realizar estas recargas fluidas es esencial en entornos que requieren alta disponibilidad.

6) Describe cómo configurar NGINX como proxy inverso.

Un proxy inverso reenvía las solicitudes de los clientes a los servidores backend (grupo ascendente) y luego devuelve la respuesta. A continuación se muestra un bloque típico de proxy inverso de NGINX:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

Esta configuración mejora la seguridad, proporciona distribución de carga y habilita políticas de almacenamiento en caché o limitación de velocidad entre los clientes y los servidores de aplicaciones.

7) Explique los procesos Master y Worker de NGINX.

En NGINX:

  • El Proceso maestro Administra la configuración, inicia procesos de trabajo y maneja operaciones privilegiadas como la vinculación a puertos.
  • Procesos de trabajo realizar el manejo real de las solicitudes: procesar las conexiones entrantes y ejecutar las reglas configuradas.

El uso de múltiples trabajadores mejora la concurrencia y se puede ajustar según los núcleos de CPU disponibles y las demandas de tráfico. La división de roles mejora el rendimiento y la estabilidad.

ARTÍCULOS RELACIONADOS

8) ¿Cómo se puede restringir el procesamiento de nombres de servidor indefinidos en NGINX?

Para descartar solicitudes sin una validez Host encabezado en NGINX:

server {
    listen 80;
    server_name "";
    return 444;
}

Esta configuración devuelve código 444, un estado NGINX no estándar que cierra la conexión sin una respuesta, rechazando efectivamente los hosts indefinidos y mejorando la seguridad.

9) ¿Para qué se utiliza ngx_http_upstream_module?

El ngx_http_upstream_module la define groups of backend servers (upstreams) a los que NGINX puede pasar solicitudes mediante directivas como proxy_pass, fastcgi_pass o uwsgi_passEsto permite flexibilidad para escalar aplicaciones en entornos con balanceo de carga. Al agrupar varios servidores backend, NGINX puede distribuir el tráfico según políticas definidas, lo que permite la operación por turnos y otras estrategias.

10) Describe cómo se utiliza NGINX para servir contenido estático y dinámico.

NGINX es altamente eficiente al servir archivos estáticos (HTML, CSS, imágenes) utilizando directamente su bucle de eventos optimizado y mecanismos de E/S de archivos. Para contenido dinámico, NGINX pasa solicitudes a procesadores backend como PHP-FPM, Python Servidores WSGI o frameworks de aplicaciones mediante mecanismos FastCGI/proxy. Esta separación permite a NGINX destacar como servidor de archivos estático, a la vez que aprovecha los servicios de backend para la generación dinámica, garantizando así un rendimiento y una escalabilidad óptimos.

11) ¿Cómo funciona el equilibrio de carga en NGINX y cuáles son los diferentes métodos disponibles?

NGINX proporciona una robusta balanceo de carga a través de la upstream Directiva que distribuye el tráfico entre múltiples servidores backend para optimizar el rendimiento y garantizar una alta disponibilidad. Admite varios métodos:

Método Descripción Mejores casos de uso
Round Robin Método predeterminado que rota solicitudes entre servidores secuencialmente. Cargas de trabajo distribuidas uniformemente.
Conexiones mínimas Envía solicitudes al servidor con menos conexiones activas. Sesiones de larga duración.
hash de ip Utiliza la IP del cliente para determinar la selección del servidor. Persistencia de la sesión.
menos tiempo Saldos basados ​​en tiempo de respuesta y número de conexiones. Aplicaciones sensibles a la latencia.

NGINX también puede realizar controles de salud para eliminar servidores en mal estado de forma dinámica, garantizando un flujo de tráfico fluido y resiliencia.

12) ¿Cuál es la diferencia entre NGINX de código abierto y NGINX Plus?

Nginx Open Source es la versión comunitaria que ofrece capacidades esenciales de servidor web, proxy y equilibrio de carga. NGINX más es la edición comercial que amplía esas funciones con mejoras de nivel empresarial, como monitoreo avanzado, persistencia de sesión, reconfiguración dinámica y controles de estado activos.

Característica NGINX de código abierto NGINX más
Balanceo de carga Básico (Round Robin, Hash de IP) Avanzado (menor tiempo, reconfiguración dinámica)
Monitoring Herramientas manuales/externas Panel de control y API integrados
Almacenamiento en caché Básico Mejorado con control de purga
Soporte Solo comunidad Soporte y actualizaciones empresariales

Las organizaciones con cargas de trabajo de misión crítica a menudo eligen NGINX Plus por su confiabilidad y capacidad de observación mejoradas.

13) ¿Cómo se implementa el almacenamiento en caché en NGINX?

El almacenamiento en caché en NGINX mejora la velocidad de respuesta y reduce la carga del backend al almacenar localmente el contenido al que se accede con frecuencia. Se habilita mediante proxy_cache Directiva. Ejemplo de configuración:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;
server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://backend;
    }
}

Las respuestas almacenadas en caché se entregan directamente desde el disco cuando llega una solicitud coincidente, omitiendo el procesamiento ascendente. Puede controlar la expiración de la caché mediante proxy_cache_valid y excluir URI específicos con proxy_no_cacheEste mecanismo es crucial para entornos de alto tráfico, como sitios de noticias o de comercio electrónico.

14) Explique el propósito y el uso de la directiva “try_files”.

El try_files La directiva comprueba la existencia de archivos en un orden específico antes de enviar una solicitud a la ubicación de respaldo. Se usa comúnmente para enrutamiento de sitios estáticos or solicitudes de una sola página (SPA).

Ejemplo:

location / {
    try_files $uri $uri/ /index.html;
}

Aquí, NGINX primero verifica si el URI solicitado coincide con un archivo, luego con un directorio y, finalmente, enruta las solicitudes no coincidentes a /index.htmlEsto mejora la eficiencia y la experiencia del usuario al servir archivos almacenados en caché o estáticos directamente, evitando llamadas innecesarias al backend.

15) ¿Cómo puede NGINX gestionar la terminación HTTPS y SSL/TLS?

NGINX actúa como un proxy de terminación SSL/TLS, gestionando el cifrado y descifrado en la capa del servidor antes de reenviar las solicitudes sin cifrar a los servicios ascendentes. Ejemplo de configuración:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;
    location / {
        proxy_pass http://backend;
    }
}

Es compatible con HTTP / 2, Grapado OCSP, HSTS y suites de cifrado modernas, lo que permite comunicaciones seguras y de alto rendimiento. La terminación de SSL en NGINX reduce la sobrecarga de cifrado en los servidores backend y simplifica la gestión de certificados.

16) ¿Cuál es la diferencia entre reescribir y redirigir en NGINX?

Ambos volver a escribir y reorientar modifican la forma en que se enrutan las solicitudes, pero difieren fundamentalmente:

Aspecto Volver a escribir Redireccionar
Categoría Reescritura de URL interna Redirección de clientes externos
Código de respuesta 200 (interno) 301/302 (redirección HTTP)
Visibilidad Transparente para el usuario El cliente ve la nueva URL
Caso de uso URL optimizadas para SEO, enrutamiento Migración de dominio, implementación de HTTPS

Ejemplo:

rewrite ^/oldpage$ /newpage permanent;  # Redirect
rewrite ^/img/(.*)$ /assets/$1 break;   # Rewrite

Comprender esta distinción es clave para optimizar el SEO y la lógica de enrutamiento de manera efectiva.

17) ¿Cómo proteger NGINX de vulnerabilidades comunes?

El fortalecimiento de la seguridad implica una combinación de mejores prácticas:

  • Deshabilitar tokens de servidor: server_tokens off;
  • Métodos de solicitud de límite: Permitir únicamente GET, POST, HEAD.
  • Restringir los desbordamientos de búfer: Configurar client_max_body_size y client_body_buffer_size.
  • Utilice HTTPS con cifrados modernos.
  • Habilitar limitación de velocidad vía limit_req_zone.
  • Ocultar información de la versión y deshabilitar el listado de directorios.

Además, usando un Firewall de aplicaciones web (WAF) como ModSecurity with NGINX Puede filtrar tráfico malicioso. Actualizar NGINX regularmente y aplicar parches de seguridad es esencial para prevenir ataques de día cero.

18) ¿Qué son las variables NGINX y cómo se utilizan en las configuraciones?

Las variables NGINX almacenan datos dinámicos utilizados en las configuraciones y el procesamiento de registros. Pueden representar encabezados de solicitud, direcciones IP de cliente o valores calculados. Algunos ejemplos incluyen: $remote_addr, $host, $uri, $request_method y $upstream_addr.

Por ejemplo:

log_format custom '$remote_addr - $host - $uri';

Las variables añaden flexibilidad, lo que permite el enrutamiento condicional y el registro personalizado. También puede definir variables personalizadas mediante set directiva, que ayuda en el diseño de configuración modular.

19) ¿Cómo se puede configurar la limitación de velocidad en NGINX?

La limitación de velocidad controla la frecuencia con la que los usuarios pueden enviar solicitudes, lo que protege contra ataques de fuerza bruta y DDoS. Se configura mediante limit_req_zone directiva:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
    location / {
        limit_req zone=mylimit burst=5;
    }
}

Esto permite una solicitud por segundo con una ráfaga de cinco. NGINX descarta las solicitudes sobrantes o las retrasa según la configuración. La limitación de velocidad garantiza un uso justo de los recursos y evita la sobrecarga del servidor.

20) ¿Cuáles son las ventajas y desventajas de utilizar NGINX como proxy inverso?

NGINX como proxy inverso ofrece numerosos beneficios pero también algunas desventajas:

Ventajas Desventajas
Alto rendimiento y manejo de concurrencia Requiere ajuste manual para implementaciones a gran escala
Terminación SSL y seguridad centralizada Soporte limitado para módulos dinámicos (tiempo de compilación)
Compatibilidad con equilibrio de carga y almacenamiento en caché Configuración compleja para nuevos usuarios
Filtrado de la capa de aplicación Falta de ejecución de contenido dinámico nativo

Sus ventajas superan ampliamente las limitaciones en la mayoría de los escenarios empresariales, lo que convierte a NGINX en un componente indispensable de la infraestructura web moderna.

21) ¿Cómo se puede supervisar el rendimiento y la salud de NGINX en producción?

Monitorear NGINX es crucial para identificar cuellos de botella, fallos y comportamientos anormales del tráfico. Se pueden utilizar varios enfoques:

  1. Módulo de estado incorporado (stub_status):

    Muestra las conexiones activas, las solicitudes gestionadas y los estados de lectura y escritura. Ejemplo:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. Panel de control de NGINX Plus: Proporciona métricas en tiempo real a través de API REST y GUI.
  3. Integraciones de terceros: Herramientas como Prometheus, Grafana, Datadog o ELK pueden recopilar métricas y registros.
  4. Registros de acceso y errores: La rotación regular de registros y el análisis con herramientas como GoAccess o AWStats mejoran la observabilidad.

La supervisión ayuda a garantizar el tiempo de actividad, la detección rápida de fallas y la planificación de la capacidad.

22) ¿Cuál es la diferencia entre las directivas proxy_pass y fastcgi_pass?

Ambas directivas reenvían solicitudes a servicios backend pero están diseñadas para diferentes protocolos:

Directiva Proposito Protocolo de backend Ejemplo de uso
proxy_pass Reenvía solicitudes HTTP o HTTPS a servidores backend HTTP RevAPI web o microservicios de proxy inverso
fastcgi_pass Envía solicitudes a un procesador FastCGI FastCGI PHP-FPM, Python Aplicaciones FastCGI

Ejemplo:

location /api/ {
    proxy_pass http://backend;
}
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

En resumen, utilice contraseña_proxy para backends HTTP genéricos y fastcgi_pass para entornos de ejecución de lenguajes dinámicos como PHP.

23) ¿Cómo se puede configurar la compresión gzip en NGINX y cuáles son sus beneficios?

Habilitar la compresión Gzip en NGINX reduce el uso del ancho de banda y mejora el tiempo de carga al comprimir las respuestas basadas en texto antes de enviarlas a los clientes.

Configuración de ejemplo:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_vary on;

Beneficios:

  • Reduce el tamaño de las transferencias de archivos hasta en un 70%.
  • Mejora los puntajes de rendimiento de la página y el tiempo hasta el primer byte (TTFB).
  • Ahorra costes de ancho de banda, especialmente beneficioso para usuarios móviles.

Sin embargo, no debe aplicarse a archivos ya comprimidos (por ejemplo, .zip, .jpg, .png) para evitar la sobrecarga de la CPU.

24) ¿Cuáles son algunas de las mejores prácticas para ajustar NGINX para alto tráfico?

La optimización de alto tráfico implica un ajuste cuidadoso de los recursos y los parámetros de configuración:

Área Directiva Práctica recomendada
Los obreros worker_processes auto; Coincidir con los núcleos de la CPU
Conexiones worker_connections 4096; Aumentar la concurrencia
Mantener viva keepalive_timeout 65; Optimizar la reutilización del cliente
Archive Descriptoros OS ulimit -n Aumentar los límites para los sockets abiertos
Almacenamiento en caché proxy_cache_path Reducir la carga del backend
Gzip gzip on; Comprimir respuestas de texto

Además, usando E/S de disco asincrónica, balanceo de carga y controles de salud previos garantiza estabilidad y velocidad bajo solicitudes simultáneas masivas.

25) ¿Cómo maneja NGINX las conexiones WebSocket?

Los WebSockets permiten la comunicación bidireccional entre el cliente y el servidor, crucial para las aplicaciones en tiempo real. NGINX lo admite de forma nativa mediante el reenvío de encabezados.

Configuración de ejemplo:

location /ws/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Puntos claves:

  • El Upgrade y Connection Los encabezados son obligatorios.
  • Asegúrese de que NGINX utilice HTTP/1.1 para conexiones TCP persistentes.
  • Los WebSockets de equilibrio de carga pueden requerir sesiones persistentes utilizando ip_hash.

Esta configuración admite aplicaciones como chat, compraventa de acciones o juegos.

26) ¿Cuál es el propósito de la directiva “worker_rlimit_nofile”?

worker_rlimit_nofile Define el número máximo de descriptores de archivos abiertos disponibles para los procesos de trabajo. Este límite afecta directamente la cantidad de conexiones simultáneas que NGINX puede gestionar. Ejemplo:

worker_rlimit_nofile 100000;

Aumentar este límite es vital para sistemas de alta concurrencia (como puertas de enlace API o plataformas de streaming). Sin embargo, el límite del sistema operativo (ulimit -n) también debe aumentarse para que coincida con este valor para mantener la coherencia.

27) ¿Cómo se puede utilizar NGINX para reescribir URL o redirigir a HTTPS automáticamente?

Redirigir HTTP a HTTPS garantiza una comunicación segura. Ejemplo:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Esta configuración emite un Redirección permanente 301 De HTTP a HTTPS. Para un control más preciso, las reglas de reescritura pueden aplicar una redirección específica de la ruta:

rewrite ^/oldpath$ /newpath permanent;

La implementación automática de HTTPS mejora la clasificación SEO, evita ataques de intermediario y mantiene una experiencia de usuario consistente.

28) ¿Cuáles son algunas razones comunes de errores “502 Bad Gateway” en NGINX?

Un error "502 Bad Gateway" indica que NGINX, actuando como proxy, no recibió una respuesta válida de un servidor ascendente. Las causas comunes incluyen:

  • Fallo o indisponibilidad del servidor backend.
  • Incorrecto proxy_pass URL o ruta de socket.
  • Tiempo de espera ascendente (proxy_read_timeout demasiado bajo).
  • Firewall o SELinux bloqueando conexiones ascendentes.
  • Parámetros FastCGI mal configurados (para PHP).

Para depurar, verifique los registros de errores (/var/log/nginx/error.log), verificar la accesibilidad ascendente y probar las respuestas del backend directamente a través de curl.

29) ¿Cómo NGINX soporta microservicios y arquitecturas basadas en contenedores (por ejemplo, Docker, Kubernetes)?

NGINX es ideal para entornos de microservicios Gracias a su diseño ligero y su funcionalidad de proxy inverso, en Docker o Kubernetes, cumple las siguientes funciones:

  • Controlador de ingreso: Administra el tráfico HTTP/S externo a los servicios internos.
  • Puerta de enlace de servicio: Realiza enrutamiento, equilibrio de carga y autenticación.
  • Proxy sidecar: Mejora la resiliencia y la observabilidad en las mallas de servicios (por ejemplo, Istio).

Las configuraciones de NGINX se pueden actualizar dinámicamente mediante Kubernetes ConfigMaps, lo que permite un control centralizado del tráfico y la gestión de SSL. Su enfoque modular se adapta perfectamente a las implementaciones contenedorizadas y nativas de la nube.

30) ¿Cuáles son las diferentes formas de mejorar la seguridad de NGINX para los sistemas de producción?

Mejorar la seguridad de NGINX requiere una configuración de varias capas:

  1. Endurecimiento de SSL/TLS: Utilice cifrados modernos, deshabilite SSLv3/TLSv1.0.
  2. Limitar los métodos HTTP: Permitir sólo verbos seguros (GET, POST, HEAD).
  3. Encabezados de seguridad: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Ocultar información de la versión: server_tokens off;
  5. Habilitar limitación de velocidad y controles de acceso.
  6. Integrar WAF o Fail2Ban para la prevención de fuerza bruta.

Combinadas, estas medidas crean un entorno NGINX reforzado y de nivel de producción, resistente a exploits comunes.

31) ¿Cómo se pueden depurar problemas de NGINX de manera efectiva?

La depuración de NGINX implica el análisis sistemático de registros, archivos de configuración y estados de los procesos. Los pasos clave incluyen:

  1. Comprobar sintaxis:
    2. nginx -t
  2. Valida la configuración antes de recargar.

    3. Habilitar el registro de depuración:

    error_log /var/log/nginx/error.log debug;
  3. Proporciona diagnósticos detallados del tiempo de ejecución.

    4. Analizar registros de acceso: Detectar códigos de respuesta y patrones de solicitud utilizando:

    tail -f /var/log/nginx/access.log
  4. Conectividad de prueba: Use curl -v or wget para verificar la accesibilidad del backend.
  5. Monitorear conexiones activas: Vía stub_status or netstat.

Comprender los procesos de trabajo de NGINX, los límites de búfer y las respuestas ascendentes ayuda a identificar rápidamente los cuellos de botella en los sistemas de producción.

32) ¿Cómo se configura el registro de NGINX y qué son los formatos de registro personalizados?

NGINX proporciona mecanismos de registro flexibles a través de access_log y error_log directivas

Configuración de ejemplo:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$request_time"';

access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;

Tu puedes definir formatos personalizados para incluir métricas como $upstream_addr, $request_time o $bytes_sent.

Para una observación avanzada, los registros a menudo se envían a ELK, Loki o Splunk para análisis y paneles de control en tiempo real.

33) ¿Cuál es el papel de la directiva proxy_buffering en NGINX?

proxy_buffering controla si NGINX almacena en búfer las respuestas de los servidores ascendentes antes de enviarlas a los clientes.

Configuración Descripción Caso de uso
proxy_buffering on; Bufferes la respuesta completa para un rendimiento optimizado Predeterminado; mejora el rendimiento
proxy_buffering off; Transmite datos directamente a los clientes sin almacenamiento en búfer Transmisión en tiempo real o API

Por ejemplo, para deshabilitar el almacenamiento en búfer:

location /stream/ {
    proxy_buffering off;
}

Deshabilitar el almacenamiento en búfer es ideal para los servicios de chat o transmisión, pero puede reducir el rendimiento del tráfico web normal.

34) Explique cómo se puede invalidar o purgar el almacenamiento en caché de NGINX.

NGINX Open Source no incluye purga de caché incorporada, pero se puede lograr de varias maneras:

  1. Purga manual: Eliminar archivos del directorio de caché. 
    rm -rf /var/cache/nginx/*
  2. Módulo de terceros: Use ngx_cache_purge Para purgar mediante solicitud HTTP: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. Característica de NGINX Plus: Permite la purga de caché basada en API de forma dinámica.

La purga garantiza que el contenido obsoleto se reemplace rápidamente, manteniendo la frescura y la consistencia del contenido en las implementaciones de CDN o de múltiples nodos.

35) ¿Cómo gestiona NGINX los tiempos de espera de conexión?

NGINX proporciona múltiples directivas de tiempo de espera para controlar cuánto tiempo espera las respuestas del cliente o del servidor ascendente:

Directiva Proposito Predeterminado(s)
client_body_timeout Tiempo de espera para el cuerpo del cliente 60
client_header_timeout Tiempo de espera para el encabezado del cliente 60
keepalive_timeout Conexiones keepalive inactivas 75
send_timeout Hora de enviar datos al cliente 60
proxy_read_timeout Tiempo de espera para la respuesta ascendente 60

Un ajuste adecuado evita desconexiones innecesarias y garantiza experiencias de usuario más fluidas en condiciones de red variables.

36) ¿Cómo se implementa la implementación azul-verde utilizando NGINX?

En un despliegue azul-verdeDos entornos (Azul = activo, Verde = en espera) se ejecutan simultáneamente. NGINX actúa como enrutador de tráfico entre ellos.

Configuración de ejemplo:

upstream app_cluster {
    server blue.example.com;
    #server green.example.com; # Uncomment during switch
}
server {
    location / {
        proxy_pass http://app_cluster;
    }
}

Cuando se prueba y verifica la nueva versión (Verde), el tráfico se cambia actualizando la definición ascendente y recargando NGINX (nginx -s reload).

Este método asegura cero tiempo de inactividad durante las actualizaciones o reversiones de la aplicación.

37) ¿Qué es la ráfaga de limitación de velocidad y cómo mejora el rendimiento de NGINX?

El explosión El parámetro de limitación de velocidad permite que picos cortos de tráfico pasen temporalmente sin rechazo inmediato.

Ejemplo:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location /api/ {
    limit_req zone=mylimit burst=5 nodelay;
}

Aquí se aceptan cinco solicitudes adicionales instantáneamente antes de aplicar la limitación.

Esta técnica suaviza los picos de tráfico y mantiene una experiencia de usuario consistente sin saturar los sistemas back-end.

38) ¿Cómo maneja NGINX entornos IPv6 y de doble pila?

NGINX es totalmente compatible con IPv6, tanto en la configuración de servidor como en la de subida. Ejemplo:

server {
    listen [::]:80 ipv6only=on;
    server_name example.com;
}

La compatibilidad con doble pila (IPv4 + IPv6) se logra incluyendo ambos:

listen 80;
listen [::]:80;

La compatibilidad con IPv6 garantiza una accesibilidad más amplia, especialmente para clientes móviles e internacionales, y es fundamental para el cumplimiento de los estándares modernos de Internet.

39) ¿Cómo se configuran sesiones persistentes en el equilibrio de carga de NGINX?

Las sesiones persistentes garantizan que las solicitudes del mismo cliente siempre se dirijan al mismo servidor back-end.

  1. El uso de ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. Galleta adhesiva NGINX Plus:
    Persistencia de sesión avanzada con cookies configurables.

Las sesiones persistentes son vitales para aplicaciones con estado, como paneles de usuario o carritos de compra, ya que garantizan la consistencia de los datos de la sesión sin almacenamiento compartido.

40) ¿Cuáles son los principales niveles de registro en NGINX y en qué se diferencian?

NGINX admite niveles de registro jerárquicos para controlar el nivel de detalle en el registro de errores.

Nivel Descripción
debug Información detallada para la resolución de problemas (muy detallada)
info Información general sobre el tiempo de ejecución
notice Eventos significativos pero no críticos
warn Posibles problemas o configuraciones erróneas
error Operaerrores nacionales que requieren atención
crit, alert, emerg Fallos críticos y alertas del sistema

Configuración de ejemplo:

error_log /var/log/nginx/error.log warn;

Ajustar los niveles de registro según el entorno (depuración en ensayo, advertencia en producción) ayuda a mantener un equilibrio entre la visibilidad y el rendimiento.

41) ¿Cómo se compara el rendimiento de NGINX?

La evaluación comparativa de NGINX implica medir el rendimiento, la latencia y la concurrencia para identificar cuellos de botella en la configuración. Las herramientas comunes incluyen:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • Las pruebas solicitan volumen y concurrencia.
  • trabajo: Proporciona percentiles de latencia detallados y tasas de solicitud.
  • asedio / httperf: Simula la carga de tráfico del mundo real.
  • Grafana + Prometeo: Supervisa métricas de rendimiento en vivo.

El benchmarking debe medir parámetros como requests per second (RPS), time per request y error rate.

Variables de ajuste como worker_processes, worker_connections y keepalive_timeout mejora significativamente el rendimiento observado.

42) ¿Cómo puede NGINX integrarse con los pipelines CI/CD?

NGINX se integra perfectamente con CI / CD Para la implementación automatizada, las pruebas y la gestión de la configuración. Los enfoques comunes incluyen:

  • Infraestructura como Código (IaC): Administre configuraciones con gráficos de Ansible, Terraform o Helm.
  • Contenedores Docker: Cree e implemente imágenes NGINX utilizando herramientas CI (Jenkins, GitLab CI o GitHub Actions).
  • Pruebas automatizadas: Validar configuraciones usando nginx -t en etapas de tubería.
  • Azul-Verde / Canary Automatización de la implementación: Actualice los servidores ascendentes de forma dinámica durante la implementación.

Ejemplo de fragmento de código de GitLab CI:

deploy:
  script:
    - nginx -t
    - systemctl reload nginx

La implementación automatizada garantiza implementaciones de NGINX consistentes, confiables y controladas por versiones.

43) Explique la función del controlador de ingreso NGINX en Kubernetes.

El Controlador de entrada NGINX Gestiona el tráfico entrante a los servicios de Kubernetes. Traduce dinámicamente los recursos de Kubernetes Ingress a configuraciones NGINX.

Funciones clave:

  • Enruta las solicitudes HTTP/S al servicio correcto.
  • Proporciona terminación SSL, limitación de velocidad y reescritura de URL.
  • Admite equilibrio de carga entre pods.
  • Permite realizar anotaciones para un control detallado (por ejemplo, rewrite-target, proxy-body-size).

Ejemplo de YAML de Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Esta arquitectura desacopla la lógica de enrutamiento del tráfico de las implementaciones de contenedores para lograr una escalabilidad flexible.

44) ¿Cómo maneja NGINX HTTP/2 y cuáles son sus ventajas?

NGINX es totalmente compatible HTTP / 2, el sucesor de HTTP/1.1, que mejora la eficiencia a través de la multiplexación y la compresión de encabezados.

Para habilitar HTTP/2:

server {
    listen 443 ssl http2;
    ...
}

Ventajas:

Característica Descripción
Multiplexación Múltiples solicitudes por conexión TCP
Compresión de encabezado (HPACK) Reduce el uso de ancho de banda
Empuje el servidor Envía activos de forma preventiva a los clientes
TLS más rápido Apretones de manos seguros y optimizados

HTTP/2 reduce drásticamente la latencia y los tiempos de carga de las páginas, especialmente para aplicaciones web modernas con numerosos activos.

45) ¿Cuál es la diferencia entre keepalive upstream y reutilización de conexión en NGINX?

Keepalive ascendente Mantiene conexiones persistentes con los servidores backend, lo que reduce la sobrecarga del protocolo de enlace TCP. Ejemplo:

upstream backend {
    server app1.example.com;
    keepalive 32;
}

Diferencia:

Aspecto Mantener viva Reutilización de conexiones
<b></b><b></b> Entre NGINX y upstream Entre NGINX y los clientes
Proposito Optimización de back-end Rendimiento del frontend
Configuration keepalive interior upstream keepalive_timeout in server bloquear

Ambas técnicas reducen la latencia pero sirven a diferentes capas de comunicación (lado del cliente vs. lado del servidor).

46) ¿Cómo puedes reconfigurar dinámicamente NGINX sin reiniciarlo?

Para aplicar nuevas configuraciones dinámicamente Sin tiempo de inactividad, utilizar el reload mecanismo:

nginx -t && nginx -s reload

Esto señala la proceso maestro para generar nuevos trabajadores con configuraciones actualizadas y al mismo tiempo apagar con elegancia los antiguos.

En NGINX Plus, se pueden realizar cambios a través de API (por ejemplo, agregar servidores ascendentes dinámicamente):

curl --request POST \
  --url http://localhost:8080/api/3/http/upstreams/backend/servers \
  --header 'Content-Type: application/json' \
  --data-raw '{"server":"10.0.0.12"}'

Esta capacidad admite implementaciones sin tiempo de inactividad en canales DevOps modernos.

47) ¿Cuáles son las diferencias clave entre el proxy inverso y el proxy directo en NGINX?

Aspecto Revproxy incorrecto Proxy de reenvío
Visibilidad del cliente Clientes que desconocen los servidores backend Los servidores desconocen la identidad del cliente
Uso primario Equilibrio de carga, almacenamiento en caché, terminación SSL Filtrado, anonimato, control de acceso
Caso de uso común Distribución del tráfico web Navegación saliente corporativa o segura
Soporte de NGINX Nativo y ampliamente utilizado Requiere configuración personalizada

Ejemplo (proxy de reenvío):

location / {
    proxy_pass $scheme://$http_host$request_uri;
    proxy_set_header Host $http_host;
}

RevEl proxy inverso sigue siendo el caso de uso dominante, especialmente para puertas de enlace de API y arquitecturas de microservicios.

48) ¿Cómo se puede utilizar NGINX para limitar y estrangular la velocidad de la API?

La limitación de velocidad protege las API del abuso y garantiza un uso justo. Ejemplo de configuración:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

Mecanismo:

  • limit_req_zone:Define la zona y la velocidad de memoria compartida.
  • burst:Permite picos temporales limitados.
  • nodelay:Hace cumplir los límites inmediatamente.

Esta configuración garantiza que cada IP de cliente pueda realizar solo 10 solicitudes por segundo y permite ráfagas cortas.

49) ¿Cuáles son los casos de uso típicos de NGINX en entornos DevOps empresariales?

En los ecosistemas DevOps empresariales, NGINX cumple múltiples funciones críticas:

  1. Servidor web: Entrega de contenido estático de alto rendimiento.
  2. RevProxy erse / Balanceador de carga: Gestión del tráfico a través de microservicios.
  3. Puerta de enlace API: Autenticación, enrutamiento y limitación.
  4. Controlador de ingreso: Para clústeres de Kubernetes.
  5. Capa de almacenamiento en caché de contenido: Reduce la carga del backend.
  6. Punto final de terminación SSL: Gestión centralizada de certificados.
  7. Punto final de monitoreo: Integración de métricas y observabilidad.

Su tamaño liviano y diseño modular hacen que NGINX sea indispensable en procesos de CI/CD, nubes híbridas y clústeres de alta disponibilidad.

50) ¿Cuáles son las principales diferencias entre NGINX y HAProxy para el equilibrio de carga?

Ambos son balanceadores de carga de alto rendimiento, pero difieren en enfoque y arquitectura:

Característica Nginx HAProxy
Rol primario Servidor web + proxy inverso Balanceador de carga TCP/HTTP dedicado
Simplicidad de configuración Más fácil para cargas de trabajo basadas en la web Control complejo pero más granular
Soporte de capa L7 (HTTP), L4 parcial L4 y L7 completos
Reconfiguración dinámica Limitado (código abierto) Actualizaciones de tiempo de ejecución nativo
Rendimiento Excelente para cargas de trabajo mixtas Superior para el equilibrio de carga sin procesar
Características adicionales Almacenamiento en caché, compresión y contenido estático Controles de salud, tablas de palos

Las empresas a menudo combinan NGINX (interfaz) y HAProxy (backend) para un enrutamiento y escalabilidad óptimos.

🔍 Las mejores preguntas de entrevista de NGINX con situaciones reales y respuestas estratégicas

1) ¿Qué es NGINX y por qué se utiliza comúnmente en entornos de producción?

Se espera del candidato: El entrevistador quiere evaluar su conocimiento básico de NGINX y su comprensión de su valor práctico en sistemas del mundo real.

Respuesta de ejemplo: NGINX es un servidor web y proxy inverso de alto rendimiento conocido por su arquitectura basada en eventos. Se utiliza comúnmente en entornos de producción porque puede gestionar un gran número de conexiones simultáneas de forma eficiente y consume menos recursos del sistema que los servidores web tradicionales.

2) ¿Puedes explicar la diferencia entre NGINX y Apache?

Se espera del candidato: El entrevistador está evaluando su capacidad para comparar tecnologías y elegir la herramienta adecuada en función de los casos de uso.

Respuesta de ejemplo: NGINX utiliza una arquitectura asíncrona y sin bloqueos, lo que la hace más eficiente para gestionar tráfico intenso y contenido estático. Apache utiliza un modelo basado en procesos que puede ser más flexible para configuraciones dinámicas, pero puede consumir más recursos con una carga elevada.

3) ¿Cómo actúa NGINX como proxy inverso?

Se espera del candidato: El entrevistador quiere confirmar su comprensión de los conceptos de proxy inverso y cómo NGINX encaja en las arquitecturas modernas.

Respuesta de ejemplo: NGINX actúa como un proxy inverso: recibe las solicitudes de los clientes y las reenvía a los servidores backend. Posteriormente, devuelve las respuestas del servidor al cliente, lo que mejora la seguridad, la distribución de la carga y el rendimiento general.

4) Describe una situación en la que utilizaste NGINX para equilibrar la carga.

Se espera del candidato: El entrevistador busca experiencia práctica y su capacidad para aplicar las funciones de NGINX en escenarios reales.

Respuesta de ejemplo: En mi puesto anterior, configuré NGINX para distribuir el tráfico entre múltiples servidores de aplicaciones mediante algoritmos de round-robin y de mínimas conexiones. Este enfoque mejoró la disponibilidad de las aplicaciones y evitó que un solo servidor se convirtiera en un cuello de botella.

5) ¿Cómo se maneja la configuración de SSL y HTTPS en NGINX?

Se espera del candidato: El entrevistador quiere evaluar su comprensión de las mejores prácticas de seguridad y la gestión de la configuración.

Respuesta de ejemplo: En un puesto anterior, configuré SSL instalando certificados, habilitando escuchas HTTPS y aplicando conjuntos de cifrado robustos. También implementé la redirección de HTTP a HTTPS para garantizar la comunicación segura en todos los puntos finales.

6) ¿Qué pasos tomarías para solucionar un error 502 Bad Gateway en NGINX?

Se espera del candidato: El entrevistador está probando sus habilidades para resolver problemas y su metodología de solución de problemas.

Respuesta de ejemplo: Comenzaría por revisar los registros de errores de NGINX para identificar problemas de conectividad del backend. Luego, verificaría que los servidores ascendentes estén funcionando, confirmaría que la configuración del proxy sea correcta y que los tiempos de espera estén configurados correctamente.

7) ¿Cómo optimizar el rendimiento de NGINX para aplicaciones de alto tráfico?

Se espera del candidato: El entrevistador quiere saber cómo aborda el ajuste del rendimiento y la escalabilidad.

Respuesta de ejemplo: En mi trabajo anterior, optimicé NGINX habilitando la compresión gzip, optimizando los procesos de trabajo y configurando el almacenamiento en caché para contenido estático. Estos cambios redujeron significativamente los tiempos de respuesta y la carga del servidor.

8) ¿Puedes explicar cómo NGINX maneja el contenido estático versus el dinámico?

Se espera del candidato: El entrevistador está evaluando su comprensión del manejo de solicitudes y la optimización del rendimiento.

Respuesta de ejemplo: NGINX sirve contenido estático directamente y de forma muy eficiente desde el sistema de archivos. Para el contenido dinámico, reenvía las solicitudes a servidores de aplicaciones o servicios como PHP-FPM, lo que permite que cada componente se centre en lo que mejor sabe hacer.

9) ¿Cómo gestionar y probar de forma segura los cambios de configuración de NGINX?

Se espera del candidato: El entrevistador quiere comprender su enfoque en la confiabilidad y la reducción de riesgos.

Respuesta de ejemplo: Valido los cambios de configuración con el comando de prueba de configuración de NGINX antes de recargar el servicio. También aplico los cambios durante las ventanas de mantenimiento y superviso los registros de cerca después de la implementación.

10) Describe una ocasión en la que tuviste que resolver rápidamente una interrupción relacionada con NGINX.

Se espera del candidato: El entrevistador está evaluando su capacidad para trabajar bajo presión y comunicarse eficazmente durante los incidentes.

Respuesta de ejemplo: En mi anterior puesto, se produjo una interrupción debido a un servicio ascendente mal configurado. Identifiqué rápidamente el problema mediante los registros, revertí la configuración y comuniqué las actualizaciones de estado a las partes interesadas hasta que se restableció el servicio por completo.

Resumir este post con: