Nginx Proxy Manager: qué es, instalación con Docker y SSL

Nginx Proxy Manager es un proxy inverso con interfaz web que se instala con Docker: recibe las visitas que llegan de internet y las reparte entre sus aplicaciones internas. Además, le pone a cada una un certificado SSL gratuito y lo renueva solo. Por eso es la forma más sencilla de publicar varios servicios con una sola dirección IP, sin escribir a mano la configuración de Nginx. En esta guía verá cómo instalarlo, cómo configurarlo y cómo resolver sus fallos más buscados, empezando por el error 502 Bad Gateway.

Esta guía sirve a dos lectores. Si usted decide en una empresa, le bastan los apartados sobre qué es, para qué sirve, qué beneficios trae y qué límites tiene. Si administra los sistemas, además encontrará el sistema base, las arquitecturas soportadas, la instalación con Docker, la configuración básica, los comandos más comunes, varios escenarios de ejemplo y los errores frecuentes.

Por otra parte, no nos quedamos en la documentación. Primero leímos el código de la versión vigente, la 2.16.0. Después la pusimos a funcionar en un entorno aislado y medimos cada opción con peticiones reales. Así encontramos cuatro cosas que conviene saber antes de usarlo. Primero, el usuario por defecto ya no existe. Segundo, una opción de caché puede entregar a un visitante la respuesta de otro. Tercero, pedir un certificado deja el sitio unos segundos sin servicio. Y cuarto, un error de sintaxis en la configuración avanzada apaga el host.

Qué es Nginx Proxy Manager y para qué sirve

Nginx Proxy Manager es un programa gratuito y de código abierto que administra un proxy inverso desde el navegador. Por dentro usa Nginx, uno de los servidores web más extendidos. Sin embargo, usted no edita sus ficheros: llena un formulario y el programa escribe la configuración por usted.

El proyecto nació en diciembre de 2017 y tiene licencia MIT. Además, su repositorio oficial supera las 34.000 estrellas en GitHub y su imagen de Docker acumula más de 282 millones de descargas. Su autor resume el objetivo así: que publicar un servicio con HTTPS sea tan fácil que cualquiera pueda hacerlo.

Explicado sin tecnicismos

Piense en la portería de un edificio de oficinas. El edificio tiene una sola entrada, pero adentro trabajan muchas empresas. El portero recibe a cada visitante, le pregunta a quién busca y lo envía al piso correcto. Además, comprueba la identificación y, si una empresa lo pide, solo deja subir a quienes están en su lista.

Nginx Proxy Manager es ese portero. La entrada es la dirección IP pública de su empresa y los pisos son sus aplicaciones: el sistema de inventario, la wiki interna o el panel de un servidor. En cambio, sin un portero cada aplicación necesitaría su propia entrada a la calle, es decir, su propia IP o un puerto distinto que el visitante tendría que recordar.

Qué es un proxy inverso y en qué se diferencia de un proxy

Los dos son intermediarios, pero trabajan para lados opuestos. Un proxy «directo» representa a quien navega: los equipos de la oficina salen a internet a través de él. En cambio, un proxy inverso representa a quien publica: las visitas llegan a él, y él las entrega al servidor que corresponde.

Pregunta	Proxy directo	Proxy inverso
¿A quién representa?	A los usuarios que navegan	A los servidores que publican
¿Dónde se pone?	Entre la oficina e internet, de salida	Entre internet y sus aplicaciones, de entrada
¿Para qué sirve?	Filtrar o registrar la navegación	Repartir visitas, poner HTTPS y controlar el acceso
¿Quién sabe que existe?	El equipo del usuario, que se configura para usarlo	Nadie: el visitante cree que habla con la aplicación

Además, el proxy inverso decide a dónde va cada visita según el nombre que escribió el visitante. Por ejemplo, inventario.example.com va a una aplicación y wiki.example.com va a otra, aunque los dos nombres apunten a la misma dirección IP.

Qué hay dentro de Nginx Proxy Manager

No es un solo programa, sino varios que trabajan juntos dentro de un contenedor. Esto es lo que encontramos al abrir la imagen oficial de la versión 2.16.0, publicada el 24 de septiembre de 2026:

Pieza	Qué hace	Versión en la 2.16.0
OpenResty (Nginx)	Es el proxy inverso: recibe y reparte las visitas	1.31.1.1
Panel y API	Guardan lo que usted configura y escriben los ficheros de Nginx	Node.js 22
Certbot	Pide y renueva los certificados de Let’s Encrypt	5.8.0
Base de datos	Guarda usuarios, hosts, listas y certificados	SQLite, o MariaDB y PostgreSQL
Sistema base	El Linux mínimo sobre el que corre todo	Debian 13 «trixie»

Por tanto, lo que usted administra es Nginx. El panel solo le ahorra escribir y recargar su configuración. Eso tiene una consecuencia práctica: todo lo que sabe de Nginx sigue valiendo, y los ficheros que genera el panel se pueden leer.

Usos comunes de Nginx Proxy Manager

Casi todos los usos se resumen en una idea: una sola puerta de entrada, ordenada y con HTTPS, para servicios que viven en la red interna.

Uso	Ejemplo	Función que se usa
Publicar varias aplicaciones con una sola IP	El inventario y la wiki en el mismo servidor	Hosts proxy
Poner HTTPS a una aplicación que no lo trae	Un panel interno que solo habla HTTP	Certificado SSL con Let’s Encrypt
Usar HTTPS dentro de la oficina	Nombres internos con candado, sin abrir puertos	Desafío DNS y certificado comodín
Limitar quién entra	Un panel de administración solo para la red de la oficina	Listas de acceso
Mover un dominio	El dominio antiguo lleva al nuevo sin perder las rutas	Hosts de redirección
Publicar algo que no es web	Una base de datos o un servidor de juegos	Streams TCP y UDP
Retirar un nombre	Un servicio dado de baja responde «no existe»	Hosts 404
Montar un laboratorio	Un servidor casero con Docker o Proxmox	Todo lo anterior

Por eso es tan popular en laboratorios caseros y en empresas pequeñas. Además, encaja con las herramientas que ya explicamos en este blog: los contenedores de Docker, las máquinas virtuales de Proxmox o un NAS con TrueNAS.

