Por qué un reverse proxy en su VPS
Un VPS expone una sola dirección IP pública. Detrás de esa IP puede ejecutar cinco, diez o veinte servicios en puertos internos distintos. Sin reverse proxy, exponer cada servicio en un puerto público implica abrir esos puertos en el firewall, gestionar manualmente los certificados TLS de cada uno e informar de ello a cada usuario. Un reverse proxy resuelve estos tres problemas de una sola vez: recibe todo el tráfico en los puertos 80 y 443, identifica el dominio solicitado y redirige la petición al contenedor interno correcto. Nginx Proxy Manager añade una capa de interfaz gráfica a esta mecánica: ningún archivo de configuración que escribir, ningún reload manual, y los certificados Let's Encrypt se gestionan con unos pocos clics. Resulta especialmente adecuado para las agencias que alojan varias aplicaciones de clientes en el mismo servidor, o para los desarrolladores independientes que ejecutan varios proyectos en paralelo.
NPM frente a la configuración manual de Nginx: 7 ventajas concretas
- Ningún archivo de configuración: cada proxy host se crea desde la interfaz web, sin sintaxis Nginx que memorizar.
- Certificados Let's Encrypt automáticos: NPM solicita, instala y renueva los certificados sin intervención. Wildcard posible mediante DNS challenge.
- Gestión centralizada: todos sus dominios, subdominios y redirecciones en una sola pantalla, en lugar de una decena de archivos en
/etc/nginx/sites-enabled/. - Listas de acceso (Access Lists) integradas: proteger un servicio por IP o por contraseña sin tocar la configuración de cada aplicación.
- Logs por host consultables en la interfaz: identificar un error 502 o un abuso sin entrar por ssh en el contenedor.
- Redirecciones HTTP→HTTPS y páginas 404 personalizadas configurables de forma visual.
- Descubrimiento por nombre de contenedor Docker: apuntar a
portainer:9000en lugar de a una IP interna inestable que cambia al reiniciar.
Requisitos previos con cifras antes de instalar NPM
NPM solo enruta tráfico, por lo que es ligero. Un VPS con 1 GB de RAM y 1 vCPU basta si NPM es el único servicio destacable. Si además aloja detrás de él las aplicaciones, dimensione según la suma de sus necesidades. Prevea 15 GB de disco SSD (certificados, base SQLite, logs). Software necesario: Docker Engine 28 o posterior (antes de la 28.0, un puerto publicado en 127.0.0.1 seguía siendo accesible desde la red local) y el plugin Compose v2 (docker compose, no el antiguo comando docker-compose). Red: los puertos 80 y 443 deben estar libres en el VPS, ya que NPM es su único ocupante. El puerto 81 queda reservado a la interfaz de administración; nunca debe exponerse directamente a Internet. DNS: apunte sus registros A a la IP del VPS antes de solicitar los certificados. Para un wildcard *.votre-domaine.com, hace falta una clave API de su proveedor DNS (Cloudflare, OVH, etc.).
Instalación y primera configuración de Nginx Proxy Manager
Instalar Docker en el VPS
En un servidor Debian/Ubuntu:
curl -fsSL https://get.docker.com | sh. Compruebe después:docker --versionydocker compose version. Si el plugin Compose no está presente, instale el paquetedocker-compose-plugincon apt.Crear la carpeta de trabajo y el archivo Compose
Cree
/opt/npmen el VPS. Dentro de esa carpeta, cree un archivodocker-compose.yml. Declare en él el servicio NPM con la imagenjc21/nginx-proxy-manager:latest, mapee los puertos80:80y443:443, publique la administración solo en la dirección de bucle local (127.0.0.1:81:81), añadarestart: unless-stoppedy defina dos volúmenes:./data:/datay./letsencrypt:/etc/letsencrypt.Arrancar el contenedor
Desde
/opt/npm, ejecutedocker compose up -d. Compruebe que el contenedor está en marcha:docker compose ps. El primer arranque puede tardar uno o dos minutos. Como el puerto 81 solo escucha en127.0.0.1, abra un túnel SSH desde su equipo (ssh -L 8181:127.0.0.1:81 usuario@IP_DU_VPS) y luego la interfaz enhttp://localhost:8181.Primera conexión y protección de la cuenta admin
Desde la versión 2.13.0 (noviembre de 2025), NPM ya no crea una cuenta por defecto: en el primer acceso, una pantalla de instalación le pide crear la cuenta de administrador, con una contraseña larga y única. Hágalo antes de cualquier otra acción: esta cuenta da acceso total a su infraestructura de enrutamiento. Para un despliegue automatizado, las variables
INITIAL_ADMIN_EMAILeINITIAL_ADMIN_PASSWORDcrean esa cuenta al arrancar; colóquelas en un archivo.env(contraseña generada conopenssl rand -base64 32), nunca en claro en el Compose. En una versión anterior existe la cuenta[email protected]/changeme: cámbiela de inmediato.Crear una red Docker compartida
Para que NPM pueda alcanzar sus contenedores de aplicación por su nombre, deben compartir la misma red Docker. Cree una red externa:
docker network create proxy. En eldocker-compose.ymlde NPM, declare esa red como externa. Haga lo mismo en el Compose de cada aplicación que quiera proxificar.Añadir un primer Proxy Host
En la interfaz: Proxy Hosts → Add Proxy Host. Indique el dominio (p. ej.
app.votre-domaine.com), elForward Hostname(nombre del contenedor o IP interna) y el puerto de la aplicación. Marque «Block Common Exploits». Si la aplicación usa WebSockets, active «Websockets Support».Activar el SSL de Let's Encrypt
En la pestaña SSL del Proxy Host, elija «Request a new SSL Certificate», acepte las condiciones de Let's Encrypt y marque «Force SSL». NPM contacta con los servidores ACME, valida el dominio mediante HTTP-01 e instala el certificado. Su servicio queda en HTTPS en unos segundos. La renovación es automática.
Proteger la interfaz de administración (puerto 81)
No confíe en
ufw deny 81: Docker encamina los puertos publicados antes de las reglas de ufw, que por tanto no los filtran. Lo que mantiene el puerto fuera de Internet es la publicación en127.0.0.1:81(paso 2). Para un acceso sin túnel, cree después un Proxy Host dedicado —por ejemplonpm.votre-domaine.com→localhost:81— con SSL y una Access List restringida a su IP de gestión. Así accede a la interfaz por HTTPS sin exponer el puerto 81 al resto del mundo.Certificado wildcard mediante DNS challenge
Para cubrir todos sus subdominios con un solo certificado, use el DNS challenge. En la pestaña SSL, seleccione «Use a DNS Challenge», elija su proveedor (Cloudflare, OVH…) e indique la clave API. NPM crea un registro TXT en su zona DNS, valida la propiedad del dominio y obtiene el certificado
*.votre-domaine.com.Probar la cadena completa
Desde un terminal:
curl -I https://app.votre-domaine.com. Espere un código200o el código de su aplicación. Compruebe también la redirección HTTP:curl -I http://app.votre-domaine.comdebe devolver un301hacia la versión HTTPS.
Configuración avanzada
NPM expone en su interfaz varias funcionalidades que van más allá del simple reverse proxy. Las Access Lists permiten restringir el acceso a un host por rango de IP, por credenciales HTTP Basic Auth, o por una combinación de ambos, algo útil para proteger un backoffice sin añadir autenticación en la propia aplicación. Los Streams gestionan el proxy TCP/UDP para los protocolos que no son HTTP (MySQL remoto, servidor de juegos, MQTT…). La sección Redirecciones crea reglas permanentes (301) o temporales (302) de un dominio o de una ruta hacia otra URL, sin que haga falta un servicio detrás. Las pestañas Avanzado de cada proxy host permiten inyectar configuración Nginx en bruto cuando la interfaz no cubre un caso particular (cabeceras de seguridad personalizadas, proxy_read_timeout ampliado para las peticiones largas de subida, etc.).
Endurecimiento: rate limiting en la pestaña Avanzado
NPM no expone ningún control de rate limiting en su interfaz básica, pero puede aplicarlo desde la pestaña «Advanced» del proxy host correspondiente. La zona compartida no puede declararse allí (limit_req_zone solo se admite en el bloque http, y la pestaña Advanced escribe en el bloque server): coloque limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m; en ./data/nginx/custom/http_top.conf, que NPM incluye al principio del bloque http. Después aplíquela en la pestaña Advanced: limit_req zone=api burst=10 nodelay;. Esto limita cada IP a 30 peticiones por minuto con un burst de 10, lo que basta para recortar el scraping o los intentos de fuerza bruta en un formulario de inicio de sesión sin bloquear a los usuarios legítimos.
Resolución de los errores más frecuentes
Estos son los cinco problemas más frecuentes que aparecen tras una instalación de NPM, con su diagnóstico directo.
Errores frecuentes y sus causas
- 502 Bad Gateway: NPM no alcanza su contenedor. Compruebe primero que el contenedor de la aplicación está en marcha (
docker ps) y que está en la misma red Docker que NPM (docker network inspect proxy). Compruebe después que elForward Hostnamecorresponde exactamente al nombre del servicio declarado en el Compose de la aplicación. - Certificado SSL pendiente o error ACME: Let's Encrypt debe poder alcanzar su servidor en el puerto 80 a través del dominio declarado. Compruebe que el registro DNS A apunta a la IP correcta, que el puerto 80 no está bloqueado por el firewall del VPS ni por un filtro de red aguas arriba, y que el dominio se resuelve desde el exterior (
dig app.votre-domaine.com). - Contenedor inaccesible mediante el nombre DNS de Docker: si apunta a
monapp:3000y obtiene un error de resolución, el contenedormonappno está en la misma red que NPM. Añada la redproxyen el Compose de la aplicación y vuelva a crear los contenedores (docker compose up -d --force-recreate). - Redirección infinita HTTP→HTTPS: ocurre cuando la propia aplicación efectúa su propia redirección HTTPS además de la de NPM. NPM ya envía la cabecera
X-Forwarded-Proto: configure la aplicación para que confíe en el proxy (ajuste «trusted proxies» o equivalente) y conozca así el protocolo real. Detrás de Cloudflare, compruebe también que el modo SSL/TLS es Full (strict): en Flexible, la redirección HTTPS del origen entra en bucle. - Interfaz de administración inaccesible tras un reinicio: asegúrese de que el servicio NPM tiene la directiva
restart: unless-stoppeden su Compose. Sin ella, Docker no volverá a arrancar el contenedor tras un reboot del VPS.
Nginx Proxy Manager frente a Traefik
Desplace la tabla
| Criterio | Nginx Proxy Manager | Traefik |
|---|---|---|
| Configuración | Interfaz web visual, ningún archivo que editar | Archivos YAML y labels de Docker |
| Curva de aprendizaje | Baja, accesible sin experiencia en Nginx | Más pronunciada, orientada a DevOps |
| SSL Let's Encrypt | Automático desde la interfaz, wildcard posible | Automático mediante configuración |
| Descubrimiento de servicios | Manual (nombre de contenedor o IP:puerto) | Automático mediante labels de Docker |
| Ideal para | Unos pocos servicios gestionados manualmente, setup claro | Entornos dinámicos y numerosos contenedores |
| Consumo de RAM | Muy bajo | Bajo |
| Logs por host | Consultables en la interfaz | Mediante un stack de logs externo |
| Gestión de accesos | Access Lists integradas (IP, contraseña) | Middlewares que hay que configurar |
Cuándo plantearse Traefik o Caddy
NPM encaja perfectamente para un parque de servicios estable cuyo número se mantiene bajo control. En cuanto gestiona despliegues dinámicos —contenedores que aparecen y desaparecen de forma automática, como en un entorno Kubernetes o con pipelines CI/CD que crean previews sobre la marcha—, Traefik resulta más adecuado: su descubrimiento de servicios mediante los labels de Docker evita volver a la interfaz por cada nuevo contenedor. Caddy es una buena alternativa si busca la sencillez de la configuración por archivo con certificados automáticos, sin interfaz web. En todos los casos, NPM puede convivir con Traefik o Caddy en el mismo VPS, gestionando cada uno una parte del tráfico, siempre que no ponga dos proxies en los mismos puertos 80 y 443. Si su infraestructura crece hasta el punto de gestionar varias decenas de servicios con equipos distintos, una malla de servicios (Consul Connect, Linkerd) sustituye con ventaja al apilamiento de proxies.
