Los certificados, el DNS y el reverse proxy son de esas capas que solo parecen aburridas hasta que fallan. El servicio sigue vivo, el contenedor está arrancado, la VM responde, pero el navegador enseña un error rojo o el nombre ya no resuelve. En casa eso tiene una gracia limitada. Si afecta a una herramienta que usas tú, molesta. Si afecta a algo que usa la familia, se convierte en otra cosa.
Con el tiempo he dejado de tratar HTTPS interno como una pieza decorativa. No lo reviso porque me guste coleccionar candados verdes. Lo reviso porque es una de las pocas partes del homelab donde una caducidad silenciosa puede tumbar una experiencia entera aunque el servidor esté perfecto.
Además, la presión va a subir. Let’s Encrypt explica en su FAQ que sus certificados estándar duran 90 días y recomienda renovar alrededor de los 60 días. También anunció que reducirá la duración hasta 45 días en 2028 en su nota sobre certificados de 45 días. Eso no es un drama si la renovación automática funciona. Sí es un problema si tu sistema depende de que te acuerdes de mirar algo cada trimestre.
Mi enfoque es sencillo: una vez al mes reviso nombres, certificados, rutas del proxy y alertas. No busco perfección. Busco saber que, si mañana reinicio el servidor o cambio una IP, no voy a descubrir un castillo de excepciones antiguas.
Este artículo encaja con la ruta de operación y monitorización y también con red y acceso remoto, porque DNS y proxy viven justo en la frontera entre “todo funciona” y “nadie entiende por qué esto carga desde el móvil pero no desde el portátil”.
Por qué lo revisaría junto#
Podría separar certificados, DNS y reverse proxy en tres tareas. Técnicamente son capas distintas. En la práctica, cuando falla una, acabas mirando las tres.
Un certificado no renueva porque el desafío ACME no llega al servicio correcto. Eso puede ser un problema de proxy, de DNS, de firewall o de un proveedor que cambió una API. Un servicio no carga por HTTPS porque el proxy apunta al puerto viejo. El DNS resuelve bien, pero el proxy entrega otro certificado porque hay una regla duplicada. O el certificado está bien, el proxy está bien y lo que falla es que el móvil está usando DNS del operador en vez del de casa.
La revisión conjunta evita perseguir síntomas sueltos. Yo la pienso como una cadena:
- El nombre existe y resuelve donde debe.
- El reverse proxy recibe esa petición.
- El proxy sabe a qué backend mandarla.
- El certificado está vigente y se renueva solo.
- Hay una alerta antes de que algo caduque.
Si una de esas piezas no se puede explicar en dos frases, probablemente necesita limpieza.
Inventario mínimo de nombres#
El primer paso no es abrir el proxy. Es saber qué nombres tienes.
En un homelab pequeño se empieza con dos o tres nombres y se acaba con una colección bastante alegre: paneles, automatizaciones, NAS, fotos, documentos, domótica, monitorización, pruebas, servicios retirados y dominios temporales que ya no deberían existir.
Mi inventario mínimo tendría estos campos:
- Nombre.
- Servicio.
- Uso: privado, familia, público o laboratorio.
- Proxy que lo atiende.
- Backend.
- Tipo de certificado.
- Fecha de última revisión.
- Qué pasa si falla.
No hace falta una base de datos. Puede ser un Markdown, una hoja sencilla o el mismo inventario operativo del homelab. Lo importante es que no dependa de recordar qué significaba panel2 dentro de seis meses.
Aquí soy bastante bruto con los nombres. Si un nombre no se usa, se borra. Si apunta a un servicio retirado, se borra. Si existe solo porque un día hice una prueba, se borra. Mantener DNS viejo es acumular polvo con consecuencias.
También separaría nombres por función. Los servicios familiares no deberían mezclarse mentalmente con pruebas. Un nombre para fotos, documentos o domótica merece más cuidado que un subdominio de laboratorio donde estoy probando una app que quizá borre mañana.
DNS interno: menos nombres, más claridad#
El DNS interno es cómodo hasta que empieza a parecer un cajón de cables. Cada entrada nueva parece inocente, pero juntas forman una red de dependencias que luego cuesta reconstruir.
Una vez al mes revisaría tres cosas.
La primera es que los nombres importantes resuelven desde los sitios donde deben resolver. No basta con probar desde el servidor. Hay que probar desde un portátil en la LAN, desde un móvil en WiFi, desde una VLAN de usuario si existe y desde Tailscale si lo usas para entrar desde fuera.
La segunda es que los nombres internos no se escapan hacia internet por accidente. Los paneles privados deberían vivir detrás de VPN, Tailscale o una red interna. Si un servicio solo lo uso en casa, no necesito publicarlo por comodidad mal entendida.
La tercera es que el TTL tenga sentido. Cloudflare define el TTL como el tiempo que un registro queda cacheado y explica en su documentación de DNS que un TTL largo mejora caché, pero hace más lentos los cambios. En casa no necesito hilar fino con esto, pero sí quiero recordar una cosa: si voy a migrar un servicio o cambiar IPs, bajo TTL antes. Si todo está estable, no lo toco cada semana.
Para DNS local, mi criterio sería este:
- Nombres de servicios usados por la familia: claros y estables.
- Nombres de administración: privados y sin exposición pública.
- Nombres de pruebas: con fecha o prefijo que haga evidente que pueden morir.
- Entradas antiguas: fuera.
Lo que no haría es usar .local como comodín para todo. Ya lo conté en mDNS en homelab: por qué .local no sustituye a un DNS decente. mDNS va bien para descubrimiento sencillo. Para servicios que quieres mantener, prefiero nombres explícitos y una configuración que pueda leer sin adivinar.
Certificados: mirar caducidad no es suficiente#
Ver que un certificado caduca dentro de 50 días está bien. Pero la pregunta real es otra: ¿sé que va a renovar?
El certificado vigente solo demuestra que el sistema funcionó una vez. La renovación automática demuestra que sigue funcionando. Por eso revisaría el mecanismo, no solo la fecha.
Si usas Caddy, su documentación de Automatic HTTPS explica que provisiona certificados TLS y los mantiene renovados cuando la configuración encaja. Es una de las razones por las que Caddy me gusta para instalaciones pequeñas. Hace pocas cosas, pero esta la hace con muy poca ceremonia.
Si usas Traefik, la documentación oficial de ACME deja claro que puedes usar resolvers de certificados y distintos tipos de desafío. Ahí hay más piezas que revisar: storage del ACME, permisos del archivo, challenge elegido, puertos alcanzables y credenciales DNS si usas DNS-01.
Con Nginx Proxy Manager pasa algo parecido. Es cómodo, pero no lo trataría como una caja negra eterna. Miraría la lista de certificados, comprobaría que los dominios siguen vivos y revisaría si hay certificados manuales que deberían haber sido automáticos.
Mi checklist mensual sería:
- Certificados que caducan en menos de 30 días.
- Certificados manuales que debería automatizar.
- Errores recientes de renovación.
- Credenciales DNS usadas para DNS-01.
- Servicios que ya no necesitan certificado.
- Backups de la configuración del proxy y del storage ACME.
No guardaría tokens DNS repartidos por medio homelab. Si uso DNS-01, los trato como credenciales sensibles. Permisos mínimos, documentación clara y copia segura. Un token con permiso amplio sobre el DNS de un dominio es una llave bastante seria.
Reverse proxy: rutas limpias o tarde perdida#
El reverse proxy se llena de reglas con una facilidad insultante. Un contenedor nuevo, una prueba rápida, un puerto que cambia, un host que migra, una regla temporal. A los dos meses nadie sabe por qué hay dos entradas parecidas apuntando a puertos distintos.
Una vez al mes revisaría cada host publicado:
- Nombre externo o interno.
- Backend real.
- Puerto.
- Protocolo hacia el backend.
- Cabeceras especiales.
- Websockets si aplica.
- Restricciones de acceso.
- Certificado asociado.
La parte que más problemas da no suele ser crear una regla. Es retirar la vieja.
Cuando migro un servicio, me obligo a buscar si queda una ruta anterior. Si un proxy sigue apuntando a una IP antigua, quizá no moleste hoy. Pero el día que esa IP la use otro servicio, el fallo será bastante confuso.
También revisaría qué servicios están publicados hacia fuera. Mi criterio es restrictivo: paneles de administración, dashboards, bases de datos, herramientas de backup y consolas deberían quedarse privados. Si necesito entrar desde fuera, uso Tailscale o VPN. Para exponer servicios con sentido ya hablé de las diferencias en Cloudflare Tunnel, Tailscale y VPN clásica.
El reverse proxy público lo reservaría para servicios que realmente deben recibir visitas externas o integraciones. Todo lo demás puede vivir feliz detrás de la red privada.
Una prueba real vale más que mirar paneles#
Los paneles engañan. Un certificado puede aparecer como válido y aun así el navegador puede recibir otro. Una regla puede estar activa y apuntar a un backend que responde con una página de login rota. El DNS puede resolver desde el servidor y fallar desde el móvil.
Por eso la rutina necesita pruebas desde fuera del propio servidor.
Yo probaría:
- Un portátil conectado a la red normal de casa.
- Un móvil en WiFi.
- Un dispositivo por Tailscale.
- Datos móviles para un servicio que deba ser público.
No hace falta recorrer todo el catálogo cada semana. Para la revisión mensual sí escogería los servicios críticos: fotos, documentos, contraseñas, domótica, monitorización y cualquier panel que uses para recuperar el resto.
La prueba mínima es abrir el servicio, comprobar que carga por HTTPS, verificar que el certificado pertenece al nombre esperado y confirmar que el login funciona. Parece poco. Es más de lo que hacen muchas instalaciones.
Si quieres automatizar parte de esto, un healthcheck HTTP puede avisar de caídas, pero no siempre detecta problemas humanos. Una respuesta 200 de una pantalla de error no es un servicio sano. Para servicios críticos me gusta combinar comprobación automática y revisión manual corta.
Orden de actuación si algo falla#
Cuando un servicio no carga, seguiría este orden:
- Resolver el nombre desde el cliente que falla.
- Confirmar a qué IP apunta.
- Comprobar si el proxy recibe tráfico.
- Revisar la regla del host.
- Probar el backend desde el proxy.
- Mirar el certificado entregado por el navegador.
- Revisar logs de renovación si el error es TLS.
Lo importante es no saltar directo al contenedor. Muchas veces el servicio está vivo. Lo que está roto es el camino.
Si el fallo afecta a un servicio familiar, primero busco restaurar acceso. Luego limpio. No me pongo a rediseñar DNS mientras alguien intenta ver fotos, abrir una receta o encender una luz. La operación doméstica tiene esta parte poco glamourosa: a veces la mejor decisión técnica es devolver el servicio y apuntar el arreglo bueno para después.
Cómo lo dejaría documentado#
La documentación útil no es un manual de 40 páginas. Es una nota que permite saber qué existe y cómo se recupera.
Para esta capa dejaría cuatro bloques:
- Tabla de nombres y servicios.
- Dónde vive el DNS.
- Qué reverse proxy atiende cada zona.
- Cómo se renuevan certificados.
También añadiría una sección de “fallos conocidos”. Por ejemplo, si un servicio necesita websockets, si una app no tolera cambiar de subruta, si un backend solo habla HTTP, si una regla depende de una cabecera concreta o si un certificado usa DNS-01 porque el servicio no es público.
Esto ahorra horas. No por brillante. Por obvio. El día que estás cansado, lo obvio documentado gana.
Mi rutina mensual#
La dejaría así:
- Revisar inventario de nombres.
- Borrar entradas DNS muertas.
- Probar resolución desde LAN, móvil y acceso remoto.
- Revisar certificados próximos a caducar.
- Confirmar que la renovación automática no da errores.
- Revisar reglas del reverse proxy.
- Probar los servicios críticos desde un cliente real.
- Actualizar la nota operativa.
Si la revisión tarda más de 30 minutos, probablemente hay demasiadas piezas sin dueño. Ahí no añadiría más automatización todavía. Primero reduciría ruido.
También evitaría convertir esto en una ceremonia semanal. DNS, certificados y proxy no necesitan que los mires cada mañana si hay alertas razonables. Necesitan una revisión periódica y una alarma antes de caducar. Nada más.
Dónde pondría las alertas#
Como mínimo, quiero aviso si un certificado caduca pronto. No el mismo día. Antes. Entre 20 y 30 días me parece margen cómodo para casa. Si Let’s Encrypt va reduciendo duración, ese margen tendrá que revisarse.
También avisaría si un servicio crítico devuelve error desde fuera del host donde vive. Una prueba local dentro del contenedor vale para una cosa. Una prueba desde otro punto de la red vale para otra.
Para DNS, no me obsesionaría con alertar cada cambio. Sí mantendría registro de cambios si gestionas DNS con infraestructura como código. Si lo haces a mano, apuntaría cambios importantes en la nota de operación mensual.
El objetivo es detectar caducidades, rutas rotas y nombres fantasma. No construir un SOC doméstico para saber que el proxy tosió a las 03:17.
Lo que no complicaría#
No montaría una PKI interna para todo el mundo salvo que tenga un motivo claro. Puede tener sentido, pero para muchos homelabs añade distribución de CA raíz, problemas en móviles, errores raros y más documentación. Para servicios internos con nombres reales y DNS-01, un certificado público válido puede ser más práctico aunque el servicio no sea público.
No publicaría paneles internos solo para que Let’s Encrypt renueve por HTTP-01. Si necesito certificados para servicios privados, prefiero DNS-01 o un proxy que pueda gestionar bien la renovación sin abrir administración al exterior.
No mezclaría reglas temporales con reglas familiares sin marcarlo. Las pruebas deben oler a prueba. Nombre claro, fecha y retirada.
Y no delegaría toda la confianza en una interfaz bonita. Nginx Proxy Manager, Traefik, Caddy o cualquier otra opción pueden estar perfectamente configurados. También pueden conservar basura durante meses si nadie limpia.
La señal de que está bien montado#
Una capa de DNS, certificados y reverse proxy está bien cuando deja de ser tema de conversación.
Los nombres son legibles. Los certificados renuevan solos. Los servicios críticos cargan desde donde deben. Las reglas antiguas desaparecen. Las alertas avisan con margen. Y si algo falla, la nota operativa permite seguir el camino sin reconstruir media historia.
No es la parte más divertida del homelab. Pero pocas cosas dan tanta tranquilidad por tan poco tiempo mensual.
Si ya tienes una rutina de mantenimiento mensual del homelab, esta sería una sección fija dentro de ella. Si todavía no la tienes, empieza por aquí. HTTPS roto y DNS confuso son dos formas muy rápidas de convertir una tarde tranquila en una sesión de arqueología técnica.