Nginx on javierin.com

Guía Definitiva de Nginx Hardening 2025: Cómo Securizar tu Servidor Web

Thu, 06 Nov 2025 15:57:09 +0000

¿Usas Nginx? ¡Genial! Has elegido uno de los servidores web más rápidos, eficientes y versátiles del planeta. Es una máquina bien engrasada que puede servir contenido a velocidades de vértigo. Pero, aquí viene el "pero"... una instalación por defecto de Nginx es como tener un cochazo deportivo con las puertas abiertas y las llaves puestas. Funciona, sí, pero no es precisamente seguro. En pleno 2025, con las amenazas a la vuelta de la esquina, no basta con instalar y olvidar. Necesitas tomarte en serio la seguridad nginx. Este proceso, conocido en el mundillo como hardening, consiste en aplicar una serie de configuraciones y buenas prácticas para reducir la superficie de ataque y hacerle la vida imposible a los malos. En esta guía, vamos a arremangarnos y a ver, paso a paso, cómo puedes securizar Nginx de forma robusta. Olvídate de los consejos básicos y vamos a meternos en faena de verdad.

Primeros Pasos: La Base de tu Seguridad Nginx

Antes de entrar en configuraciones complejas, empecemos por lo fundamental. Estos son los cimientos sobre los que construiremos nuestra fortaleza digital.

Mantén Nginx Siempre Actualizado

Suena obvio, ¿verdad? Pues te sorprendería la cantidad de servidores que corren versiones obsoletas y vulnerables. Los desarrolladores de Nginx publican parches de seguridad constantemente. Asegurarte de tener la última versión estable es la medida de seguridad más simple y efectiva que puedes tomar.

#Para sistemas basados en Debian/Ubuntu

sudo apt update
sudo apt upgrade nginx

#Para sistemas basados en CentOS/RHEL

sudo dnf update nginx

Configura tu sistema para que te notifique de las actualizaciones o, si tu política de empresa lo permite, automatízalas.

Oculta la Versión de Nginx

Un atacante que sabe la versión exacta de tu Nginx puede buscar vulnerabilidades específicas para esa versión. No se lo pongas tan fácil. Es un pequeño paso de "seguridad por oscuridad", pero todo suma. Abre tu fichero de configuración principal nginx.conf:

#/etc/nginx/nginx.conf

http {
...
server_tokens off;
...
}

Con esta simple línea, Nginx dejará de mostrar su número de versión en las cabeceras de respuesta y en las páginas de error. En lugar de Server: nginx/1.26.1, solo mostrará Server: nginx. ¡Menos información para el enemigo!

Fortaleciendo tu Configuración: El Verdadero Nginx Hardening

Aquí es donde la magia ocurre. Vamos a tocar la configuración para blindar el servidor contra los ataques más comunes.

Configuración SSL/TLS a Prueba de Balas

En 2025, tener un sitio sin HTTPS es impensable. Pero no vale con activar cualquier certificado. La clave está en una configuración SSL/TLS robusta. 1. Utiliza Protocolos Modernos: Desactiva protocolos antiguos y vulnerables como SSLv3, TLS 1.0 y TLS 1.1. Quédate solo con TLS 1.2 y, sobre todo, TLS 1.3. 2. Elige Cifrados Fuertes: No todos los algoritmos de cifrado son iguales. Debes dar prioridad a los más modernos y seguros. 3. Implementa HSTS (HTTP Strict Transport Security): Esta cabecera le dice al navegador que solo debe comunicarse con tu servidor a través de HTTPS, eliminando la posibilidad de ataques man-in-the-middle en conexiones futuras. Una configuración de servidor para SSL podría parecerse a esto:

nginx
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

ssl_certificate /ruta/a/tu/certificado_fullchain.pem;
ssl_certificate_key /ruta/a/tu/clave_privada.pem;

# Protocolos modernos
ssl_protocols TLSv1.2 TLSv1.3;

# Cifrados fuertes
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

# HSTS (¡Cuidado! Empieza con un max-age bajo y súbelo cuando estés seguro)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# OCSP Stapling (mejora el rendimiento de la validación del certificado)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /ruta/a/tu/certificado_chain.pem;

