Si después de actualizar a Authentik 2026.8 el login muestra The request failed and the interceptors did not return an alternative response o se queda cargando, Authentik está ignorando las cabeceras de tu proxy inverso y cree que la petición llegó por HTTP. Desde la 2026.8 solo acepta X-Forwarded-Proto, X-Forwarded-Host y X-Forwarded-For cuando la conexión viene de una red incluida en AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. Se arregla añadiendo la IP o la red del proxy a esa variable. Lo reproduje el 18 de octubre de 2026 con Caddy 2.10.2, pasando de Authentik 2026.5.7 a 2026.8.4 en Docker 29.5.2 sobre Linux arm64. Tienes esta guía también en inglés.

Puntos clave

  • Authentik 2026.8.0 salió el 18 de agosto de 2026 y la última corrección es la 2026.8.5, del 21 de octubre, que no cambia el trato de las cabeceras del proxy. Mis pruebas son con la 2026.8.4. La versión anterior es la 2026.5: el proyecto publica una versión mayor cada tres meses.
  • Las redes de confianza por defecto son seis: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fe80::/10 y ::1/128. Un proxy en una red de Docker normal (172.x) sigue funcionando sin tocar nada.
  • Con el proxy en 100.64.209.0/24, fuera de esa lista, la 2026.5.7 respondía https:// en el emisor de OpenID Connect y la 2026.8.4 pasó a responder http://.
  • hash_password ya no acepta la contraseña como argumento: falla con unrecognized arguments y código de salida 2. Ahora se pasa por la entrada estándar o en un aviso oculto.
  • Saltar de la 2026.2.7 a la 2026.8.4 detiene el arranque con Major version skips are not allowed antes de migrar: la base de datos se quedó en 692 migraciones.

¿Qué cambia en Authentik 2026.8 con las cabeceras del proxy?

Authentik 2026.8 aplica la lista de proxies de confianza a todas las cabeceras reenviadas, no solo a algunas. Las notas de la versión lo explican así: "Previous versions did not apply this restriction consistently to all forwarded headers." Hasta la 2026.5, una petición desde cualquier dirección podía fijar el esquema con X-Forwarded-Proto, y eso permitía falsificarlo.

El aviso oficial describe los síntomas en una frase: "An incorrect configuration can cause authentik to interpret HTTPS requests as HTTP, resulting in blocked mixed content, an endless loading indicator, or authentication errors." La página del proxy inverso añade un cuarto efecto: los registros guardan la IP del proxy en lugar de la del cliente.

La variable que manda es AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS, una lista de rangos CIDR (Classless Inter-Domain Routing, la notación red/máscara) separados por comas. Existía antes de la 2026.8; lo nuevo es que ahora se aplica a las tres cabeceras. Si la defines, sustituye la lista por defecto en lugar de ampliarla.

¿A quién le afecta el cambio?

Te afecta si el proxy se conecta a Authentik desde una dirección fuera de la lista por defecto. También si definiste la lista a mano y el proxy no está en ella. Con Docker Compose y las redes que Docker crea por su cuenta (172.17.0.0/16 en adelante y 192.168.x) el proxy sigue siendo de confianza. Lo comprobé enviando X-Forwarded-Proto: https desde dos redes del mismo laboratorio:

Configuración de Authentik 2026.8.4 Desde 172.26.0.0/16 Desde 100.64.209.0/24
Sin TRUSTED_PROXY_CIDRS (por defecto) https:// http://
TRUSTED_PROXY_CIDRS=100.64.209.0/24 http:// https://

La segunda fila muestra la trampa de sustituir la lista: al confiar solo en 100.64.209.0/24 dejé de confiar en la red 172 que antes funcionaba. Los casos típicos fuera de la lista por defecto son estos:

  • Proxy en otra máquina con IP pública: un VPS con Caddy o Traefik que llega a Authentik por internet
  • Túnel de Tailscale o Headscale: usa direcciones del rango 100.64.0.0/10 (RFC 6598), que no es privado en el sentido de RFC 1918
  • Redes de Docker con IPv6: la lista por defecto solo incluye fe80::/10 y ::1/128, no las direcciones fd00::/8 que se suelen asignar a una red IPv6 propia
  • Una lista escrita a mano: por ejemplo con solo la IP de un proxy antiguo

Cómo he reproducido el fallo con Caddy

