Cómo configurar Nginx como reverse proxy con HTTPS

Un reverse proxy es un servidor que se sitúa delante de una o varias aplicaciones y recibe en su nombre las peticiones de los usuarios, para luego reenviarlas internamente a la aplicación que corresponda y devolver la respuesta al usuario. La diferencia con un proxy directo o convencional es importante: un proxy directo actúa en representación del cliente, por ejemplo para que un conjunto de usuarios salga a internet a través de él, mientras que un reverse proxy actúa en representación del servidor, de modo que es él quien recibe el tráfico entrante y las aplicaciones quedan detrás, sin comunicarse directamente con el usuario. Este patrón, del que Nginx es el exponente más usado, aporta varias ventajas muy valiosas. En primer lugar, proporciona un punto de entrada único al sistema, un solo lugar donde gestionar los dominios, el cifrado y las reglas de acceso, lo que simplifica enormemente la administración. En segundo lugar, permite servir varias aplicaciones desde un mismo servidor, enrutando el tráfico según el dominio o la ruta solicitada, de manera que un mismo servidor puede atender por ejemplo una web principal, una interfaz de administración y una interfaz de programación, cada una gestionada por una aplicación distinta por detrás. En tercer lugar, centraliza el cifrado, ya que el reverse proxy puede encargarse de terminar las conexiones seguras y hablar por dentro con las aplicaciones sin que estas tengan que implementar el cifrado por sí mismas, lo que simplifica su desarrollo. Y en cuarto lugar, añade funciones propias de un servidor web maduro, como la compresión de las respuestas, la caché de contenidos estáticos, los límites de tamaño de las peticiones, la limitación de la tasa de peticiones o la adición de cabeceras de seguridad, todo ello sin necesidad de modificar el código de las aplicaciones. Por estas razones, poner un reverse proxy como Nginx delante de las aplicaciones es una práctica estándar en el despliegue de servicios web, ya que aporta orden, seguridad y flexibilidad.

La directiva de reenvío de Nginx, conocida como proxy pass, es el elemento central que convierte a Nginx en un reverse proxy, ya que indica hacia dónde debe reenviar Nginx las peticiones que recibe. Su funcionamiento es conceptualmente sencillo: dentro de un bloque de configuración que define cómo se atiende un determinado dominio y una determinada ruta, la directiva de reenvío especifica la dirección interna del servidor de aplicación al que hay que pasar la petición, típicamente la dirección local del propio servidor junto con el puerto en el que la aplicación está escuchando, por ejemplo un puerto interno no expuesto al exterior. De este modo, cuando un usuario accede al sitio, Nginx recibe la petición en el puerto público y, según las reglas de ubicación configuradas, la reenvía a la aplicación correspondiente en su puerto interno, recoge la respuesta de esa aplicación y se la devuelve al usuario, actuando como intermediario. Un aspecto fundamental para que esto funcione correctamente es acompañar la directiva de reenvío de una serie de cabeceras que Nginx debe establecer al reenviar la petición, ya que de lo contrario la aplicación recibiría información incompleta o engañosa sobre el origen de la petición. Entre esas cabeceras están la que transmite el nombre de dominio solicitado, las que transmiten la dirección real del usuario, dado que sin ellas la aplicación vería todas las peticiones como procedentes del propio servidor, y la que informa de si la conexión original del usuario fue cifrada, lo cual es clave para que la aplicación genere correctamente sus enlaces y gestione adecuadamente sus cookies. Omitir estas cabeceras es una fuente habitual de errores sutiles, como que la aplicación registre siempre la misma dirección de origen, genere enlaces sin cifrar o entre en bucles de redirección. Además, es una buena práctica imprescindible comprobar la sintaxis de la configuración antes de aplicarla, mediante el comando de prueba de Nginx, y recargar el servicio de forma que no se interrumpa, de modo que un error de configuración no deje el servidor sin servicio. Con la directiva de reenvío y las cabeceras adecuadas se consigue que la aplicación funcione correctamente detrás del reverse proxy.