Beneficios de Nginx Proxy Manager y sus límites

Beneficio	En la práctica
Sin editar ficheros	Un host nuevo es un formulario; el panel escribe y recarga Nginx
HTTPS gratuito y automático	Pide el certificado a Let’s Encrypt y lo renueva 30 días antes de que caduque
Interfaz en español	Está traducida a 25 idiomas; en español tiene 230 de sus 280 textos
Usuarios y auditoría	Varios usuarios con permisos, verificación en dos pasos y registro de cambios
Automatizable	Todo lo que hace el panel se puede pedir por su API
Ligero	En nuestra prueba usó entre 99 y 149 MiB de memoria
Gratuito	Licencia MIT, sin versión de pago ni límite de hosts

Lo que Nginx Proxy Manager no hace

Conviene conocer los límites antes de adoptarlo, porque casi todos se descubren tarde:

• Solo se distribuye como imagen de Docker. Es decir, las instalaciones sin Docker existen, pero las mantienen terceros.
• Es un único punto de entrada. Si el proxy inverso se detiene, todos los servicios publicados quedan fuera a la vez.
• Cada host apunta a un solo destino. Por tanto, repartir la carga entre varios servidores exige escribir configuración de Nginx a mano.
• No es un cortafuegos de aplicaciones. La opción «Bloquear Exploits Comunes» aplica 25 patrones fijos sobre la dirección y el navegador, nada más.
• Solo la última versión recibe correcciones de seguridad. Así lo dice la política del proyecto, que publicó 12 versiones en los últimos doce meses.

Sistema base y arquitecturas soportadas

Nginx Proxy Manager no es un sistema operativo ni un paquete que se instala con apt. Es una imagen de Docker, y trae adentro su propio sistema: Debian 13 «trixie» desde la versión 2.15.0, del 31 de mayo de 2026. Por eso el servidor anfitrión puede ser cualquier Linux con Docker.

En cuanto al procesador, la imagen se publica para dos arquitecturas: amd64 y arm64. Es decir, funciona en servidores y computadores con procesadores Intel o AMD de 64 bits, y en equipos ARM de 64 bits. Si quiere repasar la diferencia, la explicamos en la comparativa AMD64 vs ARM64.

En cambio, los equipos ARM de 32 bits quedaron fuera. Desde la versión 2.14.0, de febrero de 2026, el proyecto ya no publica la imagen armv7, porque Node.js dejó de dar soporte a esa plataforma. La última que sirve allí es la 2.13.7, que ya no recibe correcciones.

Requisitos: lo que midió nuestra prueba

La documentación no publica requisitos mínimos, así que los medimos. Usamos la imagen oficial 2.16.0 en Docker Desktop para Windows, con tres hosts, un stream y dos certificados:

Dato	Resultado
Tamaño de la descarga	453 MB comprimidos
Espacio en disco, ya desempaquetada	1,1 GB
Primer arranque hasta tener el panel	5,0 segundos
Memoria recién instalado	99 MiB
Memoria con hosts y certificados	Entre 110 y 149 MiB
Base de datos tras toda la prueba	115 KB
Copia de seguridad completa	115 KB comprimida

Además, la imagen crece con cada versión: la 2.13.0 pesaba 361 MB y la 2.16.0 pesa 453 MB, un 25 % más en menos de once meses. Por eso conviene reservar unos 2 GB de disco para la imagen y vigilar el espacio al actualizar.

Antes de instalar Nginx Proxy Manager: lo que necesita

Antes de instalar Nginx Proxy Manager conviene tener resueltas cinco cosas. Casi todos los problemas del primer día vienen de una de ellas, no del programa:

1. Un servidor o una máquina virtual con Linux de 64 bits y Docker con Compose. Si no lo tiene, empiece por nuestra guía de Docker Compose.
2. Un nombre de dominio y un registro que apunte a su IP pública. Lo explicamos en la guía del servidor DNS.
3. Los puertos 80 y 443 reenviados desde el router o el firewall hacia ese servidor. Por ejemplo, así se hace en pfSense, en OPNsense o en MikroTik.
4. Una IP pública a la que se pueda llegar. Si su proveedor de internet no se la da, más abajo verá cómo usar HTTPS solo dentro de la oficina.
5. La dirección y el puerto de cada aplicación interna que piensa publicar.

Con eso listo, el camino de una visita queda así:

Paso	Qué ocurre
1	El visitante escribe inventario.example.com y el DNS le responde con la IP pública de la empresa
2	El firewall recibe la conexión en el puerto 443 y la reenvía al servidor del proxy inverso
3	El proxy inverso lee el nombre, elige el host que le corresponde y presenta su certificado
4	Después reenvía la petición a la aplicación interna y devuelve la respuesta al visitante

Por tanto, la aplicación nunca queda expuesta de forma directa. Solo el proxy inverso recibe conexiones de internet, y solo por dos puertos.

Cómo instalar Nginx Proxy Manager con Docker Compose

La forma oficial de instalar Nginx Proxy Manager es un fichero de Docker Compose. La documentación del proyecto ofrece uno mínimo; el nuestro añade cuatro precauciones que explicamos después.

Paso 1: el fichero compose.yaml

Primero cree una carpeta para el proyecto, por ejemplo /opt/proxy, y guarde dentro este fichero como compose.yaml:

services:
  app:
    image: 'jc21/nginx-proxy-manager:2.16.0'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '127.0.0.1:81:81'
    environment:
      TZ: 'America/Bogota'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    healthcheck:
      test: ['CMD', '/usr/bin/check-health']
      interval: 30s
      timeout: 5s

Cada línea tiene un motivo:

Línea	Por qué va así
image: …:2.16.0	Fija la versión. Con latest, cada descarga puede traer cambios que usted no ha leído
80:80 y 443:443	Son los puertos públicos. Deben quedar iguales, porque Let’s Encrypt solo valida por el 80
127.0.0.1:81:81	El panel de administración solo responde desde el propio servidor, no desde internet
TZ	Pone la hora local en los registros
./data y ./letsencrypt	Las dos carpetas guardan toda la configuración y los certificados
healthcheck	La imagen no trae comprobación de salud; así Docker sabe si el panel responde