Monté el compose.yml oficial de Authentik con PostgreSQL 16 y añadí Caddy 2.10.2 con un certificado interno, como única entrada por HTTPS. Para que el proxy quedara fuera de los rangos por defecto, lo conecté a Authentik por una red con la subred 100.64.209.0/24, la misma familia de direcciones que usa Tailscale. El laboratorio responde como auth.lab.test en el puerto 30943 del propio equipo, y por eso los curl llevan --resolve y -k (el certificado es el interno de Caddy). Este es el Caddyfile:

auth.lab.test {
    tls internal
    reverse_proxy server:9000
}

Caddy no necesita nada más, porque según su documentación reverse_proxy fija X-Forwarded-Proto y X-Forwarded-Host y añade X-Forwarded-For por defecto. Esta parte de la definición de servicios es la que saca al proxy de los rangos privados:

  caddy:
    image: mirror.gcr.io/library/caddy:2.10.2-alpine
    ports: ["127.0.0.1:30943:443"]
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]
    networks:
      edge: {ipv4_address: 100.64.209.10}
networks:
  edge:
    ipam:
      config: [{subnet: 100.64.209.0/24}]

El servicio server de Authentik está en esa red edge y en la de PostgreSQL. Con la 2026.5.7 todo funcionaba: login, panel de administración y una aplicación OpenID Connect (OIDC) de prueba llamada whoami. Antes de actualizar guardé la base de datos con pg_dump, que ocupó 2,8 MB.

El error The request failed and the interceptors did not return an alternative response

Ese mensaje es lo que ves en la pantalla de login de Authentik 2026.8 cuando confunde HTTPS con HTTP. Cambié AUTHENTIK_TAG de 2026.5.7 a 2026.8.4, ejecuté docker compose pull y docker compose up -d, y Authentik migró la base de datos de 718 a 777 migraciones sin errores. Los contenedores quedaron healthy, pero la página de login de https://auth.lab.test:30943 mostró esto:

The request failed and the interceptors did not return an
alternative response

La consola de Chromium explica la causa: la página se cargó por HTTPS y pidió la API del flujo de autenticación por HTTP, así que el navegador la bloqueó como contenido mixto. Parto las líneas para que quepan:

Mixed Content: The page at 'https://auth.lab.test:30943/if/flow/
default-authentication-flow/?next=%2F' was loaded over HTTPS, but
requested an insecure resource 'http://auth.lab.test:30943/api/v3/
flows/executor/default-authentication-flow/?query=next%3D%252F'.
This request has been blocked

Las aplicaciones conectadas por OIDC también lo notan, porque el documento de descubrimiento anuncia URL con http://. Un cliente que compara el emisor con el que tiene configurado rechazará los tokens:

$ curl -sk --resolve auth.lab.test:30943:127.0.0.1 \
  https://auth.lab.test:30943/application/o/whoami/\
.well-known/openid-configuration | grep -o '"issuer": "[^"]*"'
"issuer": "http://auth.lab.test:30943/application/o/whoami/"

Con la 2026.5.7 y la misma configuración, esa línea decía https://.

Cómo saber desde qué IP se conecta tu proxy

El registro de acceso de Authentik te da la respuesta sin adivinar: cada petición lleva los campos remote (quién se conectó) y scheme (el esquema que Authentik cree que se usó). Filtra una petición conocida, por ejemplo la del documento de descubrimiento:

$ docker compose logs server --since 30s \
  | grep openid-configuration | grep -o -E '"(remote|scheme)": "[^"]*"'
"remote": "::ffff:100.64.209.10"
"scheme": "http"

remote con la IP del proxy y scheme en http confirman el diagnóstico. El prefijo ::ffff: solo indica una dirección IPv4 escrita en formato IPv6. Si prefieres preguntar a Docker, docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' nombre_del_contenedor_del_proxy devuelve la IP del contenedor de Caddy o Traefik.

Cómo arreglarlo con AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS

El arreglo es una línea en el .env que leen server y worker, con la red desde la que se conecta el proxy. Pon la red entera si la IP del contenedor puede cambiar al recrearlo, o una IP con /32 si es fija:

AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS=100.64.209.0/24

Como la variable sustituye la lista por defecto, añade también cualquier otra red desde la que llegue un proxy legítimo, separada por comas. No incluyas redes desde las que se conecten clientes directamente, porque podrían fijar sus propias cabeceras. Después recrea los contenedores:

$ docker compose up -d
$ docker compose exec -T server printenv AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS
100.64.209.0/24