La forma estándar y gratuita de conseguir un certificado para habilitar conexiones seguras en un sitio web es utilizar Let’s Encrypt, que es una autoridad de certificación sin ánimo de lucro que emite certificados de validación de dominio de forma gratuita y automatizada, junto con una herramienta cliente que gestiona todo el proceso, siendo la más popular la llamada Certbot. El procedimiento habitual sobre un servidor con Nginx es el siguiente. En primer lugar, es imprescindible cumplir un requisito previo: disponer de un nombre de dominio cuyo registro apunte a la dirección del servidor, y que el servidor sea accesible desde internet para que la autoridad pueda verificar que efectivamente controlas ese dominio. A continuación se instala la herramienta cliente junto con su complemento específico para Nginx. Después se ejecuta el comando de obtención del certificado indicando el dominio o dominios que se quieren proteger; la herramienta se comunica con la autoridad, demuestra automáticamente el control del dominio mediante un desafío, obtiene el certificado y, gracias al complemento de Nginx, modifica la configuración del servidor para servir el sitio de forma cifrada en el puerto correspondiente. Durante el proceso, la herramienta suele ofrecer configurar automáticamente la redirección del tráfico sin cifrar hacia la versión cifrada, opción que conviene aceptar para que ningún usuario navegue sin protección. Un punto crucial es que los certificados de Let’s Encrypt tienen una validez corta, de noventa días, por lo que la renovación automática no es opcional sino necesaria; afortunadamente, la herramienta cliente instala automáticamente una tarea programada que se encarga de renovar los certificados próximos a caducar sin intervención manual, y es muy recomendable verificar que esa renovación funcionará correctamente ejecutando una simulación de renovación. De este modo, con unos pocos pasos se obtiene un certificado válido y reconocido por los navegadores, sin coste, y con la garantía de que se renovará solo mientras el servidor y el dominio sigan operativos. Existen otras autoridades y métodos, pero Let’s Encrypt con su herramienta cliente es hoy la opción más sencilla y extendida para cifrar un sitio sin gastar dinero.

Los certificados de Let’s Encrypt tienen una validez de noventa días, mucho más corta que la de los certificados comerciales tradicionales, que solían durar uno o más años, y esta corta duración es una decisión de diseño deliberada que responde a razones de seguridad y de fomento de la automatización. Por el lado de la seguridad, un periodo de validez corto limita el tiempo durante el cual un certificado comprometido, por ejemplo si su clave privada fuera robada o filtrada, podría ser utilizado de forma maliciosa, ya que expiraría pronto; además, reduce la dependencia de los mecanismos de revocación, que históricamente han funcionado de manera imperfecta, porque un certificado que caduca rápido deja de ser un problema en poco tiempo aunque no se revoque explícitamente. Por el lado de la automatización, una validez corta obliga en la práctica a automatizar la renovación, y esa automatización es precisamente lo que hace sostenible y fiable el modelo, ya que elimina el riesgo de olvidos humanos y convierte la gestión de certificados en un proceso desatendido y robusto. La consecuencia práctica de esta corta duración es que la renovación automática deja de ser una comodidad para convertirse en una necesidad: confiar en renovar el certificado manualmente cada noventa días es una receta para que, tarde o temprano, alguien lo olvide y el sitio amanezca un día mostrando un error de certificado caducado, con la consiguiente pérdida de servicio y de confianza de los usuarios. Por fortuna, la herramienta cliente habitual instala automáticamente una tarea programada que revisa periódicamente los certificados y renueva los que están próximos a expirar, de modo que, una vez configurado correctamente, el sistema se mantiene solo durante años sin intervención. Por eso es tan importante, tras obtener el certificado, verificar que la renovación automática funcionará correctamente mediante una simulación, ya que así se confirma que el proceso desatendido operará sin problemas. En resumen, la corta duración de noventa días no es un inconveniente sino una característica pensada para mejorar la seguridad y forzar buenas prácticas de automatización, siempre que se configure adecuadamente la renovación automática.