...

}

No tienes que memorizar todo esto. Una herramienta fantástica para generar configuraciones seguras es el Generador de Configuración SSL de Mozilla. Simplemente elige Nginx, tu versión y el nivel de compatibilidad que necesitas, y te dará una configuración lista para usar.

Protege tu Servidor contra Ataques Comunes

Además del SSL, hay varias cabeceras HTTP que añaden capas extra de seguridad nginx.

Contra el Clickjacking: Evita que tu sitio sea cargado dentro de un <iframe> en otra web. add_header X-Frame-Options "SAMEORIGIN" always;
Contra el MIME-Sniffing: Impide que el navegador intente "adivinar" el tipo de contenido de un fichero, lo que podría llevar a la ejecución de código malicioso. add_header X-Content-Type-Options "nosiff" always;
Contra el Cross-Site Scripting (XSS): Aunque los navegadores modernos ya no le hacen tanto caso, no está de más para dar soporte a versiones antiguas. add_header X-XSS-Protection "1; mode=block" always;
Limita los Buffers: Peticiones con cuerpos o cabeceras enormes pueden ser un vector para ataques de denegación de servicio o buffer overflow. Establece límites razonables. client_body_buffer_size 16k; client_header_buffer_size 1k;
Limita las Peticiones (Rate Limiting): Esencial para mitigar ataques de fuerza bruta (por ejemplo, contra un panel de login) o DDoS a nivel de aplicación. limitreqzone $binaryremoteaddr zone=login:10m rate=1r/s; # Si lo pones en nginx.conf
En el server block o location que quieres proteger

server {
...
location /login.php {
limit_req zone=login burst=5 nodelay;
...
}
}

Este ejemplo limita a los usuarios a una petición por segundo a la página de login, con un pequeño búfer de 5 peticiones. El nginx hardening pasa, sí o sí, por controlar el ritmo al que te hablan.

Securizar Nginx con PHP-FPM

Si usas PHP (¿quién no?), lo más probable es que lo hagas a través de PHP-FPM. Una mala configuración aquí es una puerta de entrada directa a tu servidor.

Aísla tus Sitios con Pools Separados

No ejecutes todos tus sitios web bajo el mismo usuario de PHP-FPM (www-data por defecto). Si un atacante compromete uno de tus sitios, tendrá acceso a todos los demás. La mejor práctica es crear un pool de PHP-FPM por cada sitio web, cada uno ejecutándose con su propio usuario y grupo. De esta forma, un incidente en sitioA.com no afectará a sitioB.com. Es un poco más de trabajo de configuración, pero la ganancia en seguridad es brutal.

Parámetros Clave de FastCGI

Dentro de tu bloque location ~ \.php$, hay que tener cuidado. 1. Evita la Ejecución de Ficheros Fantasma: Una vulnerabilidad clásica permitía ejecutar código si subías un fichero llamado, por ejemplo, imagen.jpg/fichero.php. Para prevenirlo, asegúrate de tener cgi.fix_pathinfo=0 en tu php.ini y utiliza try_files en tu configuración de Nginx.

nginx
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php8.3-fpm-misitio.sock; # Usando el socket del pool específico
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

El try_files $uri =404; es crucial. Le dice a Nginx: "si el fichero .php no existe físicamente en el disco, devuelve un error 404 en lugar de pasárselo a PHP". 2. No Confíes en las Extensiones de Fichero: Limita la ejecución de PHP solo a los scripts que tú quieres. Por ejemplo, si tienes una carpeta /uploads donde los usuarios suben ficheros, deshabilita la ejecución de PHP dentro de ella.

location /uploads/ {
    location ~ \.php$ {
        return 403; # Prohibido
    }
    # Otras reglas para los ficheros de /uploads
}

Nginx como Proxy Inverso: Doble Deber, Doble Seguridad

Usar Nginx como proxy inverso (delante de una aplicación Node.js, Python, Java o incluso otro Apache) es súper común. Aquí, el objetivo es securizar Nginx para que actúe como un escudo protector.

