Bucle de inicio de sesión de WordPress: te devuelve al login — Cómo solucionarlo

Playbook de diagnóstico rápido (comprueba esto primero)

Si solo tienes cinco minutos antes de que alguien importante pregunte por qué no puede publicar la entrada del CEO, haz esto en orden. Esta secuencia encuentra el cuello de botella rápido porque sigue la ruta de autenticación: navegador → caché de borde → proxy inverso → PHP → base de datos.

1) Confirma si las cookies se están estableciendo y devolviendo

• Comprueba: ¿Recibe el navegador Set-Cookie después de enviar las credenciales por POST?
• Luego: ¿Incluye la siguiente petición a /wp-admin/ esa cookie?
• Por qué: Un “bucle” de login suele ser WordPress diciendo “no recibí una cookie de autenticación válida”, así que te devuelve al login.

2) Confirma que tu URL canónica y el esquema son consistentes

• Comprueba: ¿Estás rebotando entre http y https o entre www y el dominio raíz?
• Por qué: Las cookies están limitadas por dominio y esquema. Si tu POST de login ocurre en una variante y el admin carga en otra, la cookie puede no aplicarse.

3) Evita cachés y capas de seguridad

• Comprueba: ¿Está un caché de borde, WAF, plugin de “rendimiento” o proxy inverso cachéando wp-login.php o manipulando cabeceras?
• Por qué: Los endpoints de autenticación son dinámicos. Cachéarlos es como poner un letrero en tu puerta que diga “a veces abierta”.

4) Desactiva plugins de forma segura, luego temas

• Comprueba: ¿Desaparece el problema con los plugins desactivados?
• Por qué: Un plugin de “seguridad” o de “consentimiento de cookies” puede romper la autenticación de maneras creativas.

5) Valida sesiones del lado del servidor, PHP y escrituras en la BD

• Comprueba: ¿Está PHP escribiendo sesiones? ¿La BD es escribible? ¿Hay errores fatales?
• Por qué: Si WordPress no puede establecer estado relacionado con la autenticación (o tienes rarezas con el object cache), no puede mantener tu sesión iniciada.

Cómo funciona realmente el flujo de inicio de sesión de WordPress (para que dejes de luchar con fantasmas)

El inicio de sesión de WordPress se basa en cookies. Cuando envías credenciales a wp-login.php, WordPress:

1. Valida usuario/contraseña (o SSO) y comprueba el estado/capacidades del usuario.
2. Emite cookies de autenticación: típicamente wordpress_logged_in_* y wordpress_sec_* (los nombres varían según hash/salt y ajustes).
3. Te redirige (302) a /wp-admin/ o a una ruta objetivo.
4. En la siguiente petición, WordPress lee las cookies, las valida contra los salts y el registro del usuario, y o bien permite el acceso o te redirige de vuelta al login.

Un “bucle de login” significa una de tres cosas:

• La cookie nunca se estableció (bloqueada, eliminada, respuesta cacheada, cabeceras erróneas).
• La cookie se estableció pero nunca se envió de vuelta (incompatibilidad de dominio, flag secure, path, problemas de SameSite en ciertos flujos).
• La cookie se envió pero fue rechazada (salts malos tras una migración, inconsistencia BD/object cache, desajuste de hora, meta de usuario raro, plugin de autenticación personalizado).

Un mantra práctico: trátalo como depuración de sistemas distribuidos. Hay múltiples capas, y cualquiera de ellas puede “amablemente” reescribir tu petición hacia el fracaso.

Idea parafraseada de un experto en fiabilidad: parafraseando la idea — “La esperanza no es una estrategia.” — atribuido a Gene Kranz (mentalidad de operaciones de misión).

Broma #1: Un bucle de inicio de sesión de WordPress es el único cardio que algunos hacemos en el día laboral. No es un buen programa de bienestar.

Hechos interesantes y contexto histórico (breve y útil)