Además, para abrir el panel desde su computador hay dos caminos. El primero es un túnel SSH, que no abre nada más: ssh -L 8181:127.0.0.1:81 usuario@servidor y luego http://127.0.0.1:8181 en el navegador. El segundo es cambiar esa línea por la IP interna del servidor, por ejemplo '192.168.10.5:81:81', para llegar desde la red de la oficina.

Paso 2: arrancar y comprobar

Después, desde esa carpeta, arranque el servicio y compruebe que respondió:

docker compose up -d
docker compose ps
docker compose logs --tail 20 app
curl -s http://127.0.0.1:81/api/

La última orden debe devolver algo como {"status":"OK","setup":false,"version":{"major":2,"minor":16,"revision":0}}. En nuestra prueba el panel respondió a los 5 segundos del primer arranque. Mientras tanto, el programa crea la base de datos y un par de claves para firmar las sesiones.

Paso 3: crear el administrador, porque ya no hay usuario por defecto

Durante años, el primer ingreso se hizo con admin@example.com y la contraseña changeme. Muchas guías todavía lo dicen, pero ya no es cierto. Desde la versión 2.13.0, de noviembre de 2025, no existe ningún usuario inicial. En su lugar, al abrir el panel aparece la pantalla «¡Bienvenido!», que le pide nombre, correo y una contraseña de ocho caracteres como mínimo.

Lo comprobamos en la 2.16.0. Con el usuario antiguo, el panel respondió «Invalid email or password». Además, vimos que el campo setup de la orden anterior pasa de false a true cuando el administrador ya existe.

Sin embargo, esa comodidad tiene un riesgo. Mientras nadie complete la pantalla de bienvenida, cualquiera que llegue al puerto 81 puede crear el administrador. Por eso recomendamos no publicar ese puerto y completar el asistente justo después del primer arranque.

También existe una vía automática: las variables INITIAL_ADMIN_EMAIL e INITIAL_ADMIN_PASSWORD crean el usuario sin pasar por la pantalla. Ahora bien, en nuestra prueba la contraseña quedó escrita en texto claro en dos sitios: el registro del contenedor y el fichero data/logs/backend.log. Si las usa, cambie la contraseña en cuanto entre.

Instalar Nginx Proxy Manager en Proxmox, Raspberry Pi, Windows o un NAS

El método es el mismo en casi todas partes, porque lo único que cambia es dónde corre Docker:

Plataforma	Cómo se instala	Lo que debe saber
Servidor o máquina virtual Linux	Docker Compose	Es el camino que documenta y atiende el proyecto
Raspberry Pi 3, 4 o 5	Docker Compose sobre un sistema de 64 bits	Solo arm64; con un sistema de 32 bits no hay imagen vigente
Proxmox	Una máquina virtual o un contenedor con Docker	También existe un guion comunitario que no usa Docker
Windows y macOS	Docker Desktop	Sirve para pruebas; así hicimos las nuestras
Unraid, Synology y Home Assistant	Imágenes y complementos de terceros	El autor los lista, pero aclara que no les da soporte

En Proxmox, el guion comunitario merece una aclaración. Crea un contenedor con Debian 13, 2 núcleos, 2 GB de memoria y 8 GB de disco, y compila el programa desde el código fuente. Por tanto, no usa la imagen oficial. De hecho, el día de nuestra revisión compilaba OpenResty 1.29.2.5, mientras la imagen oficial ya traía la 1.31.1.1. Es cómodo, pero las correcciones le llegan por otro camino y con otro calendario.

SQLite, MariaDB o PostgreSQL: dónde guarda la configuración

De fábrica, todo se guarda en un fichero SQLite dentro de data. Para un solo servidor es suficiente y, además, simplifica la copia de seguridad: basta con copiar la carpeta. Si prefiere MariaDB o PostgreSQL, se configuran con las variables DB_MYSQL_* o DB_POSTGRES_* que describe la documentación.

Configuración básica de Nginx Proxy Manager: el primer host proxy

En Nginx Proxy Manager, cada servicio publicado es un «host proxy». Para crearlo, entre al menú Hosts, elija Hosts Proxy y pulse el botón de añadir. El formulario pide muy poco:

Campo del panel	Qué se escribe	Ejemplo
Nombres de Dominio	El nombre público, o varios	inventario.example.com
Esquema	Cómo habla la aplicación interna	http
Nombre de Host / IP de Reenvío	Dónde está la aplicación	192.168.10.20 o el nombre del contenedor
Puerto	En qué puerto escucha	8080
Lista de Acceso	Quién puede entrar	Accesible Públicamente

Al guardar, el panel escribe un fichero en data/nginx/proxy_host y recarga Nginx. Desde ese momento el nombre ya responde por HTTP. Además, si escribe un dominio que ya usa otro host, el panel lo rechaza con el aviso «is already in use».

Hay un error muy común en el destino: escribir 127.0.0.1. Dentro de un contenedor, esa dirección es el propio proxy inverso, no el servidor. Por tanto, use la IP del equipo en la red o, si la aplicación corre en Docker, el nombre de su contenedor.

Qué recibe la aplicación detrás del proxy inverso

Para comprobarlo pusimos detrás una aplicación de diagnóstico que devuelve lo que recibe. Esto fue lo que añadió el proxy inverso a cada petición:

Cabecera	Contenido	Para qué le sirve a la aplicación
Host	El nombre que escribió el visitante	Saber por qué dominio la llamaron
X-Forwarded-For	La IP del visitante, añadida al final de lo que ya traía	Registrar quién la visitó
X-Real-IP	La IP desde la que llegó la conexión	Lo mismo, en un solo valor
X-Forwarded-Proto	http o https	Saber si el visitante usó HTTPS

Sin embargo, hay un detalle importante. Enviamos una petición con un X-Forwarded-For inventado y la aplicación recibió los dos valores: primero el falso y después el real. Es decir, el proxy inverso no borra lo que manda el visitante. Si su aplicación toma el primer valor de esa lista para decidir algo, un visitante puede engañarla.

Qué hace cada opción del host

El formulario tiene tres interruptores. Probamos cada uno con peticiones reales, encendido y apagado:

