Un reverse proxy interno es una de esas piezas que parecen opcionales hasta que montas cinco servicios y empiezas a entrar a todo con puertos raros. Primero tienes http://servidor:8123, luego http://servidor:9000, después otra app en el NAS, otra en Docker, otra en Kubernetes y al final tu navegador parece una colección de matrículas.
Yo tardé más de lo razonable en tomármelo en serio. Al principio me bastaba con guardar favoritos. Luego empecé a usar nombres locales. Después llegaron los certificados, los contenedores, algún servicio expuesto por túnel y la típica pregunta incómoda: ¿esto lo estoy ordenando o solo estoy moviendo el caos a otra capa?
Ahí es donde el reverse proxy deja de ser una comodidad y se convierte en arquitectura doméstica. No arquitectura de póster. Arquitectura de la que se nota cuando falla.
La comparación habitual es Nginx Proxy Manager contra Traefik. Tiene sentido, aunque a veces se plantea mal. No creo que uno sea simplemente mejor que el otro. Creo que encajan en momentos distintos del homelab. Y, si soy sincero, usar Traefik demasiado pronto me parece una forma estupenda de complicarse la vida con una sonrisa técnica.
Qué problema intento resolver#
En casa busco cuatro cosas bastante concretas.
La primera es no tener que recordar puertos. Quiero abrir photos.home.arpa, docs.home.arpa o router.home.arpa y llegar al sitio correcto. Parece menor, pero cuando un servicio lo usa más gente en casa, el puerto raro deja de ser un detalle y pasa a ser fricción.
La segunda es centralizar certificados. Incluso en una red interna, el navegador se queja si todo va por HTTP o si usas certificados raros. Puedes vivir con avisos, claro. También puedes vivir con cables por el suelo. No significa que sea buena idea.
La tercera es separar entrada de aplicación. El servicio no tiene por qué saber si fuera lo llaman por un dominio bonito, por un túnel o por una IP interna. El proxy recibe, decide y reenvía. Esa separación ayuda mucho cuando migras contenedores o cambias una app de servidor.
La cuarta es tener un punto claro donde aplicar reglas. No todo tiene que estar expuesto igual. Algunas apps solo deberían estar en LAN. Otras pueden ir por VPN. Otras quizá pasan por Cloudflare Tunnel. Si cada servicio se publica a su manera, acabas con una mezcla difícil de auditar.
Ese es el problema real. No es “quiero aprender Traefik”. Eso puede ser divertido, pero no es una necesidad.
Mi punto de partida: DNS antes que proxy#
Antes del reverse proxy pongo DNS interno. Sin DNS decente, el proxy se queda cojo.
Para casa prefiero usar nombres claros y previsibles. Algo tipo home.arpa, que está reservado precisamente para redes domésticas, o un subdominio interno de un dominio propio si sabes lo que haces. Lo importante es no depender de .local para todo. .local tiene su sitio con mDNS, pero no me gusta usarlo como base de una infraestructura que empieza a crecer.
Mi esquema mental es simple:
- DNS local resuelve nombres internos.
- El reverse proxy atiende esos nombres.
- Los servicios viven donde tengan que vivir.
- El firewall decide desde qué redes se puede llegar.
Si el DNS falla, el proxy puede estar perfecto y aun así nadie llega de forma cómoda. Por eso no lo trato como un accesorio. En un homelab familiar, DNS y proxy suelen convertirse en pareja de hecho.
También intento evitar nombres demasiado listos. paperless.home.arpa es mejor que doc-stack-prod-01.home.arpa. En casa no necesitas demostrar que has leído un manual de nomenclatura corporativa. Necesitas acordarte de las cosas un domingo por la tarde.
Nginx Proxy Manager: el martillo cómodo#
Nginx Proxy Manager me parece una herramienta muy buena para la mayoría de homelabs pequeños y medianos. Tiene una interfaz clara, añade hosts en dos minutos, gestiona certificados sin convertirlo todo en una clase de YAML y permite resolver el 80 por ciento del problema con muy poca ceremonia.
Su mayor virtud es esa: reduce el coste mental.
Si tienes varios servicios en Docker Compose, un NAS, un par de VMs y quieres nombres bonitos con HTTPS, Nginx Proxy Manager suele ser suficiente. Entras, creas un proxy host, pones dominio, IP, puerto, certificado y listo. No es glamuroso. Me da igual. Funciona.
Esto importa más de lo que parece. Un homelab no es una empresa con un equipo de plataforma. Muchas veces eres tú, de noche, cansado, queriendo arreglar una cosa sin romper tres. En ese contexto, una UI sencilla puede ser mejor que una configuración elegante.
También es fácil de explicar. Si mañana tienes que recordar cómo está publicado un servicio, lo ves en una lista. Si algo falla, puedes revisar el host, el certificado y el destino sin bucear por labels repartidas en varios compose.
Pero Nginx Proxy Manager tiene límites. Y conviene reconocerlos antes de cargarlo con responsabilidades que no lleva bien.
Dónde empieza a chirriar Nginx Proxy Manager#
El primer límite aparece cuando todo cambia a menudo. Si levantas y tiras servicios con frecuencia, añadir hosts a mano acaba cansando. No es grave con cinco apps. Con veinte, empieza a dar pereza.
El segundo límite aparece cuando quieres que la configuración viva junto a los servicios. En Docker Compose, Traefik puede leer labels y descubrir rutas. En Kubernetes, puede integrarse con IngressRoute o recursos similares. Nginx Proxy Manager, en cambio, suele vivir más como una pieza manual.
Eso no es malo por definición. De hecho, para servicios críticos de casa a veces me gusta que el proxy no se actualice mágicamente con cada experimento. Pero si tu homelab se parece más a una plataforma dinámica, la gestión manual se vuelve menos cómoda.
El tercer límite es la repetición. Mismos patrones, mismos headers, mismas redirecciones, mismas excepciones. Se puede manejar, pero no siempre con la limpieza que te gustaría.
El cuarto límite es que la UI también puede ser una trampa. Si todo se configura a mano y no documentas nada, el proxy se convierte en una cajita con secretos. Funciona hasta que tienes que reconstruirlo. Por eso, incluso con Nginx Proxy Manager, intento tener una nota simple con dominios, destinos y motivo de cada entrada.
Traefik: potente, pero no gratis#
Traefik empieza a tener sentido cuando el homelab se vuelve más dinámico o más declarativo. Si tus servicios nacen desde Docker Compose, si tienes Kubernetes, si quieres que las rutas estén versionadas con la propia app o si necesitas middlewares reutilizables, Traefik encaja muy bien.
Me gusta especialmente cuando cada servicio declara cómo quiere ser publicado. En vez de entrar en una UI y apuntar manualmente a un puerto, el servicio lleva sus labels o su manifiesto. Eso hace que mover, reconstruir o desplegar sea más repetible.
También me gusta para Kubernetes. Ahí Nginx Proxy Manager se siente un poco fuera de sitio. Puedes usarlo delante, claro, pero Traefik habla mejor el idioma del cluster. Ingress, servicios, certificados, namespaces, reglas. Si ya estás en ese mundo, tiene sentido no fingir que todo es una VM con un puerto.
Ahora viene la parte menos bonita: Traefik exige más cabeza.
La configuración inicial puede ser confusa. Routers, services, entrypoints, middlewares, providers, resolvers. La terminología tiene lógica, pero la primera vez se siente como pagar peaje antes de tener carretera. Además, cuando algo no enruta, el fallo puede estar en DNS, labels, red Docker, certificados, entrypoints, prioridades o una tontería de comillas.
No digo esto para asustar. Digo que Traefik merece la pena cuando su modelo te ahorra más trabajo del que añade. Si solo tienes seis servicios estáticos, quizá no.
Mi regla práctica para elegir#
La regla que uso ahora es bastante clara.
Uso Nginx Proxy Manager cuando los servicios son pocos, estables y quiero operar rápido. Apps familiares, servicios internos, paneles de administración, multimedia, documentos, contraseñas, Home Assistant, cosas que no cambian cada dos días.
Uso Traefik cuando la publicación forma parte del despliegue. Docker Compose versionado, stacks que se mueven, Kubernetes, entornos de prueba, servicios que nacen y mueren, rutas que quiero revisar en Git.
También mezclo capas si hace falta. No tengo problema en tener Traefik dentro de un entorno dinámico y un proxy frontal más simple para entradas internas o externas concretas. Lo que intento evitar es una cadena absurda de proxies donde nadie recuerda quién termina TLS, quién reescribe headers y quién tiene la culpa cuando algo da 502.
Una cadena aceptable sería:
- DNS interno apunta al proxy principal.
- El proxy principal enruta servicios estables.
- Traefik gestiona un bloque dinámico concreto, por ejemplo Kubernetes.
Una cadena mala sería:
- Router reenvía a un proxy.
- Ese proxy manda a otro proxy.
- El segundo proxy manda a Traefik.
- Traefik manda a una app que también trae su propio proxy.
- Nadie sabe dónde se perdió el header real del cliente.
En casa, cuanto más larga es la cadena, más probable es que estés comprando problemas futuros.
Certificados internos sin volverse loco#
El tema de certificados merece calma. Para servicios expuestos públicamente, Let’s Encrypt es cómodo. Para servicios internos, tienes varias opciones.
Puedes usar DNS challenge con un dominio real y emitir certificados válidos para nombres internos. Es limpio, pero implica depender de un proveedor DNS y guardar credenciales con cuidado. También puedes usar una CA interna, que está muy bien si controlas los dispositivos, pero en móviles, tablets y equipos de familiares puede ser más trabajo del que apetece.
Mi preferencia depende del servicio. Para cosas que uso solo yo desde equipos controlados, una CA interna puede valer. Para servicios que quiero abrir desde varios dispositivos sin pelearme con avisos, prefiero certificados válidos mediante DNS challenge.
Lo que no me gusta es aceptar avisos de navegador como estado permanente. Es una mala costumbre. Al principio molesta poco. Luego normalizas ignorar avisos de seguridad. Y eso sí que es una idea floja.
Seguridad: el proxy no arregla una mala red#
Un reverse proxy no sustituye al firewall. Esto parece obvio, pero en homelab se olvida fácil.
Publicar una app detrás de un proxy no la hace segura. Solo cambia cómo llega el tráfico. Si una aplicación no debería ser accesible desde invitados, IoT o Internet, la regla buena está en la red, no solo en el proxy.
Yo separo así:
- Servicios solo internos: DNS interno, proxy interno, acceso desde LAN o VPN.
- Servicios familiares: acceso desde LAN, quizá VPN, con autenticación propia fuerte.
- Servicios externos: pocos, bien elegidos, con actualizaciones y logs.
- Paneles administrativos: nunca abiertos por comodidad.
El reverse proxy ayuda a ordenar, pero no compensa publicar demasiadas cosas. De hecho, cuanto más fácil es publicar servicios, más disciplina necesitas para no abrir medio homelab porque “ya que estoy”.
También reviso una cosa muy concreta: qué pasa si el proxy cae. Si todo depende de él, necesito saber cómo entrar a lo importante por una ruta alternativa. Quizá una IP interna, quizá VPN, quizá acceso directo temporal. No para usarlo a diario, sino para no quedarme fuera por mi propia comodidad.
Cómo lo plantearía si empezara hoy#
Si empezara un homelab doméstico desde cero, haría esto.
Primero montaría DNS interno sencillo. Pocos nombres, claros, documentados.
Después pondría Nginx Proxy Manager para servicios estables. Lo dejaría en una VM o contenedor con backup claro de configuración. Nada de convertirlo en un experimento más.
Luego definiría qué servicios son internos de verdad. Los paneles de administración, NAS, Proxmox, dashboards y herramientas sensibles no necesitan exposición externa alegre.
Si más adelante meto Kubernetes o un entorno Docker más dinámico, añadiría Traefik dentro de esa zona. No como sustituto automático de todo, sino como herramienta para esa parte del homelab.
Y documentaría el mapa. Una tabla simple basta: dominio, destino, puerto, quién lo usa, cómo se restaura. Parece aburrido, pero cuando algo rompe a las once de la noche esa tabla vale más que cualquier dashboard bonito.
Lo que haría distinto#
La tentación técnica es montar Traefik pronto porque parece más serio. Hoy no lo haría así. Empezaría con lo que reduce fricción y solo añadiría complejidad cuando me devuelva algo tangible.
También evitaría publicar servicios por impulso. Cada app nueva con dominio bonito parece inofensiva. Pero cada entrada es otra cosa que mantener, actualizar, respaldar y entender.
El reverse proxy interno ideal en casa no es el más sofisticado. Es el que puedes reconstruir sin drama, explicar en cinco minutos y tocar sin miedo. Para muchos homelabs, eso es Nginx Proxy Manager. Para entornos más vivos, Traefik empieza a brillar.
La clave está en no confundir madurez con complejidad. Un homelab maduro no es el que usa la herramienta más potente. Es el que sigue funcionando cuando tú no tienes ganas de pelearte con él.