BookinglyTech News
Infraestructura

Error intermitente "Failed to reach OIDC issuer" al usar Pocket ID con Caddy y Docker

Usuarios de Docker en Ubuntu Server reportan fallos esporádicos al autenticar servicios protegidos por Pocket ID tras cambiar a nombres de contenedor en el proxy inverso.

2 min de lecturar/selfhosted0 vistas

El problema aparece cuando Caddy actúa como proxy inverso para varios contenedores Docker y la autenticación OpenID Connect (OIDC) falla de forma intermitente. El mensaje exacto es "Failed to reach OIDC issuer" y se muestra en cualquier servicio que dependa de Pocket ID. Recargar la página suele resolver la autenticación, lo que indica un fallo de resolución DNS temporal.

Qué está pasando

El autor del post indica que la situación empezó después de sustituir la dirección IP del backend por el nombre del contenedor en la configuración de Caddy. En su red Docker, todos los servicios comparten la red proxy, y el archivo de Caddy incluye una regla como:

recipes.mydomain.org {
    reverse_proxy mealie:9000
}

Con esta configuración, Caddy debe resolver mealie a través del DNS interno de Docker. Cuando la resolución falla, la solicitud a la autoridad OIDC (el issuer) no se completa y se lanza el error. La solución propuesta por Google sugiere un problema de DNS, pero los pasos habituales (reiniciar el contenedor DNS, validar /etc/resolv.conf, etc.) no han corregido el síntoma.

Posibles causas y pruebas rápidas

  1. Cache de DNS en Caddy: Caddy mantiene una caché de resoluciones. Si la entrada expira mientras el contenedor está bajo carga, la petición puede fallar. Reiniciar Caddy o desactivar la caché (disable_dns_cache) ayuda a confirmar esta hipótesis.
  2. Configuración de la red Docker: Verificar que todos los contenedores involucrados estén realmente en la red proxy. Un contenedor fuera de esa red no será resoluble por nombre y provocará errores.
  3. AdGuard Home como DNS recursivo: El usuario tiene AdGuard Home en una Raspberry Pi que reescribe DNS. Si AdGuard no está configurado para reenviar consultas internas de Docker, las peticiones a nombres de contenedor pueden quedar sin respuesta.
  4. Tiempo de arranque desincronizado: Si Caddy se inicia antes que el contenedor mealie, la primera resolución fallará y quedará en caché. Un simple depends_on en Docker‑compose o un script de espera puede evitarlo.

Qué probar ahora

  • Añadir resolve_mealie al bloque hosts de Caddy con la IP estática del contenedor, eliminando la dependencia del DNS interno.
  • Configurar AdGuard Home para que reenvíe las consultas .docker a la IP del daemon Docker (normalmente 127.0.0.11).
  • Desactivar temporalmente la caché DNS de Caddy y observar si el error desaparece.
  • Revisar los logs de Caddy (caddy log) y del contenedor OIDC para identificar patrones de latencia o time‑outs.

Si ninguna de estas medidas funciona, lo más probable es que el problema sea una combinación de caché DNS y timing de arranque, y la solución definitiva consistirá en asegurar que la resolución de nombres sea fiable antes de que Caddy intente la autenticación.

En última instancia, la cuestión no es sólo el mensaje de error, sino la arquitectura de resolución DNS en entornos Docker con proxies inversos. Garantizar que los nombres de contenedor sean resolubles de forma consistente evita interrupciones en flujos críticos como la autenticación OIDC.

Historias Relacionadas