Proxy inverso con Apache para Nginx Proxy Manager

Si ya tenés Apache corriendo en tu VPS y querés que Nginx Proxy Manager (que vive en un contenedor Docker) responda en ngx.iquipedigital.com en vez de en http://210.192.2.190:8081, la solución es montar Apache como proxy inverso adelante del contenedor. Apache recibe el tráfico del subdominio, lo reenvía al puerto 8081 interno y vos accedés con una URL limpia y, después, con HTTPS.

Un proxy inverso Apache Nginx es una configuración donde un servidor web (Apache) recibe las peticiones de internet y las reenvía a otro servicio interno (en este caso Nginx Proxy Manager dentro de Docker). Sirve para exponer varios servicios bajo distintos dominios desde una sola IP pública, agregar SSL y ocultar puertos internos. La administración queda del lado del operador del VPS.

¿Por qué necesitás un reverse proxy si ya tenés Apache?

Ponele que en tu VPS tenés Apache sirviendo un par de sitios y, además, levantaste Nginx Proxy Manager en Docker para gestionar otros servicios. El problema aparece rápido: NPM escucha en el puerto 8081, así que la única forma de entrar es tipear la IP y el puerto a mano. Feo, difícil de recordar y sin SSL.

Acá viene lo bueno: dos servicios distintos no pueden escuchar el puerto 80 al mismo tiempo. Si Apache ya lo ocupa, no podés simplemente “mover” NPM ahí. La salida elegante es que Apache se quede como portero de la entrada y reparta el tráfico según el dominio que pidió el visitante. El que pregunta por ngx.iquipedigital.com va al contenedor; el resto, a los sitios de siempre. Hablamos de esto en detalle en nuestro artículo sobre automatizar cambios con pipelines modernos.

Es la arquitectura típica de cualquier VPS con varios servicios. Y si estás armando esta infra desde cero, conviene arrancar con un hosting o VPS confiable donde tengas acceso root y puertos abiertos sin pelearte con el soporte.

Paso 1: Configurar el DNS para que el subdominio apunte a tu VPS

Antes de tocar Apache, el dominio tiene que resolver a tu servidor. Entrá al panel de tu proveedor DNS (en el ejemplo de la fuente, Hostman, pero da igual cuál uses) y creá un registro A.

• Tipo de registro: A (apunta un nombre a una IPv4).
• Host / nombre: ngx (para el subdominio ngx.iquipedigital.com).
• Valor: la IP pública de tu VPS, en este caso 210.192.2.190.
• TTL: dejalo en automático o 3600 segundos si querés cambios más ágiles.

Ojo con la propagación. Puede tardar desde unos minutos hasta 24-48 horas según el TTL anterior. Para no quedarte adivinando, verificá con dig ngx.iquipedigital.com o nslookup hasta que te devuelva la IP correcta. Si todavía resuelve a otra cosa, esperá: configurar Apache antes de que el DNS propague no sirve de nada.

Paso 2: Crear un VirtualHost en Apache para Nginx Proxy Manager

Ahora sí, el corazón del asunto. Vas a crear un archivo de configuración nuevo dentro de /etc/apache2/sites-available/, según la guía de dev.to.

nano /etc/apache2/sites-available/ngx.iquipedigital.com.conf

Adentro va un bloque VirtualHost que escucha el puerto 80 y reenvía todo al contenedor:

<VirtualHost *:80>
 ServerName ngx.iquipedigital.com

 ProxyPreserveHost On
 ProxyPass / http://127.0.0.1:8081/
 ProxyPassReverse / http://127.0.0.1:8081/

 ErrorLog ${APACHE_LOG_DIR}/ngx_error.log
 CustomLog ${APACHE_LOG_DIR}/ngx_access.log combined
</VirtualHost>