Opción	Apagada	Encendida
Soporte de Websockets	La aplicación respondió 400 a una conexión de tipo websocket	Respondió 101, que es la conexión establecida
Bloquear Exploits Comunes	Una dirección con forma de ataque pasó, con 200	El proxy la cortó con 403
Cachear Recursos	Cada petición llegó a la aplicación	La segunda petición de un fichero .css ya no llegó

La primera opción hay que encenderla en casi cualquier aplicación moderna: consolas remotas, tableros que se actualizan solos o chats internos. Por ejemplo, la consola web de una máquina virtual usa esa clase de conexión.

En cambio, la última merece cuidado. Con «Cachear Recursos», el proxy inverso guarda 30 minutos los ficheros de estilo, los guiones y las imágenes. Además, lo hace sin mirar las instrucciones de la aplicación ni sus cookies. En nuestra prueba, la segunda petición recibió la respuesta que se había generado para la primera, con los datos de otra sesión. En un sitio con ficheros fijos eso es justo lo que se busca. Sin embargo, en una aplicación que arma esos ficheros por usuario, un visitante vería datos de otro. Tampoco queda rastro: esas peticiones no se anotan en el registro de acceso.

El certificado SSL en Nginx Proxy Manager

El certificado SSL es lo que pone el candado y el https:// en el navegador. En Nginx Proxy Manager se pide desde la pestaña SSL del host: se elige «Solicitar un nuevo Certificado», con Let’s Encrypt, y se guarda. No cuesta nada, porque Let’s Encrypt es una autoridad gratuita. Además, sus certificados duran 90 días y el panel los renueva solo.

Dos formas de demostrar que el dominio es suyo

Antes de emitir, Let’s Encrypt comprueba que usted controla el dominio. Hay dos pruebas posibles, y elegir bien ahorra la mayoría de los errores:

Pregunta	Desafío HTTP	Desafío DNS
¿Qué exige?	Que Let’s Encrypt llegue a su servidor por el puerto 80	Una credencial de la API de su proveedor de DNS
¿Sirve sin abrir puertos?	No	Sí
¿Permite un comodín como *.example.com?	No	Sí
¿Cuál es el riesgo?	Tener el puerto 80 abierto a internet	Guardar esa credencial en el servidor

El desafío HTTP es el que viene por defecto y el más simple. En cambio, el desafío DNS se activa con «Usar Desafío DNS» y pide elegir el proveedor: el panel trae 88. El propio panel avisa de que esa credencial se guarda como texto plano en la base de datos. Por eso conviene crearla con el permiso mínimo: editar solo esa zona.

Lo que medimos al pedir y renovar un certificado SSL

Para no tocar Let’s Encrypt, usamos una autoridad de pruebas local que habla su mismo protocolo. Es la misma que emplea el proyecto para probar cada versión. Los tiempos dependen de la autoridad, pero el comportamiento del panel es el mismo:

Qué medimos	Resultado
Emitir un certificado con el desafío HTTP	2,6 segundos
Tiempo que el host dejó de responder durante la emisión	3,3 segundos
Renovar ese certificado	2,5 segundos, sin ningún corte
Tipo de clave de fábrica	ECDSA de 384 bits
Tipo de clave al elegir RSA	RSA de 2.048 bits

El segundo dato sorprende. Al pedir un certificado, el panel retira un momento el host de Nginx para responder él mismo a la prueba, y luego lo restaura. Durante ese rato el sitio no responde. Por tanto, pida el primer certificado de un servicio en uso fuera del horario de trabajo. En cambio, la renovación no corta nada.

También encontramos una diferencia entre el rótulo y el resultado. El selector de la interfaz ofrece «ECDSA 256», pero la clave que obtuvimos fue de 384 bits. No es un problema de compatibilidad con los navegadores actuales; solo conviene saberlo si audita sus certificados.

En cuanto a la renovación, el panel revisa cada hora, y al arrancar, si algún certificado caduca en menos de 30 días. Con los 90 días de Let’s Encrypt, eso significa renovar en el día 60, que es justo lo que recomienda esa autoridad. Además, Let’s Encrypt aplica límites de emisión que conviene conocer antes de repetir intentos fallidos:

Límite de Let’s Encrypt	Valor
Certificados por dominio registrado	50 cada 7 días
Certificados para el mismo conjunto exacto de nombres	5 cada 7 días
Validaciones fallidas por nombre	5 por hora
Nombres dentro de un mismo certificado	Hasta 100

Forzar SSL, HTTP/2 y HSTS: qué envía de verdad

Con el certificado puesto, la pestaña SSL ofrece cuatro interruptores. Esto hizo cada uno en nuestra prueba:

Opción	Efecto medido
Forzar SSL	Responde 301 hacia https:// con el mismo nombre y la misma ruta, sin indicar puerto
Soporte HTTP/2	La respuesta llegó por HTTP/2
HSTS Habilitado	Añade la cabecera Strict-Transport-Security con max-age=63072000; preload
HSTS en Subdominios	Añade includeSubDomains a esa cabecera

De esa tabla salen dos avisos. Primero, la redirección de «Forzar SSL» no lleva puerto. Por eso, si publica el proxy inverso en puertos distintos del 80 y el 443, el visitante acabará en un sitio que no existe. Segundo, HSTS le dice al navegador que use solo HTTPS con ese dominio durante dos años. Además, apagar la opción después no lo borra de los navegadores que ya lo recibieron. Así que actívelo cuando el HTTPS lleve semanas estable, y la opción de subdominios solo si todos tienen certificado.

Por otra parte, comprobamos qué versiones del protocolo acepta. El servidor rechazó TLS 1.0 y TLS 1.1, y aceptó TLS 1.2 y TLS 1.3, con ocho conjuntos de cifrado. Es una configuración actual, que solo deja fuera equipos muy antiguos.

Usar un certificado propio

Si ya tiene un certificado de otra autoridad, se sube en Certificados, con la opción «Certificado Personalizado». Se suben el certificado y su clave y, si la autoridad lo entrega, el certificado intermedio. Además, la clave no puede tener contraseña.

En nuestra prueba, esa clave quedó en data/custom_ssl con permiso de lectura para cualquier usuario del servidor. En cambio, las claves que genera Let’s Encrypt quedaron solo para el administrador. Por tanto, limite quién puede entrar a la carpeta data.

Listas de acceso, redirecciones, streams y hosts 404