Oculta la Identidad de tus Servidores Backend

Tu servidor de aplicación backend (el que corre tu app) no debería hablar directamente con internet. Nginx es su único interlocutor. Asegúrate de que el backend no revela información sensible. Usa proxy_hide_header para limpiar cabeceras que delaten al backend, como X-Powered-By o Server.

location /api/ {
proxypass http://localhost:3000; # Tu app Node.js, por ejemplo
proxysetheader Host $host;
proxysetheader X-Real-IP $remoteaddr;
proxysetheader X-Forwarded-For $proxyaddxforwardedfor;

# Ocultamos información del backend
proxy_hide_header X-Powered-By;
proxy_hide_header Server;


}

Bloquea el Acceso Directo al Backend

Tu aplicación backend solo debería aceptar conexiones desde Nginx. La forma más sencilla es hacer que escuche solo en localhost (127.0.0.1). Si está en otra máquina, usa un firewall (como ufw o firewalld) para bloquear el acceso público a su puerto, permitiendo únicamente las conexiones desde la IP del servidor Nginx.

Herramientas y Monitorización: Tus Ojos en el Servidor

Un buen nginx hardening no termina con la configuración. Necesitas vigilar.

Fail2ban: Esta herramienta es tu mejor amiga. Monitoriza los logs de Nginx y banea automáticamente las IPs que muestran un comportamiento malicioso (intentos de login fallidos, búsqueda masiva de ficheros, etc.). Configurar fail2ban para que vigile nginx-http-auth o nginx-badbots es un must.
Web Application Firewall (WAF): Para una capa extra de protección, puedes usar un WAF como ModSecurity. El conector oficial de Nginx te permite integrar este potente cortafuegos de aplicaciones que puede detectar y bloquear ataques complejos como inyecciones SQL o XSS en tiempo real. Puedes encontrar el proyecto en el repositorio de ModSecurity-nginx en GitHub.
Logs, Logs y más Logs: Revisa tus logs de acceso y error periódicamente. Son una mina de oro para detectar patrones de ataque y problemas de configuración.

Conclusión: Un Proceso Continuo

¡Y ya está! Has pasado de una instalación básica a una configuración de Nginx robusta y preparada para lo que venga. Recuerda que la seguridad nginx no es algo que haces una vez y te olvidas. Es un proceso continuo de actualización, monitorización y ajuste. Las amenazas evolucionan, y tu defensa también debe hacerlo. Pero con esta guía como punto de partida, has dado un paso de gigante. Ahora tu Nginx no solo es endiabladamente rápido, sino que también es una auténtica fortaleza digital. ¡A dormir un poco más tranquilo Este articulo puede contener enlaces de afiliación

Preguntas Frecuentes

Q: Son muchas configuraciones. Si tuviera que empezar por algo, ¿cuáles son las 3 medidas de seguridad más críticas e indispensables para cualquier servidor Nginx?

Guía Definitiva 2025: Cómo Optimizar PHP-FPM y PHP.ini para Volar

Wed, 05 Nov 2025 00:03:00 +0000

¿Sientes que tu web podría ir más rápido? ¿Has instalado el último tema, optimizado las imágenes y puesto un CDN, pero la cosa sigue sin volar? A veces, el verdadero tesoro del rendimiento no está en el frontend, sino en las tripas del servidor. Y ahí, amigo mío, es donde brilla PHP-FPM.

Si usas un stack moderno con Nginx, lo más seguro es que estés usando PHP-FPM para gestionar las peticiones PHP. Pero, ¿lo tienes bien configurado? Por defecto, viene con unos valores bastante conservadores que no le sacan todo el jugo a tu máquina.

Nginx: "listen ... http2" deprecated - Solución y Guía Completa

Mon, 01 Sep 2025 05:18:37 +0000

¿Tu Nginx se queja de «listen http2»? No te preocupes, tiene fácil solución

Si eres de los que gestiona servidores web, es muy probable que, tras una actualización reciente de Nginx, te hayas topado con un aviso un tanto molesto en tus logs o al reiniciar el servicio. Un mensaje que dice algo como: nginx: [warn] the "http2" parameter of the "listen" directive is deprecated, use the "http2" directive instead.