En el compose.yml oficial PostgreSQL también lee el .env, así que docker compose up -d lo recrea junto a Authentik; el volumen de datos no se toca. Si usas el chart de Helm, el valor equivalente es authentik.listen.trusted_proxy_cidrs.

Cómo comprobar que Authentik vuelve a ver HTTPS

Repite las dos pruebas del diagnóstico: el emisor debe volver a https:// y el registro debe mostrar el esquema correcto. Esto obtuve tras el cambio:

$ curl -sk --resolve auth.lab.test:30943:127.0.0.1 \
  https://auth.lab.test:30943/application/o/whoami/\
.well-known/openid-configuration | grep -o '"issuer": "[^"]*"'
"issuer": "https://auth.lab.test:30943/application/o/whoami/"
$ docker compose logs server --since 30s \
  | grep openid-configuration | grep -o -E '"(remote|scheme)": "[^"]*"'
"remote": "100.64.209.1"
"scheme": "https"

remote ya no es el proxy (100.64.209.10) sino el cliente que llegó a Caddy, porque Authentik acepta ahora X-Forwarded-For. Con la 2026.5.7 ese campo mostraba la IP del proxy aunque el esquema fuera correcto, que es la incoherencia que la 2026.8 corrige. El login con akadmin llegó a la biblioteca de aplicaciones sin errores en la consola.

Probé también la opción Base URL, nueva en la configuración del sistema, por si bastaba con fijar https://auth.lab.test:30943. En la 2026.8.4 no cambió nada: el emisor siguió en http:// hasta añadir el proxy a la lista de confianza.

hash_password ya no acepta la contraseña como argumento

El segundo cambio incompatible afecta a scripts de aprovisionamiento. hash_password genera el hash de una contraseña para, por ejemplo, la variable AUTHENTIK_BOOTSTRAP_PASSWORD o una plantilla. En la 2026.5.7 aceptaba la contraseña como argumento; en la 2026.8.4 falla así, con código de salida 2:

$ docker compose run --rm -T server hash_password 'mi_contrasena_de_prueba'
manage.py hash_password: error: unrecognized arguments: mi_contrasena_de_prueba

El motivo, según las notas, es que la contraseña quedaba a la vista en la lista de procesos. Ejecuta el comando sin argumentos para un aviso oculto, o pásala por la entrada estándar en un script. La forma de tubería devolvió el hash pbkdf2_sha256 con un millón de iteraciones:

$ printf '%s' 'mi_contrasena_de_prueba' \
  | docker compose run --rm -T server hash_password
pbkdf2_sha256$1000000$ZVYQzKhfBytxmrDpaxccvo$91xSL+kUWe1IccdcpsMR…

Usa -T con docker compose run en la tubería, para que no reserve una terminal y lea la entrada estándar.

Major version skips are not allowed al saltar desde la 2026.2

Authentik 2026.8 se niega a arrancar si la base de datos viene de una versión anterior a la 2026.5. Lo probé en una instancia aparte con la 2026.2.7: al cambiar directamente a la 2026.8.4, server y worker terminaron con código 1 y este error:

[error] Major version skips are not allowed. See: https://docs.goauthentik.io/
install-config/upgrade/?from=2026.2.7&to=2026.8.4
RuntimeError: Major version skips are not allowed.

La comprobación ocurre antes de migrar: la tabla django_migrations siguió con 692 filas. Pasar primero por la 2026.5.7 (718 migraciones) y después a la 2026.8.4 (777) funcionó sin tocar nada más. La guía de actualización pide además llegar a la última corrección de cada versión mayor antes de saltar a la siguiente.

Otros cambios de la 2026.8 que conviene revisar antes de actualizar

Las notas de la 2026.8 incluyen otros siete cambios. No los he reproducido en el laboratorio, pero conviene conocerlos antes de actualizar:

  • Outposts: el servidor y todos los outposts deben ir en la misma versión, así que actualízalos a la vez. El outpost integrado ya se actualiza con la imagen.
  • "Prevent duplicate devices": desaparece esa opción de la etapa de configuración de WebAuthn. Venía desactivada por defecto desde la 2026.5.4 y no hay que hacer nada.
  • Base URL: será obligatoria en la 2026.11, y el proyecto recomienda configurarla ya en la configuración del sistema.
  • Tareas: las que registran errores pero terminan pueden aparecer ahora como error o aviso. Las anteriores conservan su estado hasta volver a ejecutarse.
  • Autenticadores: borrar una etapa de autenticador ya no borra los dispositivos inscritos que la usan.
  • SAML con ForceAuthn: las peticiones que lo piden exigen ahora autenticarse de nuevo.
  • AUTHENTIK_POSTGRESQL__CONN_OPTIONS: queda obsoleta, junto con su equivalente para réplicas, y desaparecerá en una versión futura.