¿Qué hace cada cosa? ServerName le dice a Apache qué dominio atiende este bloque. ProxyPass manda las peticiones entrantes al puerto 8081 de la propia máquina (por eso 127.0.0.1, no la IP pública). ProxyPassReverse hace el trabajo inverso: reescribe las cabeceras de respuesta para que las redirecciones que genera NPM apunten a tu dominio y no al puerto interno. Sin esa línea, el panel de login te puede tirar a :8081 y romper la experiencia. Lo explicamos a fondo en nuestro artículo sobre orquestar deployments de forma automática.

¿Qué módulos de Apache tenés que habilitar?

Esto es lo que más gente se olvida. Apache no sabe hacer proxy “de fábrica”: necesita módulos cargados. Si no los activás, el VirtualHost no falla al guardarse, pero te tira 502 cuando entrás.

• mod_proxy: el motor base del proxy. Sin esto, nada funciona.
• mod_proxy_http: habilita el reenvío sobre HTTP/HTTPS hacia el contenedor.
• mod_ssl: necesario para servir HTTPS (lo vas a usar en el Paso de SSL).
• mod_rewrite: opcional, útil si después querés forzar la redirección de HTTP a HTTPS.

Los activás con a2enmod:

a2enmod proxy proxy_http ssl rewrite

¿Cómo confirmás que quedaron? Corré apache2ctl -M y fijate que aparezcan proxy_module y proxy_http_module en la lista. Si no están y entrás al sitio, vas a ver el clásico 502 Bad Gateway. No es un bug del contenedor: es Apache que no sabe a dónde mandar el tráfico.

Activar el sitio y recargar Apache

Tenés el archivo, tenés los módulos. Falta decirle a Apache que use esa configuración:

a2ensite ngx.iquipedigital.com.conf
systemctl reload apache2

a2ensite crea el enlace simbólico que activa el sitio. reload aplica la config sin cortar las conexiones actuales (si algo quedó raro, usá systemctl restart apache2 para un reinicio completo). Antes de recargar, conviene un apache2ctl configtest: si te devuelve Syntax OK, vas tranquilo. Esto se conecta con lo que analizamos en gestionar múltiples dominios en producción.

Para probar desde el propio servidor, sin depender del navegador, tirá un curl -I http://127.0.0.1:8081. Si responde, el contenedor está vivo. Después probá curl -I http://ngx.iquipedigital.com y mirá que la cabecera sea un 200 o un 301 hacia el login. ¿Algo falla? Los logs están en /var/log/apache2/, justo en los archivos ngx_error.log y ngx_access.log que definiste en el VirtualHost.

Asegurar la conexión con SSL/TLS

Hasta acá el subdominio anda, pero por HTTP plano. Para producción eso no va: el panel de NPM pide credenciales y mandarlas sin cifrar es pedir problemas. La forma estándar y gratis es Let’s Encrypt con Certbot.

• Instalá Certbot con el plugin de Apache: en Debian/Ubuntu, apt install certbot python3-certbot-apache.
• Emití el certificado: certbot --apache -d ngx.iquipedigital.com. Certbot detecta tu VirtualHost y arma el bloque :443 solo.
• Forzá HTTPS: cuando Certbot te pregunte, elegí redireccionar todo el tráfico HTTP a HTTPS.
• Auto-renovación: el certificado dura 90 días y se renueva solo vía systemd timer. Probalo con certbot renew --dry-run.

Si querés chequear el certificado a mano, openssl s_client -connect ngx.iquipedigital.com:443 te muestra la cadena y la fecha de expiración. Eso sí: como el tráfico interno entre Apache y el contenedor viaja por 127.0.0.1, no hace falta cifrarlo. El SSL termina en Apache y listo.

Resolver problemas comunes: 502, 503 y timeouts

¿Y qué pasa cuando entrás y no carga? Lo primero: no asumas que está roto Apache. Casi siempre el problema es de a uno y se ve en los logs. Más contexto en ejecutar procesos locales sin intermediarios.