Permission denied en php5-fpm.sock

Mon, 24 Oct 2016 13:11:59 +0000

Hace un tiempo tuve que actualizar versiones de php5 y nginx en una serie de servidores y según los iba actualizando empezaban a aparecer errores 502 Bad Gateway en los servidores Nginx. Por lo general los errores 502 Bad Gateway responden a un intento de conectar a un backend que no está levantado o escuchando en donde le decimos.

Viendo que esto ocurría de repente, me fijé en que nginx estaba soltando los siguientes errores de permission denied en php5-fpm.sock:

Resolver Error 504 Gateway Timeout en Nginx: Guía Definitiva 2025

Mon, 24 Oct 2016 10:54:12 +0000

Seguro que te suena la situación: estás trabajando en tu web, todo va como la seda, y de repente, ¡zas! Pantalla en blanco y un mensaje que te hiela la sangre: 504 Gateway Timeout. Si has llegado hasta aquí, es probable que tu servidor web sea Nginx y que este error te esté quitando el sueño. ¡Que no cunda el pánico! En este artículo, actualizado para 2025, vamos a desglosar qué significa este error, por qué aparece y, lo más importante, cómo puedes solucionarlo. Y te lo explicaré de una forma sencilla, para que no necesites ser un administrador de sistemas con 20 años de experiencia para entenderlo. ¡Vamos al lío!

¿Qué es exactamente un error 504 Gateway Timeout?

Imagina que Nginx es el camarero de un restaurante muy eficiente. Tú, el cliente, le pides un plato (accedes a una URL). El camarero (Nginx) va a la cocina (el backend de tu aplicación, como PHP-FPM, Node.js, Python...) y le pasa la comanda. El problema viene cuando la cocina tarda demasiado en preparar el plato. El camarero tiene una paciencia limitada; no puede esperar eternamente. Si la cocina no saca el plato a tiempo, el camarero vuelve a tu mesa y te dice: "Lo siento, ha habido un problema de tiempo de espera en la cocina". Eso es, en esencia, un error 504 Gateway Timeout. Nginx, actuando como un gateway o proxy inverso, ha esperado una respuesta del proceso que está detrás (el backend), pero este no ha respondido en el tiempo estipulado. Es importante entender que el problema no es de Nginx en sí mismo, sino de la comunicación con lo que hay detrás o del propio backend que está sobrecargado o es demasiado lento.

Causas más comunes del dichoso error 504

Antes de tocar nada, es fundamental entender por qué puede estar pasando esto. Las causas más habituales son:

Scripts que tardan una eternidad: Tienes un proceso en tu aplicación (un script PHP, por ejemplo) que realiza una tarea muy pesada. Puede ser una consulta a la base de datos muy compleja, la importación de un archivo enorme, la generación de un informe o la comunicación con una API externa que está lenta.
El backend está sobrecargado o "muerto": El servicio que ejecuta tu aplicación (normalmente PHP-FPM si usas WordPress, Laravel, etc.) está saturado. Puede que no tenga suficientes "trabajadores" (workers) para atender todas las peticiones o que el servidor se haya quedado sin CPU o memoria RAM.
La configuración de timeout de Nginx es demasiado estricta: A veces, el camarero es simplemente muy impaciente. Nginx tiene unos tiempos de espera por defecto que, para ciertas tareas, pueden ser demasiado cortos.
Problemas de red o firewall: Si Nginx y tu aplicación están en servidores diferentes, un firewall podría estar bloqueando la conexión o puede haber problemas de red entre ellos.

La guía paso a paso para Resolver Error 504 Gateway Timeout en Nginx

Ahora que ya tenemos una idea de las posibles causas, vamos a la acción. Sigue estos pasos de forma ordenada para resolver el error 504 Gateway Timeout en Nginx.

Paso 1: Aumentar los valores de timeout en Nginx