La imagen también crece: ghcr.io/goauthentik/server:2026.8.4 ocupa 1,87 GB descomprimida en arm64, frente a 1,68 GB de la 2026.5.7.

Pasos para actualizar Authentik a la 2026.8 sin cortes

La secuencia que funcionó en el laboratorio cabe en cinco pasos, y el orden importa porque Authentik no admite volver atrás:

  1. Comprueba tu versión actual. Si es anterior a la 2026.5, actualiza primero a la última 2026.5.x.
  2. Guarda la base de datos con docker compose exec -T postgresql pg_dump -U authentik -Fc authentik > authentik.dump.
  3. Averigua la IP de tu proxy con el registro de acceso y, si no está en los rangos por defecto, añade AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS al .env antes de cambiar de versión.
  4. Cambia AUTHENTIK_TAG a 2026.8.5 (o descarga el compose.yml nuevo), y ejecuta docker compose pull y docker compose up -d.
  5. Comprueba el emisor de una aplicación OIDC, el campo scheme del registro y un login completo desde el navegador.

Si actualizas contenedores de forma automática con Watchtower, excluye Authentik: un salto de versión mayor sin el paso 3 deja el login roto sin que nadie lo vea. Si estás montando el proxy desde cero, la guía de Traefik como proxy inverso con Docker usa una red de Docker normal, que entra en los rangos de confianza por defecto. Y si dudas de seguir con Authentik, la comparativa de Pocket ID, Authelia y Authentik repasa las alternativas.

Preguntas frecuentes

¿Puedo poner AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS=0.0.0.0/0 para salir del paso?

Funciona, pero deshace la protección que añade la 2026.8. Cualquiera que llegue a Authentik sin pasar por el proxy podría fijar X-Forwarded-For y X-Forwarded-Proto, falsear su IP en los registros y en las políticas por reputación. La documentación pide no incluir redes desde las que se conecten clientes no confiables. Usa la IP o la subred concreta del proxy.

¿Tengo que tocar algo si uso Traefik en la misma red de Docker?

No, si la red es de las que Docker asigna por defecto (172.17.0.0/16 a 172.31.0.0/16 o 192.168.x). En mi prueba, una petición desde 172.26.0.0/16 con la configuración por defecto obtuvo el emisor con https://. Mira el campo remote del registro para confirmarlo en tu instalación.

¿Por qué el error aparece solo después de actualizar y no antes?

Porque hasta la 2026.5 Authentik aplicaba la lista de confianza de forma desigual: aceptaba el esquema de X-Forwarded-Proto desde mi proxy en 100.64.209.10, aunque ignoraba su X-Forwarded-For. La 2026.8 aplica la misma regla a todas las cabeceras, así que un proxy que antes funcionaba a medias deja de funcionar del todo.

Conclusión

El fallo de Authentik 2026.8 detrás de un proxy inverso no es un error de Caddy ni de Traefik. Authentik deja de creer las cabeceras de un proxy que no está en AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS, y construye URL http:// que el navegador bloquea. Antes de actualizar, mira el campo remote del registro y, si el proxy está fuera de los seis rangos por defecto, añade su red a la variable. Revisa también los scripts que llaman a hash_password con la contraseña como argumento y no saltes desde la 2026.2: pasa primero por la 2026.5.

Fuentes: [1] Authentik, notas de la versión 2026.8[1], [2] Authentik, documentación del proxy inverso[2], [3] Authentik, referencia de configuración[3], [4] Authentik, guía de actualización[4], [5] Authentik, versión 2026.8.4 en GitHub[5], [6] Caddy, directiva reverse_proxy[6], [7] RFC 6598, espacio de direcciones compartido 100.64.0.0/10[7].

Fuentes

  1. Authentik, notas de la versión 2026.8
  2. Authentik, documentación del proxy inverso
  3. Authentik, referencia de configuración
  4. Authentik, guía de actualización
  5. Authentik, versión 2026.8.4 en GitHub
  6. Caddy, directiva reverse_proxy
  7. RFC 6598, espacio de direcciones compartido 100.64.0.0/10