• Hecho 1: WordPress usa autenticación basada en cookies desde las primeras versiones; los nombres de cookie incluyen hashes derivados de la configuración del sitio y salts de seguridad, por eso las migraciones pueden “romper aleatoriamente” los inicios de sesión.
• Hecho 2: El endpoint wp-login.php es una de las URL públicas más atacadas en internet; muchas pilas de hosting añaden reglas WAF o limitación de tasa que pueden interferir sutilmente con inicios de sesión legítimos.
• Hecho 3: El área de administración depende fuertemente de redirecciones (host canónico, forzamiento SSL, ubicación del admin). Una mala configuración de redirecciones produce bucles más rápido que casi cualquier otro bug del sitio.
• Hecho 4: Los navegadores han endurecido el manejo de cookies con el tiempo (destacando por los defaults de SameSite), lo que puede romper flujos de login que involucren POSTs entre sitios o callbacks de IdP externos si no se configuran las cookies correctamente.
• Hecho 5: Muchos CDNs con política “cache todo” enviaron por defecto reglas ingenuas; las configuraciones modernas normalmente excluyen wp-admin y wp-login.php, pero aún se misconfigura constantemente.
• Hecho 6: WordPress almacena las URLs canónicas (home y siteurl) en la base de datos, pero permite sobrescribirlas vía wp-config.php. Los conflictos entre ambas son un generador clásico de bucles.
• Hecho 7: Un proxy inverso (balanceador, CDN, ingress) altera el significado de “esto es HTTPS” a menos que las cabeceras reenviadas sean correctas; WordPress usa eso para decidir flags de cookie seguras y destinos de redirección.
• Hecho 8: El object caching (Redis/Memcached) puede hacer que la autenticación parezca “embrujada” cuando valores obsoletos persisten tras despliegues o cuando varios servidores de aplicación discrepan en salts/config.

Causas reales del bucle de inicio de sesión (ordenadas por frecuencia)

1) Desajuste de URL, host o HTTPS (la cinta de correr de redirecciones canónicas)

WordPress quiere una URL verdadera para el sitio. Si tu pila sirve múltiples variantes—http, https, con/sin www, quizá un dominio alternativo—el POST de login puede ocurrir en una variante, pero la redirección a /wp-admin/ aterriza en otra. Las cookies no viajan como quisieras.

Desencadenantes comunes:

• home y siteurl configurados de forma distinta (uno http, otro https).
• HTTPS forzado en el balanceador, pero WordPress cree que está en HTTP.
• Reglas de redirección en Nginx/Apache que compiten con las redirecciones canónicas de WordPress.

2) Cookies bloqueadas, eliminadas o con alcance incorrecto

Si las cookies no se establecen o no se devuelven, WordPress no puede mantener tu sesión. Causas incluyen:

• Proxy/CDN que elimina cabeceras Set-Cookie por “cacheabilidad”.
• Incompatibilidad de dominio/path tras un cambio de dominio.
• Cookies seguras sobre HTTPS que no funcionan porque WordPress no detecta HTTPS (así que establece cookies no seguras y luego te redirigen a HTTPS y no las aceptan como se espera).
• Plugins de consentimiento de cookies o de seguridad que reescriben cabeceras de forma errática.

3) Caché (edge, plugin, servidor) que cachea lo incorrecto

Es impresionante cuántas configuraciones de rendimiento intentan cachear páginas de login. Si la respuesta de login o la redirección está cacheada, distintos usuarios empiezan a compartir el mismo estado roto. Además, si un caché elimina cookies, la autenticación falla sin señales visibles.

4) Conflictos de plugins/tema, especialmente seguridad y SSO

Plugins de seguridad, puentes SSO, plugins de 2FA y paquetes tipo “desactivar XML-RPC” suelen engancharse en filtros de autenticación. Una actualización mala puede introducir una regla de redirección que nunca completa.