Además de los hosts proxy, el panel de Nginx Proxy Manager tiene otras cuatro funciones. Todas se configuran igual: un formulario y un botón de guardar.

Listas de acceso: quién puede entrar

Una lista de acceso combina dos filtros: usuario con contraseña, y direcciones IP permitidas o denegadas. Probamos las cuatro combinaciones desde una dirección que no estaba en la lista:

Regla de la lista	Sin contraseña	Con contraseña
Solo usuario y contraseña	401, pide credenciales	200, entra
Solo red permitida	403, prohibido	403, prohibido
Usuario y red, con «satisfacer todo»	403	403
Usuario o red, con «Satisfacer Cualquiera»	401	200

Es decir, con «Satisfacer Cualquiera» basta cumplir una condición: estar en la red de la oficina o saber la contraseña. Sin esa opción hay que cumplir las dos.

Sin embargo, antes de escribir una regla por IP, mire qué dirección ve el proxy inverso. En nuestra prueba no vio la del equipo, sino la de la pasarela de Docker. El dato está en el registro de acceso de cada host, en el campo Client.

Además, la versión 2.16.0 estrenó las listas por ruta. Así, /admin puede pedir contraseña mientras el resto del sitio es público. Lo probamos y funciona, con un matiz: la ruta es un prefijo. Por eso /admin también protegió /administrar.

Por último, hay un caso en que la contraseña de la lista estorba. Si la aplicación ya inicia sesión con la cabecera Authorization, las dos contraseñas chocan. Lo reprodujimos con el propio panel: el inicio de sesión pasó, pero la siguiente petición recibió un 401. En esos casos use solo la regla por red.

Hosts de redirección y hosts 404

Un host de redirección envía un dominio a otro. Se elige el código, entre 300 y 308, y si se conserva la ruta. En nuestra prueba, con el código 301 y «Preservar Ruta», viejo.example.com/docs/manual?v=2 llevó a la misma ruta en el dominio nuevo. Así no se pierden los enlaces antiguos.

En cambio, un host 404 hace lo contrario: responde «no encontrado» a un nombre que usted ya retiró, en lugar de mostrar otro servicio por error.

Streams: servicios que no son web

Un stream reenvía un puerto TCP o UDP tal cual, sin mirar nombres. Sirve para lo que no es HTTP: una base de datos, un servidor de juegos o un acceso SSH. Sin embargo, tiene tres condiciones:

• El puerto debe estar publicado también en el fichero compose.yaml, igual que el 80 y el 443.
• Como no hay nombres, cada servicio necesita su propio puerto.
• La aplicación ya no ve la IP del visitante. En nuestra prueba solo vio la del proxy inverso.

Sitio predeterminado: qué ve quien llega sin un nombre válido

Si alguien llega con un nombre que no existe, o solo con la IP, responde el «Sitio Predeterminado», que se cambia en Configuración. Probamos las cinco opciones:

Opción	Lo que recibe el visitante
Página de Felicitaciones	Código 200 y una página que dice que es Nginx Proxy Manager
Página 404	Código 404
Sin Respuesta (444)	Nada: la conexión se cierra
Redirigir	Código 301 hacia la dirección que usted indique
HTML Personalizado	Código 200 con su propio texto

La opción de fábrica es la primera, y le cuenta a cualquiera qué programa hay detrás. Por tanto, cámbiela por «Sin Respuesta (444)» o por la página 404. Por HTTPS el comportamiento es distinto: si el nombre no tiene certificado, el servidor rechaza la conexión antes de responder.

Ubicaciones personalizadas y configuración avanzada

Una ubicación personalizada envía una ruta del mismo dominio a otro destino. Por ejemplo, /wiki puede ir a un servidor distinto del resto. Aquí encontramos una diferencia que explica muchos errores 404:

Cómo se escribe	Lo que recibe la aplicación al pedir /wiki/pagina
Ubicación /wiki, sin ruta de destino	/wiki/pagina, la ruta completa
Ubicación /wiki/, con ruta de destino /	/pagina, sin el prefijo

Por otra parte, la pestaña avanzada admite directivas de Nginx para ese host. Las dos más útiles ajustan límites de fábrica, que comprobamos:

Límite de fábrica	Qué pasa al superarlo	Directiva para cambiarlo
Subidas de hasta 2.000 MB	Error 413	client_max_body_size 5000m;
Respuestas en menos de 90 segundos	Error 504, a los 90,0 segundos	proxy_read_timeout 300s;

Sin embargo, esa pestaña no perdona. Escribimos una directiva sin el punto y coma final y el panel la guardó sin protestar. Después marcó el host como desconectado, renombró su fichero con la extensión .err y dejó de servir esa aplicación: quien la visitaba recibía el sitio predeterminado. Los demás hosts siguieron funcionando. Por eso, tras cada cambio avanzado, compruebe que el host sigue «Conectado».

Comandos más comunes de Nginx Proxy Manager

Casi todo se hace desde el panel, pero el día que algo falla se trabaja en la consola. Estas son las órdenes que más se usan. Las ejecutamos todas contra la instancia de prueba, desde la carpeta del fichero compose.yaml:

docker compose ps
docker compose logs -f --tail 50 app
docker compose exec app nginx -t
docker compose exec app nginx -s reload
docker compose exec app /usr/bin/check-health
docker compose exec app certbot certificates
docker compose exec app ls /data/nginx/proxy_host
docker compose exec app tail -n 50 /data/logs/proxy-host-1_error.log
docker stats --no-stream
docker compose restart app

Orden	Para qué sirve
docker compose ps	Ver si el contenedor está en marcha y qué puertos publica
docker compose logs	Leer el registro del panel: arranque, certificados y errores
nginx -t	Comprobar si la configuración de Nginx es válida
nginx -s reload	Recargar Nginx sin cortar las conexiones abiertas
check-health	Saber si el panel responde; devuelve OK
certbot certificates	Listar los certificados de Let’s Encrypt con su fecha de caducidad
ls y tail	Ver los ficheros que generó el panel y el registro de errores de un host
docker stats	Medir la memoria y el procesador que usa el contenedor
docker compose restart app	Reiniciar el servicio sin borrar nada; espere unos segundos antes de la orden siguiente