Sí, una de las grandes ventajas de usar Nginx como reverse proxy es precisamente la capacidad de servir varias aplicaciones distintas desde un único servidor y una única instancia de Nginx, enrutando cada petición hacia la aplicación adecuada. Existen dos formas principales de organizar ese enrutamiento, que pueden combinarse. La primera y más habitual es el enrutamiento por dominio o subdominio, en el que Nginx decide a qué aplicación reenviar según el nombre de dominio solicitado por el usuario; por ejemplo, un dominio o subdominio puede dirigirse a la aplicación principal, otro subdominio a una interfaz de administración y otro a una interfaz de programación, cada uno atendido por una aplicación diferente escuchando en su propio puerto interno. Esto se configura definiendo un bloque de servidor por cada nombre de dominio, cada uno con su directiva de reenvío apuntando al puerto interno de la aplicación correspondiente. La segunda forma es el enrutamiento por ruta dentro de un mismo dominio, en el que distintas rutas de la misma dirección se reenvían a aplicaciones distintas; por ejemplo, las peticiones a una ruta que empieza por un determinado prefijo pueden ir a una aplicación de interfaz de programación, mientras que el resto de las peticiones van a la aplicación web principal, todo bajo el mismo dominio. Esto se configura con varios bloques de ubicación dentro de un mismo bloque de servidor, cada uno con su propio destino de reenvío. En ambos casos, el cifrado seguro puede gestionarse de forma centralizada en Nginx para todos los dominios y aplicaciones, obteniendo certificados para cada dominio, lo que simplifica mucho la administración frente a que cada aplicación tuviera que ocuparse de su propio cifrado. Esta capacidad de consolidar múltiples servicios detrás de un único punto de entrada es una de las razones por las que el patrón de reverse proxy resulta tan práctico, ya que permite aprovechar un solo servidor y una sola configuración de cifrado para alojar y publicar de forma ordenada varias aplicaciones, con la flexibilidad de enrutar por dominio, por ruta o por una combinación de ambos según convenga.

En general, una aplicación puede funcionar detrás de Nginx como reverse proxy sin grandes cambios, pero sí conviene que esté configurada para tener en cuenta que hay un intermediario delante, porque de lo contrario pueden aparecer comportamientos incorrectos, especialmente en lo relativo a la dirección real del usuario y al protocolo de la conexión. El motivo es que, cuando Nginx reenvía las peticiones a la aplicación, quien contacta directamente con la aplicación es el propio Nginx desde el mismo servidor, de modo que, si no se toman medidas, la aplicación creería que todas las peticiones provienen de la dirección local y que llegan por una conexión sin cifrar, ya que la comunicación interna entre Nginx y la aplicación suele ser en texto plano dentro del servidor. Para evitarlo, Nginx debe configurarse para añadir ciertas cabeceras al reenviar, que transmiten a la aplicación la dirección real del usuario y el protocolo original de la conexión, es decir, si el usuario accedió de forma cifrada. Pero además, la aplicación o el marco de trabajo sobre el que está construida deben estar configurados para confiar en esas cabeceras y utilizarlas, algo que muchos marcos ofrecen mediante una opción de confianza en el proxy; sin activar esa confianza, la aplicación podría ignorar las cabeceras o, peor aún, aceptarlas de fuentes no fiables, lo que tiene implicaciones de seguridad. Las consecuencias de no configurar bien este aspecto son problemas concretos y a veces desconcertantes, como que todos los registros muestren la misma dirección de origen en lugar de la real de cada usuario, que la limitación por dirección no funcione, que la aplicación genere enlaces o redirecciones sin cifrar aunque el usuario esté navegando de forma segura, o que se produzcan bucles de redirección. Por tanto, aunque la aplicación no necesita ser reescrita para funcionar tras un reverse proxy, sí es recomendable, y a menudo necesario, configurarla para reconocer que opera detrás de un proxy de confianza y para interpretar correctamente las cabeceras que este le envía, de modo que perciba la dirección real del usuario y el protocolo original y se comporte en consecuencia.