5) Salts/keys rotos tras migración o deriva de configuración entre servidores

WordPress firma las cookies de autenticación con salts y keys en wp-config.php. Si los cambias, las cookies existentes quedan inválidas (lo cual está bien), pero si tienes múltiples servidores de aplicación con salts distintos, los usuarios se desconectan o entran en bucle según a qué backend lleguen.

6) Desajuste de hora o rarezas de terminación TLS

Las cookies de autenticación contienen expiración. Si la hora del sistema está mal (deriva de VM, issues en contenedor, NTP roto), las cookies pueden parecer expiradas inmediatamente. Menos común, pero espectacular cuando ocurre.

7) Fallos de escritura en base de datos o sistema de archivos y errores fatales sutiles

La autenticación de WordPress depende de lecturas/escrituras en la BD y de que PHP complete las peticiones. Si PHP falla de forma fatal después de establecer una redirección, o la BD está en solo-lectura, puedes acabar en un bucle sin apenas errores visibles para el usuario. Revisa los logs en serio.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas prácticas que puedes ejecutar en un host Linux típico. Ajusta rutas si tu distribución o diseño difiere. Cada tarea incluye: comando, qué significa la salida y la decisión siguiente.

Task 1: Reproducir la cadena de redirecciones desde el servidor

cr0x@server:~$ curl -I -L https://example.com/wp-admin/ | sed -n '1,40p'
HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wp-wpml_current_language=en; path=/
server: nginx

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: no-store, no-cache, must-revalidate, max-age=0

Qué significa: Un solo 302 al login es normal si no estás autenticado. Si ves 302s repetidos rebotando entre wp-login.php y wp-admin, tienes un bucle.

Decisión: Si el bucle aparece aquí sin un navegador, estás tratando con lógica de redirección del lado del servidor o problemas de URL canónica — no “mi navegador está raro”.

Task 2: Comprobar si las respuestas de la página de login están siendo cacheadas por un proxy/CDN

cr0x@server:~$ curl -I https://example.com/wp-login.php | egrep -i 'cache|age|cf-cache-status|x-cache|via|set-cookie'
cache-control: no-store, no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Qué significa: Quieres no-store o una cabecera de caché restrictiva similar. Si ves cabeceras como x-cache: HIT o un estado de caché del CDN mostrando un hit, es sospechoso.