Además, cada host tiene dos registros en data/logs: uno de acceso y otro de errores. El número del fichero es el del host en el panel. Desde la versión 2.16.0, el panel también trae un visor de registros, así que muchas veces ya no hace falta la consola.

Actualizar Nginx Proxy Manager

Para actualizar, primero cambie el número de versión en compose.yaml. Después ejecute dos órdenes:

docker compose pull
docker compose up -d

Docker descarga la imagen nueva y recrea el contenedor con las mismas carpetas. En nuestra prueba, al recrearlo, el sitio publicado volvió a responder a los 6,0 segundos y el panel a los 6,6. Además, regresó todo: usuarios, hosts, listas y certificados. Incluso la sesión abierta siguió valiendo.

Sin embargo, lea antes las notas de cada versión. Por ejemplo, las versiones 2.15.0 y 2.16.0 advierten de que el cambio de Certbot puede romper algunos complementos del desafío DNS.

Copia de seguridad y restauración

Toda la configuración vive en dos carpetas: data y letsencrypt. Por tanto, la copia es sencilla:

docker compose stop
sudo tar czf npm-respaldo-$(date +%F).tgz data letsencrypt
docker compose start

Para restaurar en otro servidor, copie allí el fichero compose.yaml, descomprima la copia en la misma carpeta y arranque con docker compose up -d. Lo probamos con una segunda instancia: volvieron los 3 hosts, las 4 listas de acceso y los 2 certificados, y el HTTPS respondió a la primera.

Ahora bien, esa copia es delicada. Contiene la base de datos, las claves privadas de los certificados y las claves con que el panel firma las sesiones. De hecho, una sesión abierta en el servidor original también fue aceptada por la copia. Así que guárdela cifrada y fuera del servidor, igual que cualquier respaldo. Si necesita un método, lo explicamos en la guía de tipos de backup.

La API con curl

El panel es una aplicación sobre su propia API, y esa API se puede usar con curl. Primero se pide un pase con el correo y la contraseña; después se envía en cada consulta. El pase dura un día. Este ejemplo lista los hosts con su destino:

TOKEN=$(curl -s -X POST http://127.0.0.1:81/api/tokens \
  -H 'Content-Type: application/json' \
  -d '{"identity":"admin@example.com","secret":"SuClaveDelPanel"}' | jq -r .token)

curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:81/api/nginx/proxy-hosts \
  | jq -r '.[] | "\(.id)  \(.domain_names | join(","))  ->  \(.forward_scheme)://\(.forward_host):\(.forward_port)"'

Además, la descripción completa de la API está en http://127.0.0.1:81/api/schema, en formato OpenAPI. En la 2.16.0 contamos 46 rutas. Sirve, por ejemplo, para dar de alta hosts desde un guion o para vigilar las fechas de caducidad.

Recuperar el acceso si olvidó la contraseña

El panel no tiene la opción «olvidé mi contraseña». Sin embargo, quien tiene acceso al servidor puede recuperarla. Probamos dos caminos sobre una copia, ambos con la base de datos SQLite de fábrica. Antes de usarlos, haga una copia de seguridad.

El primero escribe una contraseña nueva para un usuario, sin tocar nada más:

docker compose exec app node -e "const b=require('/app/node_modules/bcrypt');const D=require('/app/node_modules/better-sqlite3');const d=new D('/data/database.sqlite');console.log(d.prepare('UPDATE auth SET secret=? WHERE type=? AND user_id=(SELECT id FROM user WHERE email=? AND is_deleted=0)').run(b.hashSync(process.argv[2],13),'password',process.argv[1]))" 'admin@example.com' 'UnaClaveNuevaYLarga'

Si responde changes: 1, ya puede entrar con la contraseña nueva. En cambio, el segundo camino marca a todos los usuarios como eliminados:

docker compose exec app node -e "const D=require('/app/node_modules/better-sqlite3');const d=new D('/data/database.sqlite');console.log(d.prepare('UPDATE user SET is_deleted=1').run())"

Después de esa orden, el panel vuelve a mostrar la pantalla de bienvenida y deja crear un administrador nuevo. En nuestra prueba, ese administrador vio todos los hosts, y el sitio siguió respondiendo durante el proceso. Eso sí, complete la pantalla enseguida: mientras esté abierta, cualquiera que llegue al puerto 81 puede crear ese usuario.

Escenarios de ejemplo con Nginx Proxy Manager

Los cinco escenarios siguientes cubren casi todos los usos reales de Nginx Proxy Manager. En ellos usamos los mismos nombres de ejemplo: inventario.example.com y wiki.example.com.

1. Dos aplicaciones en el mismo servidor Docker

Es el caso más habitual. Las aplicaciones corren en Docker, en el mismo servidor que el proxy inverso. La clave es que no publiquen ningún puerto: basta con que compartan una red de Docker con el proxy. Primero se crea esa red:

docker network create red-proxy

Después se añade al fichero del proxy inverso, que queda así:

services:
  app:
    image: 'jc21/nginx-proxy-manager:2.16.0'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '127.0.0.1:81:81'
    environment:
      TZ: 'America/Bogota'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - red-proxy

networks:
  red-proxy:
    external: true

Por último, cada aplicación se une a la misma red con un nombre propio. Por ejemplo, en la aplicación de inventario de nuestra guía de Docker Compose, el servicio que antes publicaba el puerto 80 quedaría así:

services:
  proxy:
    image: nginx:1.30-alpine
    restart: unless-stopped
    networks:
      frontend:
      red-proxy:
        aliases:
          - inventario

networks:
  frontend:
  red-proxy:
    external: true

En el panel, el host inventario.example.com apunta entonces a http://inventario:80. Así lo montamos en la prueba: las aplicaciones no publicaban ningún puerto y el proxy inverso las alcanzó por su nombre. Además, cuando detuvimos una, el proxy respondió 502; al arrancarla de nuevo, volvió a responder al instante.

2. Un equipo de la red local: un NAS o un hipervisor

Aquí el destino no es un contenedor, sino otro equipo: un servidor NAS, una impresora o el panel de un hipervisor. Se escribe su IP y su puerto, y se elige el esquema con cuidado:

• Si el equipo solo atiende por HTTPS con un certificado propio, elija https. De fábrica, Nginx no verifica el certificado del destino, así que funciona.
• Si el equipo tiene una consola o gráficas en vivo, active «Soporte de Websockets».
• Si el esquema no coincide, verá un error. En nuestra prueba, https contra un destino que solo habla HTTP dio 502, y http contra uno que solo habla HTTPS dio 400.

3. HTTPS dentro de la oficina sin abrir puertos

Muchas empresas no quieren publicar nada en internet, pero sí quieren el candado en sus aplicaciones internas. Se logra con el desafío DNS, porque Let’s Encrypt comprueba un registro del dominio y no necesita llegar a su servidor. Los pasos son tres:

1. Pida un certificado comodín, por ejemplo *.interno.example.com, con el desafío DNS y la credencial de su proveedor.
2. En el DNS de la oficina, haga que esos nombres respondan con la IP interna del proxy inverso. Sirve el DNS del firewall o un servidor como AdGuard Home.
3. Cree los hosts y asigne a todos el mismo certificado.

Este escenario no lo ejecutamos contra un proveedor real. Lo describimos a partir de la documentación de Let’s Encrypt sobre los tipos de desafío y de la lista de proveedores del proyecto.

4. Nginx Proxy Manager detrás de Cloudflare

Si su dominio pasa por Cloudflare, hay dos proxies en fila: el de Cloudflare y el suyo. El punto delicado es el modo de cifrado. En el modo «Flexible», Cloudflare habla con su servidor por HTTP. Si además su host tiene «Forzar SSL», cada petición se redirige a HTTPS, Cloudflare la repite por HTTP y el navegador muestra «demasiadas redirecciones».

Reprodujimos ese bucle enviando una petición HTTP que ya traía la marca de HTTPS. De fábrica, el proxy inverso respondió 301 una y otra vez. En cambio, con la opción «Trust Upstream Forwarded Proto Headers», añadida en la versión 2.14.0, respondió 200. Aun así, la salida limpia es otra: Cloudflare recomienda sus modos «Full» o «Full (strict)», que hablan con su servidor por HTTPS. Los describe en su página de modos de cifrado.

5. Un panel de administración solo para la oficina

Algunos servicios no deben estar a la vista de todo internet: el panel de un firewall, una consola de respaldo o el propio panel del proxy inverso. Para ellos, cree una lista de acceso que permita solo la red de la oficina y asígnela al host.

De hecho, el panel de Nginx Proxy Manager se puede publicar así. Creamos un host que apuntaba a http://127.0.0.1:81 y respondió con normalidad. De ese modo, el puerto 81 no sale del servidor y el panel queda detrás de HTTPS y de una regla por red. Para quienes trabajan fuera, la pareja natural de esa regla es una VPN: entran a la red de la oficina y, desde ella, al panel.

Errores frecuentes en Nginx Proxy Manager: 502 Bad Gateway y otros

Casi todos los errores de un proxy inverso dicen lo mismo con palabras distintas: no pudo hablar con la aplicación, o el navegador no pudo hablar con él. Reprodujimos los más buscados para ver qué los causa y cuánto tardan en aparecer.

El error 502 Bad Gateway y el 504

El error 502 Bad Gateway significa que el proxy inverso recibió su visita, pero no obtuvo una respuesta válida de la aplicación. Por tanto, el problema casi nunca está en el navegador, sino en el destino del host:

Causa que reprodujimos	Respuesta	Tardó	Lo que dice el registro de errores
Puerto equivocado	502 Bad Gateway	0,1 s	Connection refused
Nombre de destino que no existe	502 Bad Gateway	4,0 s	could not be resolved
Aplicación detenida	502 Bad Gateway	4,0 s	could not be resolved
Esquema https hacia una aplicación HTTP	502 Bad Gateway	Al instante	wrong version number
La aplicación tarda más de 90 segundos	504 Gateway Time-out	90,0 s	upstream timed out

Así que, ante un 502 Bad Gateway, revise tres cosas en este orden. Primero, que la aplicación esté en marcha. Después, que la IP o el nombre sean correctos. Por último, que el puerto y el esquema coincidan. Además, el registro de errores del host suele dar la respuesta en una línea. En cambio, el 504 se resuelve ampliando el tiempo de espera, como vimos en la configuración avanzada.

Internal Error al pedir el certificado SSL

Es el mensaje que más desconcierta, porque no explica nada. En nuestra prueba, pedir un certificado para un dominio que no apuntaba al proxy inverso tardó 89 segundos y terminó en «Internal Error». La causa real estaba en el registro de Certbot, en data/logs/letsencrypt.log: la autoridad no pudo llegar al servidor. Desde la versión 2.16.0, ese registro también se lee en el visor del panel.

Las causas habituales son cuatro: el dominio no apunta a su IP pública, el puerto 80 no está reenviado, su proveedor de internet bloquea ese puerto o ya agotó el límite de intentos fallidos. Por eso, tras dos fallos seguidos, deténgase y revise el DNS y el firewall antes de insistir.

Otros errores de Nginx Proxy Manager y su causa

Síntoma	Causa	Qué hacer
El navegador muestra ERR_SSL_UNRECOGNIZED_NAME_ALERT	No hay ningún host con certificado para ese nombre	Cree el host o asígnele un certificado
«Demasiadas redirecciones»	«Forzar SSL» detrás de otro proxy que ya terminó el HTTPS	Cambie el modo de cifrado de ese proxy o active la opción de confiar en sus cabeceras
403 con una lista de acceso por IP	El proxy inverso ve otra dirección, no la del visitante	Mire el campo Client del registro de acceso
401 que se repite tras iniciar sesión	La contraseña de la lista choca con la de la aplicación	Use una regla por red en lugar de usuario y contraseña
413 al subir un fichero	Supera el tamaño permitido	Suba client_max_body_size en la pestaña avanzada
400 al abrir la aplicación	Esquema http hacia un destino que solo habla HTTPS	Cambie el esquema a https
El host aparece «Desconectado»	Hay un error en su configuración avanzada	Corríjala; el fichero con el fallo queda con la extensión .err
El registro del contenedor cita Address family not supported	El servidor no tiene IPv6 activo	Añada la variable DISABLE_IPV6: 'true'

