Proxy

Problema En entornos donde Nginx actúa como reverse proxy para uno o varios contenedores Docker, es frecuente encontrarse con respuestas 502 Bad Gateway o logs que indican connect() failed (111: Connection refused) while connecting to upstream. El síntoma típico es que el cliente (navegador, curl, Cloudflare Tunnel) llega a Nginx, pero Nginx no puede establecer la conexión TCP con el backend. El error se manifiesta como: 2026/07/05 02:31:31 [error] 22#22: *7 connect() failed (111: Connection refused) while connecting to upstream, client: X.X.X.X, server: example.com, request: "GET / HTTP/1.1", upstream: "http://172.29.0.2:8086/", host: "media.example.com" Este patrón aparece en cualquier stack que combine: ...

Problema En muchos homelabs los servicios internos (Forgejo, Home Assistant, etc.) necesitan HTTPS para evitar advertencias del navegador y para que otras aplicaciones confíen en ellos. El obstáculo típico es que el dominio público está asociado a una IP pública, mientras que los servicios residen en redes privadas (192.168.x.x). Cuando se crea un registro DNS que apunta directamente a la IP interna, los resolvers externos no pueden resolverlo y los clientes locales obtienen “Server not found”. Además, Let’s Encrypt rechaza la emisión de certificados si el dominio no es accesible públicamente o si la validación DNS‑01 falla por una configuración incorrecta del servidor DNS interno. ...

Problema En entornos donde una aplicación monolítica se ejecuta dentro de un contenedor y expone dos procesos –por lo general un frontend (Next.js, React, etc.) y un backend (NestJS, Express, etc.)– es frecuente colocar un servidor Nginx como reverse proxy interno. Cuando el proxy no logra establecer la conexión con el proceso backend, los navegadores devuelven un 502 Bad Gateway y, en la práctica, la UI queda atrapada en un bucle de carga (por ejemplo, al intentar iniciar sesión). El síntoma típico es una petición POST /api/... que nunca finaliza y, en los logs de Nginx, aparece: ...

Problema Al ejecutar wg‑easy dentro de un contenedor Docker en un router OpenWrt, los clientes WireGuard establecen la conexión pero pierden la capacidad de alcanzar tanto la LAN como la WAN. Las peticiones DNS (por ejemplo a 1.1.1.1) nunca llegan, y cualquier intento de ping a la puerta de enlace local devuelve Destination Port Unreachable. El síntoma típico es una interfaz tun0 activa en el cliente, tráfico visible en el contenedor, pero sin rutas de salida hacia la red del router ni hacia Internet. ...

Problema Muchas organizaciones usan Let’s Encrypt para automatizar la emisión de certificados TLS. Cuando el dominio está detrás de un firewall o no se puede servir HTTP, la validación DNS‑01 es la única opción viable. La API del proveedor DNS necesita credenciales (clave API, token, usuario/contraseña) y, en entornos sin una estrategia centralizada, esas credenciales terminan copiadas a cada servidor que ejecuta el cliente ACME. El patrón típico es: Un script de solicitud de certificado en cada host. Variables de entorno o archivos de configuración con la clave del DNS. Credenciales estáticas que permanecen en el disco indefinidamente. Este enfoque genera varios riesgos: exposición accidental, rotación imposible, falta de auditoría y, cuando se necesita un proceso de aprobación interno, no hay control sobre quién puede solicitar certificados. El problema se vuelve crítico al intentar desplegar certificados en dispositivos de borde (IPMI, impresoras, appliances) que no pueden almacenar secretos de forma segura. ...

Problema Muchos usuarios que autohospedan Navidrome quieren evitar la gestión de credenciales locales y delegar la autenticación a un proveedor externo (por ejemplo, Authentik). El reto surge cuando el reverse proxy no está configurado para reenviar la información de sesión o cuando el flujo OAuth2 no se completa porque falta un contenedor de “auth‑proxy”. El síntoma típico es que Navidrome muestra la página de login pero nunca redirige al usuario, o que la cabecera X-User esperada por Navidrome está vacía. ...

Problema En entornos Docker Swarm con un reverse proxy (por ejemplo, Traefik) y un proveedor de identidad (Authelia, Keycloak, etc.) es frecuente que los servicios que implementan OAuth2 necesiten redirigir al usuario a una URL de callback que apunta al host del clúster (ej. auth.example.com). Los contenedores que forman parte de una overlay network de Swarm no pueden alcanzar directamente la IP del nodo host ni el nombre DNS que resuelve a esa IP. La resolución DNS funciona, pero la petición nunca llega porque Docker aísla la red del contenedor del stack de red del host. El síntoma típico es: ...

Problema En entornos de auto‑hosting es frecuente combinar un contenedor que necesita salir a Internet (por ejemplo, qbittorrent) con una VPN basada en WireGuard. La práctica consiste en montar un archivo wg0.conf dentro del container y delegar la resolución DNS a un resolvedor interno como Unbound. Cuando la configuración parece correcta pero cualquier llamada a curl, ping o la propia aplicación muestra errores de tipo “Could not resolve host”, el contenedor queda sin acceso a la red externa aunque la interfaz wg0 esté UP. ...

Problema En entornos de auto‑hosting es frecuente combinar wg‑easy (interfaz web para WireGuard) con Caddy como terminador TLS y reverse proxy. El objetivo es acceder a https://wg-easy.example.com sin exponer puertos internos. Un síntoma típico es el mensaje del navegador “Can’t connect to the server” o un error de conexión TCP. El problema no es exclusivo de wg‑easy; ocurre siempre que el proxy no logra resolver o alcanzar el contenedor objetivo dentro de la red Docker. La raíz suele estar en la configuración de la red Docker, la definición del reverse_proxy en el Caddyfile o en la exposición de puertos del servicio wg‑easy. ...

Problema En entornos domésticos o de pequeña oficina es frecuente delegar la resolución de nombres internos a un Pi‑hole instalado en un contenedor LXC. El objetivo es que cualquier dispositivo que consulte DNS obtenga tanto la filtración de publicidad como los registros locales (por ejemplo test.lan). Cuando los dispositivos siguen enviando consultas al router y el router reenvía a un servidor externo (Cloudflare, Google), los nombres internos no se resuelven y el navegador muestra “server IP address could not be found”. El síntoma típico es: ...