Esta es la solución más rápida y común. Vamos a darle un poco más de paciencia a nuestro "camarero". Para ello, necesitas editar tu fichero de configuración de Nginx. Este suele estar en /etc/nginx/nginx.conf o en un fichero específico para tu sitio dentro de /etc/nginx/sites-available/. Busca el bloque http o, si es específico para un sitio, el bloque server o location. Añade o modifica las siguientes directivas: ```nginx http { # ... otras configuraciones ...

proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;

} ``` ¿Qué significa cada una?

proxy_..._timeout: Se usan cuando Nginx actúa como proxy inverso para otro servidor web (como Apache) o una aplicación (Node.js, Python...). proxy_read_timeout es la más importante aquí, ya que define cuánto tiempo esperará Nginx a que el backend envíe una respuesta. Puedes encontrar más detalles en la documentación oficial de Nginx sobre el módulo proxy.
fastcgi_..._timeout: Son cruciales si usas PHP-FPM. fastcgi_read_timeout es el equivalente a proxy_read_timeout pero para FastCGI, el protocolo que Nginx usa para hablar con PHP.

He puesto 600s (600 segundos o 10 minutos) como un valor alto para asegurarnos de que el problema no viene de aquí. Puedes ajustarlo a un valor más razonable una vez soluciones el problema de fondo. Importante: Después de guardar los cambios, no te olvides de recargar la configuración de Nginx para que los aplique:

bash
sudo systemctl reload nginx

Paso 2: Ajustar la configuración de PHP (PHP-FPM)

Si has aumentado el tiempo de espera de Nginx pero el error persiste, es muy probable que el problema esté en la "cocina". Aunque Nginx espere 10 minutos, si PHP tiene configurado un límite de ejecución de 30 segundos, el script morirá mucho antes y Nginx recibirá una conexión cerrada, lo que puede derivar en un 504. Hay dos sitios principales donde mirar:

El fichero php.ini: Busca la directiva max_execution_time. Este valor define el tiempo máximo en segundos que un script puede tardar en ejecutarse.
- Localiza tu php.ini (la ubicación varía, pero puedes usar php --ini para encontrarla).
- Aumenta el valor: max_execution_time = 300 (5 minutos).
- Puedes consultar la documentación oficial de PHP sobre esta directiva para más información.
La configuración del pool de PHP-FPM: A menudo, esta configuración anula lo que ponga en php.ini. El fichero suele estar en /etc/php/[tu_version]/fpm/pool.d/www.conf. Busca la directiva request_terminate_timeout.
- Si está definida y tiene un valor bajo, auméntala. Este valor indica el tiempo tras el cual se da por finalizada una petición. Si pones 0, se desactiva el límite y se usará el max_execution_time de php.ini.
- request_terminate_timeout = 300

Después de cambiar cualquiera de estos valores, recuerda reiniciar el servicio de PHP-FPM:

bash
sudo systemctl restart php8.3-fpm # Cambia "8.3" por tu versión de PHP

Paso 3: Optimizar es la verdadera solución a largo plazo

Aumentar los timeouts es como poner un parche. Funciona, pero si tus scripts son lentos, el problema de fondo sigue ahí. Tu web será lenta para los usuarios y consumirá más recursos del servidor. La verdadera solución para resolver el error 504 Gateway Timeout en Nginx de forma definitiva es optimizar.

Optimiza las consultas a la base de datos: Una consulta lenta es una de las causas más frecuentes. Usa herramientas como EXPLAIN en SQL para analizar tus queries y asegúrate de que estás usando índices en las columnas por las que buscas o filtras.
Utiliza caché: Si una página genera contenido que no cambia a menudo, ¿por qué generarlo cada vez? Usa sistemas de caché (Redis, Memcached, o incluso plugins de caché para WordPress) para servir una versión estática y ultrarrápida.
Mueve las tareas pesadas a segundo plano: Si un usuario solicita una acción que tarda mucho (ej: exportar un informe de ventas de todo el año), no le hagas esperar. Utiliza colas de trabajos (background jobs). La petición del usuario simplemente añade la tarea a una cola, y un proceso en segundo plano la ejecuta. Cuando esté lista, se le puede notificar al usuario. Esto libera al proceso principal y mejora drásticamente la experiencia de usuario.