Hay un caso aparte que se consulta mucho: Home Assistant responde 400 detrás de un proxy inverso. No es un fallo del proxy. Según su documentación, Home Assistant bloquea las peticiones que llegan de un proxy hasta que usted activa la confianza en X-Forwarded-For y añade la IP del proxy a su lista de confianza.

Recomendaciones para usar Nginx Proxy Manager en una empresa

Nginx Proxy Manager nació para laboratorios caseros, y se nota en sus valores de fábrica. Para usarlo en una empresa conviene ajustar varias cosas desde el primer día:

1. No publique el puerto 81. Déjelo en 127.0.0.1 o en la red interna, y entre por un túnel o por una VPN.
2. Fije la versión de la imagen y actualice con calendario. Además, lea las notas de cada versión, porque solo la última recibe correcciones.
3. Haga la copia de las dos carpetas antes de cada actualización, y pruebe a restaurarla al menos una vez.
4. Cambie el sitio predeterminado por «Sin Respuesta (444)», para no anunciar qué programa usa.
5. Active la verificación en dos pasos del panel, disponible desde la versión 2.13.6.
6. Deje HSTS para el final, cuando el HTTPS lleve semanas estable.
7. No active «Cachear Recursos» en aplicaciones con sesión de usuario sin probarlo antes.
8. Use listas de acceso por red para los paneles de administración. Lo que no necesita estar en internet, no lo publique.
9. En el desafío DNS, cree la credencial con el permiso mínimo y solo para esa zona.
10. Vigile el servicio desde fuera: que responda y que los certificados no estén por caducar. Lo explicamos en la guía de monitoreo de servidores.
11. Recuerde que es un único punto de entrada. Si todo depende de él, documente cómo levantarlo en otro servidor. El concepto está en nuestra guía de alta disponibilidad.

Nginx Proxy Manager vs Traefik, Caddy y otras alternativas

Nginx Proxy Manager no es el único proxy inverso sencillo. La diferencia principal entre ellos es cómo se configuran: con un panel, con un fichero o con etiquetas en los contenedores.

Herramienta	Licencia	Cómo se configura	Cuándo conviene
Nginx Proxy Manager 2.16	MIT	Panel web y API	Pocos servicios, cambios a mano y un equipo que prefiere ver un formulario
Traefik 3.7	MIT	Etiquetas en los contenedores y ficheros	Muchos contenedores que cambian a menudo: descubre los servicios solo
Caddy 2.11	Apache 2.0	Un fichero de texto corto	Quien prefiere texto y control de versiones; el HTTPS es automático
NPMplus	AGPL 3.0	Panel web, es una bifurcación	Quien quiere el mismo panel con HTTP/3 y más opciones
SWAG	GPL 3.0	Ficheros de Nginx	Quien ya domina Nginx y quiere Certbot incluido
HAProxy 3.4	GPL 2.0	Fichero de texto	Repartir carga entre varios servidores con alto tráfico
Cloudflare Tunnel	Servicio de un tercero	Panel de Cloudflare	Publicar sin IP pública ni puertos abiertos

Por tanto, la elección depende del equipo más que de la tecnología. Si quien lo va a administrar no quiere escribir configuración, el panel gana. En cambio, si ya trabaja con infraestructura como código, Traefik o Caddy encajan mejor. Además, el túnel de Cloudflare resuelve un problema distinto: su servidor abre la conexión hacia afuera, así que no hace falta una IP pública.

Preguntas frecuentes sobre Nginx Proxy Manager

¿Nginx Proxy Manager es gratis?

Sí. Es software libre con licencia MIT, sin versión de pago y sin límite de hosts. Además, los certificados de Let’s Encrypt tampoco cuestan. Lo único que usted paga es el servidor donde corre y el dominio.

¿Cuál es el usuario y la contraseña por defecto?

Ya no hay. Hasta la versión 2.12 eran admin@example.com y changeme. En cambio, desde la 2.13.0 el panel pide crear el administrador en el primer ingreso. Si esas credenciales le funcionan, tiene una versión antigua, sin correcciones de seguridad.

¿Se puede instalar Nginx Proxy Manager sin Docker?

De forma oficial, no. La documentación responde que el proyecto se empaqueta así para controlar las versiones de Nginx y de sus dependencias. Sin embargo, existen instalaciones de terceros, como el guion comunitario para Proxmox, que el autor no atiende.

¿Qué diferencia hay entre Nginx y Nginx Proxy Manager?

Nginx es el servidor web y proxy inverso; se configura con ficheros de texto. En cambio, Nginx Proxy Manager es un panel que escribe esos ficheros y gestiona los certificados. Es decir, uno es el motor y el otro es el tablero.

¿Sirve como balanceador de carga?

No desde el panel. Cada host envía las visitas a un solo destino. Por tanto, para repartirlas entre varios servidores hay que escribir la configuración de Nginx a mano o usar una herramienta pensada para eso.

¿Necesito abrir puertos para tener HTTPS?

Depende del desafío. Con el desafío HTTP, sí: el puerto 80 debe llegar a su servidor. En cambio, con el desafío DNS no hace falta abrir nada, y además permite certificados comodín.

¿NPM y npm son lo mismo?

No. A este proyecto se le abrevia NPM, pero npm es también el gestor de paquetes de Node.js, que no tiene relación. Por eso conviene buscar siempre el nombre completo.

Cómo lo aborda KHARONTE

Un proxy inverso es la última pieza de una cadena: antes están el firewall que reenvía los puertos, la red que separa los servidores del resto y el equipo donde corre todo. Esa cadena es el trabajo de nuestra línea de redes y conectividad. Diseñamos, instalamos y administramos la red de la empresa: el firewall perimetral con sus reglas y la publicación de servicios, la segmentación por VLAN y las VPN para quienes trabajan fuera.

Además, los servidores y las máquinas virtuales donde viven estas herramientas hacen parte de nuestra línea de infraestructura de TI. Cada cambio entra como caso en nuestra mesa de ayuda TI, con su criticidad y su historial. No comercializamos los equipos.

Si prefiere un técnico dedicado a su plataforma, lo ofrecemos como outsourcing de infraestructura de TI. Y si busca servicios administrados de TI que reúnan la red, los servidores y el soporte, conozca el resto de nuestros servicios de TI para empresas.