Decisión: Si está cacheado, configura el CDN/proxy inverso para evitar caché en /wp-login.php y /wp-admin/*, y para que nunca elimine Set-Cookie.

Task 3: Confirmar URLs canónicas de WordPress (WP-CLI)

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp option get home
https://example.com
cr0x@server:/var/www/html$ wp option get siteurl
http://example.com

Qué significa: Ese desajuste (https vs http) es un disparador clásico de bucle.

Decisión: Establece ambos con el mismo esquema y host. Elige una URL canónica y mantente en ella.

Task 4: Arreglar home y siteurl de forma segura

cr0x@server:/var/www/html$ wp option update home 'https://example.com'
Success: Updated 'home' option.
cr0x@server:/var/www/html$ wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.

Qué significa: WordPress generará cookies/redirecciones basadas en estos valores.

Decisión: Vuelve a probar el login. Si sigue en bucle, pasa a detección de HTTPS y cabeceras de proxy.

Task 5: Comprobar si WordPress cree que la petición es HTTPS (detrás de un proxy)

cr0x@server:~$ grep -R "HTTPS" -n /var/www/html/wp-config.php | head
# (no output)

Qué significa: No hay forzado explícito de HTTPS a nivel de aplicación. Eso está bien si las cabeceras del proxy son correctas, pero es arriesgado cuando no lo son.

Decisión: Si terminas TLS en un balanceador y reenvías a PHP por HTTP, asegúrate de que X-Forwarded-Proto esté presente y sea respetado, o establece $_SERVER['HTTPS']='on' condicionalmente en wp-config.php.

Task 6: Verificar cabeceras reenviadas en Nginx (culpable común)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "X-Forwarded-Proto|X-Forwarded-For|fastcgi_param"
112:    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
113:    proxy_set_header X-Forwarded-Proto $scheme;
210:    fastcgi_param HTTPS $https if_not_empty;

Qué significa: Si estás detrás de un proxy, $scheme podría ser http entre proxy y origen incluso cuando el cliente usó HTTPS. Eso hace que WordPress crea que está en HTTP.

Decisión: Configura correctamente el forwarded proto desde el borde (LB → origen). A menudo quieres que Nginx confíe en X-Forwarded-Proto de tu LB y lo pase a PHP.

Task 7: Inspeccionar cabeceras de respuesta por cookies faltantes/reescritas

cr0x@server:~$ curl -s -D - https://example.com/wp-login.php -o /dev/null | sed -n '1,40p'
HTTP/2 200
date: Fri, 27 Dec 2025 11:20:00 GMT
content-type: text/html; charset=UTF-8
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Qué significa: Estás recibiendo Set-Cookie al menos para la cookie de prueba. Tras enviar credenciales deberías ver también cookies de autenticación.

Decisión: Si Set-Cookie desaparece solo en el POST, sospecha de reglas WAF, caché o un plugin que falla a mitad de respuesta.

Task 8: Hacer POST a wp-login.php y comprobar cookies auth (simulación servidor-side)

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://example.com/wp-login.php \
  -d "log=admin&pwd=wrongpassword&wp-submit=Log+In&redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&testcookie=1" | egrep -i 'HTTP/|set-cookie:|location:'
HTTP/2 200
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Qué significa: Con credenciales equivocadas no obtendrás cookies de autenticación; deberías obtener un 200 con la página de error.

Decisión: Si ni siquiera credenciales correctas producen cookies auth (verías líneas adicionales de set-cookie), pasa a logs de PHP y aislamiento de plugins.

Task 9: Revisar PHP-FPM y logs web por fatales relacionados con auth

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 11:18:32] WARNING: [pool www] child 2147 said into stderr: "PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/foo/foo.php:12) in /var/www/html/wp-includes/pluggable.php on line 1428"

Qué significa: “Headers already sent” puede impedir que se establezcan cookies. Sin cookies, no hay login. Ese archivo de plugin imprimió algo (incluso espacios) antes de que WordPress pudiera enviar cabeceras.

Decisión: Desactiva el plugin culpable. Luego arréglalo correctamente (o reemplázalo) porque esto volverá a ocurrir.

Task 10: Desactivar plugins sin necesitar wp-admin

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp plugin deactivate --all
Success: Deactivated 14 of 14 plugins.

Qué significa: Has eliminado la interferencia de plugins de la ecuación.

Decisión: Vuelve a probar el login. Si se arregla, vuelve a activar plugins uno por uno para hallar al culpable (sí, es tedioso; sí, es más rápido que adivinar).

Task 11: Cambiar a un tema por defecto para eliminar hacks de autenticación a nivel de tema

cr0x@server:/var/www/html$ wp theme list
+----------------+----------+--------+---------+
| name           | status   | update | version |
+----------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| corp-theme     | active   | none   | 4.8.1   |
+----------------+----------+--------+---------+
cr0x@server:/var/www/html$ wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Qué significa: Si tu tema tiene redirecciones de login personalizadas, hooks SSO o buffering de salida roto, esto lo aísla.

Decisión: Si esto arregla el bucle, tu “hermoso tema corporativo” ahora es un incidente de producción. Trátalo en consecuencia.

Task 12: Comprobar deriva de configuración de salts/keys entre servidores (diff rápido)

cr0x@server:~$ sudo egrep "AUTH_KEY|SECURE_AUTH_KEY|LOGGED_IN_KEY|NONCE_KEY" -n /var/www/html/wp-config.php
54:define('AUTH_KEY',         '...a...');
55:define('SECURE_AUTH_KEY',  '...b...');
56:define('LOGGED_IN_KEY',    '...c...');
57:define('NONCE_KEY',        '...d...');

Qué significa: Estos valores deben ser idénticos en todos los servidores de aplicación detrás de un balanceador.

Decisión: Si tienes múltiples orígenes, verifica que coincidan en todos. Si no, arregla el despliegue para que la configuración sea consistente.

Task 13: Comprobar hora del sistema y sincronización NTP (salud de expiración de cookies)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-27 11:20:44 UTC
           Universal time: Fri 2025-12-27 11:20:44 UTC
                 RTC time: Fri 2025-12-27 11:20:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: Si los relojes están desincronizados o NTP está inactivo, las cookies pueden parecer inmediatamente expiradas.

Decisión: Si no está sincronizado, arregla la hora primero. No depures autenticación en un servidor que no puede ponerse de acuerdo sobre “ahora”.

Task 14: Comprobar salud del cache de objetos Redis (si se usa)

cr0x@server:~$ redis-cli ping
PONG
cr0x@server:~$ redis-cli info | egrep "used_memory_human|maxmemory_human|evicted_keys"
used_memory_human:312.45M
maxmemory_human:512.00M
evicted_keys:18422

Qué significa: Muchas expulsiones pueden causar comportamiento extraño. No siempre bucles de login, pero puede desestabilizar valores de auth en algunas configuraciones.

Decisión: Si la expulsión es alta, aumenta la memoria del caché o reduce uso. También confirma que el plugin de object cache es apropiado y está configurado.

Task 15: Confirmar que la BD es escribible y no devuelve errores

cr0x@server:~$ mysql -N -e "SHOW GLOBAL VARIABLES LIKE 'read_only';"
read_only	OFF

Qué significa: Si la BD está en solo-lectura (o falla), WordPress puede comportarse de forma impredecible, especialmente con sesiones/plugins que escriben user meta.

Decisión: Si read_only está ON inesperadamente, arregla el estado de replicación/failover o apunta WordPress al primario correcto.

Task 16: Validar que wp-content no sea de solo-lectura (actualizaciones y algunos flujos de auth)

cr0x@server:~$ sudo -u www-data test -w /var/www/html/wp-content && echo "wp-content writable" || echo "wp-content NOT writable"
wp-content writable

Qué significa: No todos los bucles de login son por escrituras de archivos, pero problemas de permisos suelen acompañar despliegues rotos y problemas de “headers already sent”.

Decisión: Si no es escribible y tu pila lo espera, arregla propietarios/permisos; si tu pila prohíbe escrituras, asegúrate de que plugins/temas no intenten escribir en tiempo de ejecución de forma que rompan las respuestas.

Errores comunes: síntoma → causa raíz → solución

Síntoma: Contraseña correcta, redirección instantánea de vuelta a wp-login.php, sin error

Causa raíz: Cookies no almacenadas o no devueltas (incompatibilidad de dominio, flag secure, warnings de “headers already sent”, proxy que elimina Set-Cookie).

Solución: Verifica consistencia de home/siteurl, comprueba cabeceras de respuesta por Set-Cookie, elimina warnings de “headers already sent” en PHP y desactiva cachés en login/admin.

Síntoma: Funciona en un navegador/dispositivo, falla en otro

Causa raíz: Diferencias en políticas de cookies (comportamiento SameSite, bloqueo de cookies de terceros), cookies obsoletas o una extensión del navegador que modifica peticiones.

Solución: Prueba en un perfil limpio/ventana privada, borra cookies del sitio, asegura que tu flujo de login sea de primer partido (sin POSTs cross-site sorpresas) y confirma HTTPS y host canónico.

Síntoma: Funciona en origen directamente, falla a través de CDN/WAF

Causa raíz: Caché de borde del login/admin, páginas de challenge del WAF, eliminación de cabeceras o protección contra bots que trata a humanos como bots.

Solución: Evita caché para endpoints de auth, agrega allowlist de IPs admin si procede, y asegúrate de que las páginas de challenge no apliquen a los POSTs de wp-login.php.

Síntoma: Solo falla cuando “Forzar HTTPS” o HSTS está activo

Causa raíz: WordPress no detecta HTTPS detrás de un proxy; establece cookies o redirecciones de forma inconsistente.

Solución: Corrige cabeceras reenviadas y/o detecta HTTPS en wp-config.php. Asegura que solo una capa realice la redirección canónica.

Síntoma: Cierres de sesión aleatorios / bucles en un entorno balanceado

Causa raíz: Diferentes salts/keys entre servidores de aplicación, wp-config.php inconsistente, o falta de sesiones sticky cuando un plugin las requiere.

Solución: Haz la configuración inmutable e idéntica entre nodos. Evita depender de sesiones pegajosas; si son inevitables, configúralas explícitamente y documenta por qué.

Síntoma: Login funciona, pero wp-admin te cierra la sesión tras unos clics

Causa raíz: Plugin de caché guardando respuestas admin-ajax, plugin de seguridad invalidando sesiones agresivamente, o desajuste de reloj.

Solución: Excluye rutas de admin del caché, ajusta reglas de seguridad y verifica la sincronización horaria.

Síntoma: Solo los administradores afectados; los editores pueden iniciar sesión

Causa raíz: Políticas de redirección específicas para administradores, mala configuración de 2FA, checks de capacidades o un mu-plugin personalizado.

Solución: Inspecciona los plugins must-use y ajustes de seguridad; prueba con todos los plugins desactivados; revisa logs del servidor por redirecciones específicas de rol.

Listas de verificación / plan paso a paso

Checklist A: Recuperación en una pasada “devuélveme a wp-admin”

1. Borra las cookies del navegador para el sitio (o usa una ventana privada). Si no puedes iniciar sesión ahí tampoco, no son “cookies obsoletas”.
2. Confirma la URL canónica:
   • Haz que home y siteurl sean idénticos (esquema + host).
   • Elige www o dominio raíz y mantente en esa opción.
3. Evita temporalmente el CDN/WAF (archivo hosts / acceso directo al origen) para ver si el borde es el problema.
4. Desactiva todos los plugins vía WP-CLI o renombrando wp-content/plugins.
5. Cambia a un tema por defecto para descartar código de autenticación en el tema.
6. Revisa logs por “headers already sent” y errores fatales.
7. Arregla la detección de HTTPS detrás de proxies (cabeceras reenviadas o forzado condicional de HTTPS en wp-config.php).
8. Vuelve a habilitar plugins uno a uno. Detente cuando vuelva el bucle. Ese plugin es el culpable, no la víctima.

Checklist B: Endurecimiento para que esto no vuelva el próximo martes

1. Excluir endpoints de autenticación del caché: /wp-login.php, /wp-admin/*, y típicamente /wp-json/ según flujos de administración.
2. Estandarizar despliegue de configuración: una fuente de la verdad para wp-config.php y salts, entregada idénticamente a todos los nodos.
3. Monitorizar redirecciones: rastrea tasas de 302 para wp-login.php y wp-admin. Un pico suele ser una alarma temprana.
4. Loguear en borde y origen: incluye IDs de petición para poder seguir un login a través de toda la pila.
5. Documentar la política de URL canónica (host, esquema, HSTS). La política no escrita se convierte en folklore; el folklore en incidentes.
6. Probar tras cambios: cada vez que toques reglas de CDN, terminación HTTPS o plugins de caché, prueba explícitamente el flujo de login.

Broma #2: La forma más rápida de crear un bucle de inicio de sesión en WordPress es decir: “Es solo un pequeño cambio de redirección.” El bucle te escucha.

Tres mini-historias corporativas desde las trincheras

Incidente #1: La suposición equivocada (HTTPS es HTTPS, ¿verdad?)

Una empresa mediana ejecutaba WordPress detrás de un balanceador que terminaba TLS. Los servidores de origen hablaban HTTP internamente. El equipo asumió que porque el navegador mostraba el icono de candado, la aplicación “sabía” que era HTTPS.

Una tarde, los editores reportaron el bucle de login. No era todo el mundo—solo suficientes personas para desatar el pánico y un torbellino en Slack. El balanceador había sido reemplazado como parte de una renovación de red, y el comportamiento por defecto de las cabeceras cambió.

En el origen, WordPress empezó a ver las peticiones como HTTP. Respondía con redirecciones a HTTPS (porque home era https), pero también establecía cookies de una forma que no coincidía con las expectativas del navegador. La historia de la cookie de autenticación se volvió inconsistente entre peticiones. Los usuarios iniciaban sesión, eran redirigidos y luego tratados como desconocidos y devueltos.

La solución fue aburrida: asegurar que X-Forwarded-Proto: https se estableciera correctamente en el borde, y que el origen la confiara de forma consistente. Una vez que WordPress tuvo una vista estable del esquema, el bucle desapareció.

La lección: en un mundo proxy, “HTTPS” no es un hecho—es una afirmación transmitida por cabeceras. Si no gestionas explícitamente esa afirmación, tu aplicación inventará su propia realidad.

Incidente #2: La optimización que salió mal (cachea todo)

Otra organización tenía una iniciativa de rendimiento. Alguien activó una regla agresiva del CDN para cachear más HTML, incluyendo “páginas de bajo riesgo”. wp-login.php parecía “solo otra página” en el conjunto de reglas. Ese fue el primer error.

En pocas horas, las tasas de éxito de login cayeron. No a cero—solo lo suficiente para confundir. El CDN servía páginas de login cacheadas que contenían nonces obsoletos y objetivos de redirección inconsistentes. Peor todavía, algunas respuestas cacheadas no incluían Set-Cookie correctamente, dependiendo de cómo el borde tratara las cabeceras “no cacheables”.

El incidente se volvió político porque el cambio se presentó como “trabajo de rendimiento”, y el rendimiento se considera heroico. En su lugar, convirtió la autenticación en teatro probabilístico.

La solución fue crear reglas explícitas de bypass para todos los endpoints relacionados con auth y cualquier cosa que estableciera cookies sensibles. Luego añadieron un monitor sintético que realizaba un flujo de login y alertaba sobre cadenas de redirección inesperadas.

La lección: el caché no es una manta. Es un bisturí. Si lo usas como martillo, acabarás golpeando tu propio sistema de login.

Incidente #3: La práctica aburrida pero correcta que salvó el día (inmutabilidad de la config)

Una empresa ejecutaba WordPress en múltiples servidores de aplicación. Tenían una práctica estricta: la configuración, incluidos salts y keys, se gestionaba centralmente y se desplegaba de forma idéntica en cada release. No ediciones manuales. No “arreglos rápidos” en nodos individuales.

Siguieron teniendo un incidente—un ingeniero añadió un nodo nuevo bajo presión. El nodo provenía de una imagen antigua y originalmente tenía un wp-config.php desajustado. En muchos entornos, eso habría creado bucles de login aleatorios dependiendo del backend al que llegara el usuario.

Esto fue lo que los salvó: su pipeline de despliegue detectó la deriva. El nuevo nodo falló una comprobación checksum de configuración y nunca entró en el pool del balanceador. El bucle de login nunca llegó a clientes; se quedó en staging donde pertenecía.

Arreglaron la imagen, redeplegaron y siguieron adelante. No hubo detectiveo nocturno de “por qué ocurre solo a algunos usuarios”.

La lección: la solución de autenticación más fiable es prevenir la inconsistencia. La segunda más fiable es no dejar nodos inconsistentes servir tráfico.

Preguntas frecuentes

¿Por qué WordPress sigue redirigiéndome a la página de login después de iniciar sesión?

Porque WordPress no está recibiendo o aceptando una cookie de autenticación válida en la petición subsiguiente. Eso normalmente lo causan desajustes de URL/esquema, problemas de alcance de cookies, caché, cabeceras de proxy o un plugin que interfiere con las cabeceras.

¿Borrar cookies es la solución real?

Borrar cookies es un paso diagnóstico. Si lo arregla una vez, es probable que hayas cambiado salts/keys recientemente o tuviste una discrepancia transitoria de cookies. Si nunca lo arregla, el problema está en la pila, no en el navegador.

¿Puede un CDN o WAF causar un bucle de login?

Absolutamente. Si cachea wp-login.php, elimina Set-Cookie o desafía las peticiones POST, puedes quedar atrapado en un bucle. Evita el borde para confirmar, luego añade reglas de bypass explícitas.

¿Cuál es la diferencia entre home y siteurl, y por qué importa?

siteurl es donde residen los archivos del core de WordPress; home es lo que el sitio considera su URL pública. Si difieren (especialmente esquema/host), las redirecciones y el alcance de las cookies pueden romper la autenticación.

Estoy detrás de un balanceador. ¿Qué cabecera importa más?

X-Forwarded-Proto. Si es incorrecta o no se confía en ella, WordPress puede creer que está en HTTP incluso cuando el cliente usa HTTPS, provocando redirecciones y flags de cookie rotos.

¿Puede ser un plugin aunque el sitio funcione bien para visitantes?

Sí. Las páginas públicas pueden funcionar mientras los endpoints de admin/auth fallan porque los plugins se enganchan al login, redirecciones, checks de seguridad y manejo de cabeceras. Desactiva plugins para comprobarlo.

¿Por qué pasa solo a algunos usuarios en un entorno balanceado?

Normalmente por deriva de configuración (salts/keys distintos) o suposiciones stateful. Si un backend rechaza cookies creadas por otro backend, obtendrás comportamiento “funciona a veces”. Haz la configuración idéntica y evita hacks stateful.

¿Resetear los salts de WordPress arreglará el bucle?

Resetear salts invalida todas las sesiones, lo cual puede “arreglar” bucles causados por cookies inconsistentes o comprometidas. Pero si la causa raíz es cabeceras de proxy, caché o desajuste de URL, no ayudará—tus usuarios solo serán desconectados y seguirán atascados.

¿Qué hago si no puedo acceder a wp-admin ni a WP-CLI?

Renombra el directorio de plugins vía SSH para desactivar todos los plugins: wp-content/plugins → plugins.disabled. Si eso arregla el login, reintroduce los plugins con cuidado. Si no, céntrate en home/siteurl y detección de proxy/HTTPS.

Conclusión: próximos pasos para evitar recurrencias

Arreglar un bucle de inicio de sesión de WordPress es menos cuestión de heroísmo y más de negarse a que tu propia pila te mienta. Sigue las cookies. Sigue las redirecciones. Confirma qué considera WordPress la URL canónica y confirma qué hace realmente el navegador.

Pasos prácticos siguientes:

1. Haz que home y siteurl coincidan exactamente (esquema + host).
2. Asegura que tu proxy/CDN no cachee ni modifique wp-login.php y /wp-admin/, y que nunca elimine Set-Cookie.
3. Verifica la detección de HTTPS detrás de proxies mediante cabeceras reenviadas.
4. Desactiva plugins/temas para aislar salida de cabeceras y hooks de autenticación; vuelve a activarlos uno a uno.
5. Estandariza wp-config.php (especialmente salts/keys) en todos los nodos y mantén la hora sincronizada.

Si haces esas cinco cosas, el bucle de login volverá a ser lo que debe ser: una historia que cuentas a otros ingenieros, no un lugar donde vivas.