Paso 4: Revisa los recursos del servidor y los logs

Si todo lo demás falla, es hora de investigar más a fondo.

Revisa el consumo de CPU y RAM: Usa comandos como top o htop en tu terminal. Si ves que la CPU está al 100% o que la memoria RAM está casi agotada, es probable que tu servidor no tenga suficientes recursos. Quizás sea el momento de optimizar más o de ampliar tu plan de hosting.
¡Mira los logs!: Los archivos de registro son tus mejores amigos.
- Log de errores de Nginx: /var/log/nginx/error.log
- Log de errores de PHP-FPM: La ubicación varía, pero suele estar en /var/log/php8.3-fpm.log (cambia la versión).
- Busca en los logs mensajes que coincidan con la hora en que se produjo el error 504. A menudo encontrarás pistas muy valiosas, como "PHP-FPM process timed out" o "upstream timed out".

Conclusión: Mantén la calma y sigue los pasos

El error 504 Gateway Timeout puede parecer intimidante, pero como has visto, casi siempre se reduce a un desajuste de tiempos de espera o a un cuello de botella en el rendimiento de tu aplicación. El enfoque correcto es ir de lo más sencillo a lo más complejo. Empieza aumentando los timeouts en Nginx y PHP-FPM para ver si eso soluciona el problema de inmediato. Si lo hace, ¡genial! Pero no te quedes ahí. Investiga qué proceso está tardando tanto y optimízalo. Esa es la clave para tener una web robusta, rápida y libre de errores. Así que la próxima vez que te encuentres con este error, respira hondo, vuelve a esta guía y empieza a investigar. ¡Seguro que das con la tecla

Sacar estadisticas de acceso por user agent con logs de nginx

Mon, 11 Nov 2013 10:04:25 +0000

Seguro que a alguien le puede ser util sacar estadisticas de acceso por user agent en nginx para poder clasificar los dispositivos que utilizan sus visitantes.
Aunque pueda ser absurdo, saber el user agent de tus visitantes a partir de los logs de nginx te da una visibilidad de que tipo de gente visita tu web, si puedes necesitar una versión web de tu sitio web, etc.

cat nombre-vhost-access.log |awk -F"" "" 'NF > 1 { print $(NF - 1); }' |sort |uniq -c |sort -n

Ten presente que si usas un formato personalizado de logs, los números de columna se pueden ver desplazados. En ese caso, para obtener estadisticas de acceso por user agent en nginx deberás adaptar el comando al formato de tus logs.

Visualizar cabeceras HTTP de un servidor remoto

Sat, 08 Jun 2013 13:11:16 +0000

Hoy me ha llamado un amigo preguntándome como saber si una petición que estaba haciendo a un servidor era correcta o no.

Lo primero en lo que pensé fue en usar curl, pero luego me quedé pensando en otras formas de hacerlo, desde wget hasta netcat. Sin ir a opciones raras, aquí van 3 formas de obtener las cabeceras HTTP de respuesta:

Mirar cabeceras HTTP con Curl (La primera porque es la que suelo usar) Incluyo la opción de seguir las redirecciones indicadas por el servidor.

Error en NginX "could not build the server_names_hash, you should increase server_names_hash_bucket_size"

Tue, 28 Sep 2010 12:10:54 +0000

A veces puede ocurrir cuando ponemos muchos servidores en un NginX que nos saque este error:

[emerg] 12299#0: could not build the server_names_hash, you should increase server_names_hash_bucket_size: 128
[emerg] 12299#0: the configuration file /etc/nginx/nginx.conf test failed

Este parametro ha de ser siempre un multiplo del tamaño de cache del procesador (core). El propio error te indica cuanto poner. En mi caso yo puse 128. Esta variable va en /etc/nginx/nginx.conf

Balanceo de carga usando NginX

Tue, 28 Sep 2010 11:56:50 +0000

Nginx permite balancear la carga entre distintos servidores backend cuando esta funcionando en modo proxy. Aqui pongo una configuracion de proxy para nginx que pueden ser utiles para tener a nginx como balanceador:

upstream servidores  {
  server 127.0.0.1 weight=5 max_fails=2 fail_timeout=10s;
  server 127.0.0.1:80 weight=5 max_fails=2 fail_timeout=10s;
  server localhost:80 weight=5 max_fails=2 fail_timeout=10s;
}

server {
  server_name www.tudominio.tld otrohost.tudominio.tld otrodominio.tld;
  location / {
    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_pass  http://servidores;
  }
}

El parametro de configuracion Weight, que por omision es «1», indica cuantas peticiones seguidas se dirigiran a ese backend. Si es 5, pues mandará 5 a ese, luego 5 al siguiente, y asi.
El parametro fail_timeout indica el tiempo que esperara a enviar peticiones a un backend tras detectar un fallo y considerarlo caido.
El parametro max_fails indica cuantas veces ha de dar error el backend para marcarlo como caido.

Configuracion de Wordpress 3.0 para NginX

Tue, 28 Sep 2010 11:42:46 +0000

Aqui va una configuracion funcional para WordPress 3.0 para NginX. Aunque no lo tengo activado, tambien soporta el modulo MultiSite. aunque pueda aparecer cortado por ser lineas demasiado largas, con copiar y pegar funciona bien.

server{
    server_name dominio.tld;
    listen 127.0.0.1:80;
    client_max_body_size 32M;
    #on server block
    ##necessary if using a multi-site plugin
    server_name_in_redirect off;
    ##necessary if running Nginx behind a reverse-proxy
    port_in_redirect off;
    access_log /var/log/nginx/dominio.tld-access.log;
    error_log /var/log/nginx/dominio.tld-error.log;

    location / {
        root   /ruta/al/wordpress;
        index  index.html index.htm index.php;
        rewrite ^.*/files/(.*)$ /wp-includes/ms-files.php?file=$1 last;
        if (!-e $request_filename) {
            rewrite ^.+/?(/wp-.*) $1 last;
            rewrite ^.+/?(/.*.php)$ $1 last;
            rewrite ^(.+)$ /index.php?q=$1 last;
        }
    }

    location ~* ^.+.(html|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$
    {
        root /ruta/al/wordpress;
        rewrite ^/.*(/wp-.*/.*.(html|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js))$ $1 last;
        rewrite ^.*/files/(.*(html|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js))$/wp-includes/ms-files.php?file=$1 last;
        expires 30d;
        break;
    }

    location ~ wp-.*.php|wp-admin|.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index index.php;
        ###IMPORTANTE: NO PONER / antes de fastcgi_script_name
        fastcgi_param  SCRIPT_FILENAME  /ruta/al/wordpress$fastcgi_script_name;
    }
}

Este articulo puede contener enlaces de afiliación

Syntax Highlight de NginX para vim

Tue, 28 Sep 2010 11:34:11 +0000

He encontrado este fichero de configuracion con el que podemos tener syntax highlighting (como se dice esto en castellano????) para las configuraciones de NginX en vim:

mkdir -p ~/.vim/syntax/; cd ~/.vim/syntax/;
wget -O nginx.vim http://www.vim.org/scripts/download_script.php?src_id=12990
touch ~/.vim/filetype.vim
echo "au BufRead,BufNewFile /etc/nginx/* set ft=nginx" >> ~/.vim/filetype.vim

Y el resultado queda asi:

Instalar Nginx en ubuntu con soporte PHP5 (php5-fpm)

Mon, 27 Sep 2010 09:35:09 +0000

Hace no mucho hice el cambio de apache a Nginx en un servidor. La impresión general es del todo favorable. Aunque no era un servidor especialmente cargado, sí que en temas de memoria he podido apreciar que tengo mas espacio disponible para otras cosas.

Vamos por pasos. Lo primero, es ponerse el repositorio de Nginx. Tenemos un repositorio estable y otro de desarrollo.

Si queremos el repositorio de nginx estable:
sudo su - echo "deb http://ppa.launchpad.net/nginx/stable/ubuntu lucid main" >> /etc/apt/sources.list apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C300EE8C apt-get update apt-get install nginx