Error	Causa más probable	Cómo verificarlo
502 Bad Gateway	Falta mod_proxy o el contenedor está caído	apache2ctl -M y docker ps
503 Service Unavailable	NPM arrancando o sin recursos	docker logs del contenedor
Timeout / cuelgue	Firewall bloquea el puerto 8081 interno	curl 127.0.0.1:8081 desde el server
403 Forbidden	SELinux/AppArmor bloquea la conexión saliente	getenforce o aa-status

Un detalle que cuesta caro: en sistemas con SELinux activo (CentOS, Rocky, AlmaLinux) Apache no puede abrir conexiones de red salientes por defecto. Si el curl interno funciona pero el proxy no, corré setsebool -P httpd_can_network_connect 1. En Ubuntu con AppArmor el síntoma es parecido. Revisá también que el firewall (ufw o firewalld) no esté tapando el 8081 a nivel local.

Errores comunes que cometen hasta los que saben

• Apuntar el ProxyPass a la IP pública: si ponés http://210.192.2.190:8081 en vez de 127.0.0.1:8081, el tráfico sale a internet y vuelve. Usá siempre loopback.
• Olvidar ProxyPassReverse: el login carga pero las redirecciones te mandan al puerto crudo. La mitad del panel queda inservible.
• Configurar Apache antes de que propague el DNS: Certbot falla la validación porque el dominio todavía no resuelve a tu IP. Verificá con dig primero.

Preguntas Frecuentes

¿Cómo configurar Apache como proxy inverso para Nginx Proxy Manager?

Creá un archivo VirtualHost en /etc/apache2/sites-available/ con las directivas ProxyPass / y ProxyPassReverse / apuntando a http://127.0.0.1:8081/. Después activá el sitio con a2ensite y recargá Apache. Antes necesitás habilitar mod_proxy y mod_proxy_http.

¿Cómo accedo a Nginx Proxy Manager por un subdominio en vez del puerto 8081?

Creás un registro A en tu DNS que apunte el subdominio a la IP del VPS y configurás Apache para reenviar ese dominio al puerto 8081 interno. Así entrás por ngx.tudominio.com sin tipear el puerto, y con SSL podés usar HTTPS directo.

¿Qué módulos de Apache necesito para hacer reverse proxy?

Necesitás mod_proxy y mod_proxy_http como mínimo, más mod_ssl si vas a servir HTTPS. Los activás con a2enmod proxy proxy_http ssl y verificás que estén cargados con apache2ctl -M. Si falta alguno, vas a ver un error 502.

¿Por qué me da 502 Bad Gateway al configurar el proxy?

El 502 casi siempre significa que Apache no puede contactar el contenedor: o falta el módulo de proxy, o Nginx Proxy Manager no está corriendo. Verificá con docker ps que el contenedor esté arriba y con apache2ctl -M que proxy_module aparezca en la lista.

¿Puedo usar Apache y Nginx Proxy Manager en el mismo servidor?

Sí, mientras escuchen puertos distintos. Apache ocupa el 80 y el 443 públicos y hace de proxy inverso; Nginx Proxy Manager corre en Docker en el 8081 interno. Apache reparte el tráfico según el dominio solicitado, así que conviven sin pisarse.

Conclusión

Montar Apache como proxy inverso adelante de Nginx Proxy Manager te saca de encima el feo IP:8081 y te deja un subdominio limpio con HTTPS. La receta es corta: registro A en el DNS, VirtualHost con ProxyPass y ProxyPassReverse hacia 127.0.0.1:8081, los módulos mod_proxy y mod_proxy_http activos, y Certbot para el certificado. Lo importante es el orden. Si configurás Apache antes de que propague el DNS, o te olvidás un módulo, vas a perder media tarde persiguiendo un 502 que no era del contenedor. Verificá cada paso con curl y los logs, y la mayoría de los problemas se resuelven solos antes de llegar al navegador.

Fuentes

• Using Apache and Nginx Proxy Manager Together for Domain-Based Access – guía original en dev.to (junio 2026)
• Documentación oficial de mod_proxy – Apache HTTP Server
• Guía oficial de Nginx Proxy Manager
• Documentación de Certbot para Let’s Encrypt