wp-admin de WordPress no se abre: causas reales y soluciones

Guía de diagnóstico rápido

Si estás de guardia, no filosofes. Haz triage. Tu objetivo es responder tres preguntas rápidamente:

1. ¿Está la petición llegando al servidor? (DNS, CDN/WAF, TLS, vhost, enrutamiento)
2. ¿El servidor web la pasa a PHP correctamente? (configuración Nginx/Apache, salud de PHP-FPM, timeouts)
3. ¿WordPress se está atragantando? (errores fatales de plugins/tema, conexión/latencia de BD, caché de objetos, permisos del sistema de archivos)

Verifica primero (30–90 segundos): borde y estado HTTP

• Desde tu portátil: curl -I https://example.com/wp-admin/ y curl -I https://example.com/wp-login.php.
• Mira los códigos de estado: 200/302/401/403/404/500/502/503/504. No son decoración; son el mapa.
• Si ves 301/302 en bucle, céntrate en la normalización de esquema/host y los dominios de cookie.
• Si ves 502/504, céntrate en PHP-FPM o timeouts de upstream (o en que la aplicación tarda demasiado).
• Si ves 403, revisa reglas de WAF, autenticación básica, permisos de archivos o plugins de seguridad.

Verifica segundo (2–5 minutos): logs con intención

• Registros de error de Nginx/Apache para la marca temporal exacta de tu petición.
• Logs de PHP-FPM y slowlog (si está activado) para trabajadores atascados.
• Registro de depuración de WordPress (solo si puedes habilitarlo de forma segura) para fatales de plugins/tema.

Verifica tercero (5–15 minutos): cuellos de botella de recursos

• Saturación de CPU, presión de memoria, OOM killer, espera en I/O de disco, sistema de archivos lleno.
• Conectividad a la base de datos y latencia de consultas.
• Disponibilidad y timeouts de caché de objetos (Redis/Memcached).

Regla general: wp-admin es más “dinámico” que la página principal. Una página de inicio cacheada puede parecer bien mientras wp-admin está en llamas.

Qué hace realmente wp-admin (y por qué falla)

/wp-admin no es una sola página. Es un conjunto de puntos de entrada PHP (notablemente wp-admin/admin.php) que rápidamente se ramifican hacia:

• Comprobaciones de autenticación (cookies, nonces, roles de usuario)
• Lecturas de base de datos (user meta, options, estados de plugins)
• Lecturas del sistema de archivos (plugins, temas, traducciones)
• Llamadas HTTP (algunos plugins llaman APIs externas en páginas de administración—sí, en serio)
• Endpoints AJAX (admin-ajax.php) que pueden colgarse independientemente

Así que cuando “wp-admin no se abre”, normalmente estás mirando una de estas categorías:

• Bloqueo en la red/borde: DNS incorrecto, CDN/WAF bloquea, desajuste TLS, origen equivocado.
• Error de enrutamiento/configuración HTTP: reglas de reescritura, vhost mal configurado, manejador PHP mal enrutado, fastcgi_param roto.
• Fatal en la aplicación: error de sintaxis en plugin/tema, archivo faltante, versión de PHP incompatible.
• Fallo de dependencias: BD caída/lenta, Redis caído, NFS/EFS atascado, disco lleno, agotamiento de inodos.
• Agotamiento de recursos: pool de PHP-FPM saturado, límite de memoria, tiempo máximo de ejecución, sesiones bloqueadas.
• Bucle de redirecciones/autenticación: desajuste site URL, terminación HTTPS mal configurada, problemas con dominio de cookies.

Una frase para pegar sobre tu monitor:

«La esperanza no es una estrategia.» — Gene Kranz

Los fallos de wp-admin recompensan el método, no el optimismo.

Hechos e historia interesantes (que ayudan a depurar)

• Hecho 1: WordPress comenzó como un fork de b2/cafelog en 2003, y su sistema de plugins creció hasta convertirse en un campo minado de compatibilidad—potente, pero fácil de romper con una actualización defectuosa.
• Hecho 2: wp-login.php y /wp-admin/ son puntos de entrada separados; una falla en uno no siempre implica una falla en el otro. Revisa ambos.
• Hecho 3: Históricamente WordPress asumió despliegues al estilo “LAMP”; las pilas modernas (Nginx + PHP-FPM, proxies inversos, contenedores) requieren cabeceras y conciencia de esquema adicionales para evitar bucles de redirección.
• Hecho 4: La “Pantalla blanca de la muerte” se hizo famosa porque los fatales de PHP solían no renderizar nada en el navegador en configuraciones de producción—los logs eran la única verdad.
• Hecho 5: Muchas peticiones de administración son efectivamente no cacheadas y específicas del usuario, por lo que exponen primero problemas de capacidad de base de datos y PHP—tu página de inicio cacheada puede seguir sonriendo mientras el panel está inaccesible.
• Hecho 6: La tabla options (wp_options) es un punto caliente: las opciones autoload se leen constantemente. Una carga autoload inflada ralentiza cada página de administración.
• Hecho 7: Desde WordPress 5.2, la “protección contra errores fatales” puede enviar correos a administradores y recuperarse en algunos casos—pero no te salvará de problemas de infraestructura, ni arreglará una caché de opcodes rota.
• Hecho 8: El REST API y los endpoints admin-ajax son daños colaterales comunes de reglas de seguridad; un WAF que “ayuda” puede dejar sin funciones a la interfaz de administración de forma silenciosa.

Empieza desde primeros principios: clasifica la falla

1) ¿Puedes alcanzar el origen en absoluto?

Si tu navegador no puede alcanzar el sitio, wp-admin es irrelevante. Verifica DNS, CDN y TLS primero. Muchos “problemas de WordPress” son en realidad “el balanceador de carga habla con el pool equivocado”.

2) ¿Qué código HTTP obtienes, de forma consistente?

• 301/302 en bucle: desajuste de URL/esquema, cabeceras del proxy inverso, problemas de cookies, guerras de canonicalización.
• 403: WAF, lista de permitidos por IP, autenticación básica, permisos de archivos, plugin de seguridad, reglas ModSecurity.
• 404: desajuste de vhost, reglas de reescritura, docroot erróneo, archivos de WordPress faltantes, confusión multisite en rutas.
• 500: fatal de PHP, mala configuración, límite de memoria, plugin/tema roto, caché de opcodes malo, errores de permisos de archivo.
• 502/504: Nginx no puede hablar con PHP-FPM, PHP-FPM saturado/colgado, timeout de upstream, o la app espera en BD/disco.
• 503: modo mantenimiento, origen sobrecargado, despliegue en progreso, o un upstream que intencionalmente descarga carga.

3) ¿Es solo wp-admin o todas las páginas dinámicas?

Compara:

• / (a menudo cacheada)
• /wp-login.php (menos código de plugin que el admin completo)
• /wp-admin/ (más comprobaciones, más hooks de plugins)
• /wp-admin/admin-ajax.php (camino caliente para paneles)

Broma #1: Una capa de cache es como un mantel bonito: puede ocultar el desorden, pero no lava los platos.

4) Decide: ¿configuración, capacidad o código?

Todo lo que hagas debería intentar colocar el incidente en un solo cubo:

• Configuración: cabeceras del proxy, terminación SSL, reglas de reescritura, manejador PHP, propiedad de archivos, SELinux/AppArmor.
• Capacidad: pool de PHP-FPM, conexiones a BD, IOPS, memoria, CPU, Redis.
• Código: actualización de plugin/tema, cambio de versión de PHP, core de WordPress corrupto, mu-plugin personalizado.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas probadas en campo que puedes ejecutar en un host Linux típico. Están escritas para realismo: ejecutas un comando, lees la salida y tomas una decisión. Si estás en contenedores, ejecuta el equivalente dentro del pod/contenedor relevante.

Task 1: Reproduce la falla desde el servidor y captura estado/redirecciones

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-admin/ | head -n 20
HTTP/2 302
date: Sat, 27 Dec 2025 10:12:41 GMT
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly
server: nginx

Qué significa: Estás recibiendo una redirección normal al login. Si los usuarios dicen “wp-admin no se abre”, verifica si el inicio de sesión funciona y si las cookies se están estableciendo/devolviendo.

Decisión: Si ves un bucle de location: rebotando entre HTTP y HTTPS o entre dominios, salta al diagnóstico de bucle de redirección (Tareas 4–6).

Task 2: Verifica si wp-login.php carga pero wp-admin no

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-login.php | head -n 15
HTTP/2 200
date: Sat, 27 Dec 2025 10:12:55 GMT
content-type: text/html; charset=UTF-8
server: nginx

Qué significa: La página de login es accesible. Si wp-admin hace timeout o devuelve 500 pero wp-login está bien, sospecha hooks de plugins durante el bootstrap del admin, lentitud de BD después de la autenticación o capacidad de PHP-FPM.

Decisión: Céntrate en PHP-FPM, BD y fatales de WordPress en lugar de DNS/CDN.

Task 3: Identifica el error exacto del upstream (ejemplo Nginx)

cr0x@server:~$ sudo tail -n 40 /var/log/nginx/error.log
2025/12/27 10:13:10 [error] 1842#1842: *991 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /wp-admin/ HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Qué significa: Nginx habló con PHP-FPM pero no recibió un encabezado de respuesta antes del timeout. Esto casi nunca es “un bug de Nginx”. Es PHP atascado, sobrecargado o esperando BD/disco/red.

Decisión: Revisa la salud del pool PHP-FPM y las peticiones lentas (Tareas 7–9), luego la BD (Tarea 12).

Task 4: Detecta bucles de redirección y dónde comienzan

cr0x@server:~$ curl -sS -o /dev/null -D - -L --max-redirs 10 https://example.com/wp-admin/ | egrep -i 'HTTP/|location:'
HTTP/2 301
location: http://example.com/wp-admin/
HTTP/1.1 301 Moved Permanently
location: https://example.com/wp-admin/
HTTP/2 301
location: http://example.com/wp-admin/
HTTP/1.1 301 Moved Permanently
location: https://example.com/wp-admin/

Qué significa: Estás rebotando entre HTTP y HTTPS. Eso es problema de detección de esquema en proxy inverso / terminación SSL, o WordPress siteurl/home en desacuerdo con la realidad.

Decisión: Arregla la detección de esquema: asegúrate de que X-Forwarded-Proto lo establezca el proxy y que WordPress lo honre (Tarea 6), y valida los ajustes de URL en la BD (Tarea 11).

Task 5: Confirma qué piensa el servidor que es el host/esquema canónico

cr0x@server:~$ php -r 'echo "HTTPS=" . ($_SERVER["HTTPS"] ?? "");'
HTTPS=

Qué significa: En CLI esto está vacío, pero te recuerda el problema real: WordPress decide “¿estoy en HTTPS?” basándose en variables del servidor. Detrás de un proxy, esas variables a menudo están mal a menos que se configuren.

Decisión: Asegura que el servidor web pase los fastcgi params correctos y que tu proxy inyecte las cabeceras forward.

Task 6: Verifica que las cabeceras del proxy inverso lleguen a PHP (Nginx + PHP-FPM)

cr0x@server:~$ sudo grep -R "X-Forwarded-Proto" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42:proxy_set_header X-Forwarded-Proto $scheme;

Qué significa: La cabecera está configurada para ubicaciones proxy, pero wp-admin puede servirse vía fastcgi, no proxy. Bloques diferentes, comportamiento diferente.

Decisión: Si terminas TLS aguas arriba, configura la lógica $_SERVER['HTTPS']='on' en wp-config.php basada en X-Forwarded-Proto, y asegúrate de que tu balanceador realmente la envíe.

Task 7: Revisa el estado de PHP-FPM: ¿están saturados los workers?

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Sat 2025-12-27 09:41:03 UTC; 33min ago
   Main PID: 912 (php-fpm8.2)
     Status: "Processes active: 28, idle: 0, Requests: 18452, slow: 37, Traffic: 2.1req/sec"

Qué significa: Idle es 0. Eso es una prueba contundente: el pool está completamente ocupado. Las peticiones se ponen en cola, Nginx hace timeout, wp-admin “no se abre”.

Decisión: O bien añade capacidad (aumenta pm.max_children con precaución, escala horizontalmente) o reduce el coste por petición (arregla consultas BD lentas, desactiva plugins malos, soluciona atascos de disco).

Task 8: Inspecciona la configuración del pool PHP-FPM para límites que coincidan con tus síntomas

cr0x@server:~$ sudo egrep -n 'pm\.max_children|pm\.max_requests|request_terminate_timeout' /etc/php/8.2/fpm/pool.d/www.conf | sed -n '1,120p'
56:pm.max_children = 20
62:pm.max_requests = 500
115:request_terminate_timeout = 60s

Qué significa: Con max_children 20, los picos de wp-admin pueden saturarse rápido. Un timeout de 60s podría matar operaciones lentas legítimas (como actualizaciones de plugins), pero también evita que se quede completamente bloqueado.

Decisión: Si ves timeouts alrededor de ~60s, esto podría ser autoinfligido. Ajusta según CPU/memoria y perfiles reales de peticiones, no por corazonadas.

Task 9: Identifica si PHP está muriendo por agotamiento de memoria

cr0x@server:~$ sudo tail -n 30 /var/log/php8.2-fpm.log
[27-Dec-2025 10:14:02] WARNING: [pool www] child 2143 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 2345"

Qué significa: Clásico: se alcanzó el límite de memoria. wp-admin tiende a cargar más rutas de código y estructuras de datos grandes.

Decisión: Aumenta el límite de memoria de PHP (con cuidado) y encuentra la causa subyacente (a menudo un plugin que hace consultas administrativas pesadas). No solo subas el límite hasta que el host entre en swap fatalmente.

Task 10: Confirma que los archivos core de WordPress existen y son legibles

cr0x@server:~$ ls -la /var/www/html/wp-admin | head
total 172
drwxr-xr-x  9 www-data www-data  4096 Dec 26 22:01 .
drwxr-xr-x  5 www-data www-data  4096 Dec 27 09:55 ..
-rw-r--r--  1 www-data www-data  7339 Dec 26 22:01 admin.php
-rw-r--r--  1 www-data www-data  1058 Dec 26 22:01 index.php

Qué significa: Los archivos están presentes y son propiedad del usuario de ejecución. Si ves propietarios raros (como un usuario de CI) o archivos faltantes, el core puede haber quedado parcialmente desplegado o sobrescrito.

Decisión: Corrige la propiedad de archivos y restaura un core conocido si es necesario. Las actualizaciones parciales causan fallos extraños solo en admin.

Task 11: Verifica las URLs del sitio almacenadas en la base de datos

cr0x@server:~$ mysql -N -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
siteurl https://example.com
home https://example.com

Qué significa: Si estas están mal (http vs https, dominio equivocado, URL de staging obsoleta), las redirecciones de wp-admin pueden entrar en bucle para siempre o rebotar al host incorrecto.

Decisión: Corrígelas en la BD (o sobrescribe temporalmente en wp-config.php durante la respuesta al incidente). Luego arregla el proceso que permitió la deriva.

Task 12: Revisa la salud de MySQL/MariaDB y las consultas lentas ahora mismo

cr0x@server:~$ mysql -e "SHOW PROCESSLIST;" | head -n 15
Id	User	Host	db	Command	Time	State	Info
214	app	10.0.2.15:51122	wp	Query	28	Sending data	SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
221	app	10.0.2.15:51148	wp	Query	31	Locked	UPDATE wp_options SET option_value = '...' WHERE option_name = 'rewrite_rules'

Qué significa: Las lecturas de opciones autoload tardan decenas de segundos y un UPDATE está bloqueado: esa es una razón real por la que wp-admin se cuelga. Las páginas de administración leen opciones constantemente; la contención de locks allí es veneno.

Decisión: Identifica el poseedor del bloqueo, reduce la contención de locks e investiga payloads autoload inflados. Si es necesario, mata consultas descontroladas durante el outage y arregla el plugin/tarea subyacente.

Task 13: Encuentra el poseedor del bloqueo (InnoDB) y decide si matarlo

cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | egrep -n "LATEST DETECTED DEADLOCK|TRANSACTION|WAITING" | head -n 30
103:TRANSACTION 4211892, ACTIVE 62 sec starting index read
110:LOCK WAIT 12 lock struct(s), heap size 1136, 6 row lock(s)
121:MySQL thread id 221, OS thread handle 140520112060160, query id 981231 10.0.2.15 app updating

Qué significa: Tienes una espera de lock de ~60 segundos. Las peticiones admin de WordPress pueden acumularse detrás de esto y saturar PHP-FPM.

Decisión: Durante la respuesta al incidente, considera matar la sesión bloqueadora si es seguro (KILL 221;) y comprendes los efectos secundarios (actualizaciones parciales, instalaciones de plugins). Luego realiza el análisis de causa raíz.

Task 14: Revisa espacio en disco y agotamiento de inodos (asesinos silenciosos)

cr0x@server:~$ df -h /var/www/html /var/lib/mysql
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   79G  650M  99% /
/dev/vdb1       200G  120G   81G  60% /var/lib/mysql

cr0x@server:~$ df -i /var/www/html
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      5242880 5239011   3869  100% /

Qué significa: Te quedaste sin inodos. Eso puede romper sesiones, subidas, actualizaciones de plugins, escrituras de cache y logs. Se manifiesta como “wp-admin está roto” de maneras creativamente poco útiles.

Decisión: Libera inodos (limpia temp/cache, lanzamientos antiguos, rota logs) y añade monitorización. Disco lleno es predecible; trátalo como una falla de proceso, no como un acto de la naturaleza.

Task 15: Identifica espera de I/O que vuelve todo “lento”

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server)  12/27/2025  _x86_64_ (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    4.22   62.35    0.00   21.33

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
vda              4.20   85.30   92.1   941.4    8.12  91.3  98.7

Qué significa: 62% de iowait y utilización de disco cercana al 100%. Tu “problema de WordPress” es en realidad latencia de almacenamiento. wp-admin realiza muchas lecturas pequeñas (archivos PHP, sesiones, options), así que sufre primero.

Decisión: Reduce I/O (desactiva logs ruidosos, arregla jobs de backup, mueve sesiones/caché de objetos a memoria, mejora el tier de almacenamiento) o escala para más IOPS. No ajustes timeouts de PHP para “arreglar” un colapso de almacenamiento.

Task 16: Confirma la salud del caché de objetos Redis (si se usa)

cr0x@server:~$ redis-cli -h 127.0.0.1 ping
PONG

cr0x@server:~$ redis-cli -h 127.0.0.1 info stats | egrep 'instantaneous_ops_per_sec|rejected_connections'
instantaneous_ops_per_sec:1874
rejected_connections:0

Qué significa: Redis está vivo y no rechaza conexiones. Si Redis está caído y WordPress está configurado para usarlo, wp-admin puede estacarse en timeouts de conexión según la configuración del cliente.

Decisión: Si Redis falla, restaura o desactiva temporalmente el drop-in de caché de objetos (wp-content/object-cache.php) para restaurar acceso al admin.

Task 17: Deshabilitar plugins sin acceso a wp-admin (forma relativamente segura)

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ mv plugins plugins.disabled
cr0x@server:~$ mkdir plugins
cr0x@server:~$ chown -R www-data:www-data plugins

Qué significa: WordPress no cargará plugins si el directorio está vacío. Esta es la forma más rápida de confirmar “un plugin causó la muerte del admin”.

Decisión: Si wp-admin vuelve, restaura plugins uno por uno (o busca binariamente) para encontrar al culpable. Luego actualízalo/reemplázalo. Si no vuelve, los plugins no son la causa primaria—continúa investigando.

Task 18: Cambiar a un tema por defecto si el admin está atado al tema

cr0x@server:~$ mysql -N -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
template	twentytwentyfour
stylesheet	twentytwentyfour

Qué significa: Esto fuerza un tema por defecto. Algunos temas (o frameworks de tema) se enganchan en el admin y pueden romperlo.

Decisión: Si el admin se recupera, tu tema es el culpable o expuso un problema de versión de PHP. Arregla en staging y despliega seguro.

Task 19: Comprueba si el “modo mantenimiento” quedó activado

cr0x@server:~$ test -f /var/www/html/.maintenance && echo "maintenance file present" || echo "no maintenance file"
maintenance file present

Qué significa: Una actualización fallida puede dejar WordPress en modo mantenimiento, devolviendo comportamiento tipo 503 o una página de “Temporalmente no disponible”.

Decisión: Elimina .maintenance solo si estás seguro de que no hay una actualización en curso. Luego reejecuta la actualización correctamente.

Task 20: Habilita el registro de depuración de WordPress temporalmente (radio de blast controlado)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/html/wp-config.php | head"
90:define('WP_DEBUG', false);
91:define('WP_DEBUG_LOG', false);
92:define('WP_DEBUG_DISPLAY', false);

Qué significa: El debug está apagado (bien). Cuando wp-admin está caído por fatales, puede que necesites logs. Pero no muestres errores en HTML en producción.

Decisión: Activa WP_DEBUG_LOG a true y mantén WP_DEBUG_DISPLAY en false, reproduce una vez, y luego vuelve a apagarlo y haz tail de wp-content/debug.log.

Broma #2: Activar debug en producción es como encender las luces de la cabina durante la turbulencia—útil, pero nadie se relaja después.

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

“Demasiadas redirecciones” en /wp-admin

Síntoma: Error del navegador o curl muestra alternancia 301/302 entre http/https o entre dominios.

Causa raíz: Desajuste siteurl/home, el proxy no establece X-Forwarded-Proto, WordPress piensa que es HTTP mientras el cliente usa HTTPS, o un plugin de redirección canónica pelea con el balanceador.

Solución: Asegura cabeceras forward correctas; corrige siteurl/home; añade detección explícita de HTTPS en wp-config.php cuando hay terminación TLS detrás; elimina lógica duplicada de redirección.

Pantalla blanca en blanco (sin HTML, sin error)

Síntoma: wp-admin devuelve una página vacía, a veces 200.

Causa raíz: Fatal de PHP con display_errors apagado; confusión de opcache tras un despliegue; plugin/tema roto; agotamiento de memoria.

Solución: Revisa logs de PHP-FPM y del servidor web; habilita registro WP debug brevemente; revierte actualización de plugin/tema; limpia opcache reiniciando el servicio si procede.

502 Bad Gateway desde Nginx (o 504 Gateway Timeout)

Síntoma: Nginx devuelve 502/504; el log de errores menciona upstream timed out o connect() failed al socket de php-fpm.

Causa raíz: PHP-FPM caído, ruta de socket equivocada, pool saturado, o PHP esperando BD/disco/red.

Solución: Reinicia PHP-FPM si está colgado; arregla permisos/rutas de socket; aumenta capacidad; encuentra y elimina la ruta lenta (plugin, bloqueo BD, latencia de almacenamiento).

403 Forbidden solo en wp-admin

Síntoma: La página principal carga; wp-admin da 403.

Causa raíz: Regla de WAF activada por cookies de admin o query strings; autenticación básica aplicada por error; plugin de seguridad bloqueando IP; permisos de wp-admin.

Solución: Revisa logs del WAF; whitelist de rutas de admin con cuidado; confirma bloques de ubicación en Nginx/Apache; corrige propiedad/permisos; verifica que no haya reglas deny accidentales.

“Error establishing a database connection” al acceder al admin

Síntoma: Página de error de BD, a menudo intermitente durante carga.

Causa raíz: BD caída, conexiones máximas alcanzadas, problemas de red, DNS del host de BD roto, o consultas lentas que generan acumulación de conexiones.

Solución: Revisa salud de BD, processlist y límites de conexiones; escala BD; optimiza consultas; asegúrate de que la app use conexiones persistentes solo si entiendes sus consecuencias.

Inicio de sesión funciona, pero wp-admin carga eternamente

Síntoma: Credenciales aceptadas; el panel nunca termina de cargar.

Causa raíz: Llamadas a admin-ajax.php colgando por un plugin, REST API bloqueada, o llamada a API externa lenta desde el admin.

Solución: Inspecciona la pestaña red en las herramientas del navegador para solicitudes atascadas; haz tail de logs para admin-ajax; desactiva plugins; bloquea o acorta timeouts a llamadas externas; permite endpoints REST a través de capas de seguridad.

Solo algunos usuarios pueden acceder al wp-admin

Síntoma: Funciona para ti, falla para compañeros; o funciona en móvil pero no en laptop corporativa.

Causa raíz: Misconfiguración de dominio/ruta de cookie, problemas SameSite detrás de SSO, proxy corporativo caché o que quita cabeceras, reglas de allowlist por IP.

Solución: Normaliza dominio y esquema; revisa atributos Set-Cookie; evita listas de permitidos por IP salvo que controles la red; verifica comportamiento del proxy.

Tres microhistorias corporativas desde el campo

Incidente #1: La suposición equivocada (edición “no puede ser DNS”)

Una empresa mediana gestionaba WordPress para páginas de marketing y un portal de socios protegido dentro de wp-admin. La página principal estaba detrás de un caching agresivo en el CDN. Todo parecía sano desde fuera: las landing pages cargaban al instante, los checks de uptime pasaban, los ejecutivos dejaron de preguntar. Naturalmente, aquí empezó el verdadero problema.

Sales ops reportó que nadie podía iniciar sesión. Los ingenieros intentaron lo usual: limpiar cache, probar en incógnito, culpar a las cookies. Alguien insistió, con confianza, que “DNS está bien porque el sitio carga”. Esa suposición mantuvo el incidente cautivo durante dos horas.

El truco: el CDN tenía dos orígenes configurados. Las páginas estáticas se servían desde el origen A (correcto). Las rutas de administración se enroutaban al origen B (entorno antiguo) debido a una regla basada en rutas obsoleta añadida durante una migración previa. El origen B aún respondía, pero con un certificado TLS distinto y un siteurl de WordPress diferente, así que rebotaba a los usuarios en un bucle de redirección hasta que los navegadores se rindieron.

La solución fue aburrida: corregir las reglas de enrutamiento del CDN y purgar el comportamiento equivocado. La lección fue más aguda: “el sitio carga” no es un chequeo de salud. Necesitas chequeos que golpeen /wp-login.php y un endpoint dinámico de admin, no solo la página principal cacheada.

Incidente #2: Una optimización que salió mal (edición caché de objetos)

Otro equipo persiguió rendimiento. Añadieron un drop-in de caché de objetos Redis para reducir la carga de la base de datos. En staging se veía genial: menos consultas a BD, generación de páginas más rápida, gráficas felices. Lo pusieron en producción en una ventana de bajo tráfico y se fueron a casa sintiéndose responsables.

Tres días después, wp-admin empezó a tener timeouts intermitentes. La página principal seguía rápida porque estaba cacheada en el borde. El panel, sin embargo, se volvió una moneda al aire. Los trabajadores PHP-FPM se acumulaban en estado “busy”. Los logs de Nginx se llenaron de timeouts de upstream. La base de datos se veía más tranquila de lo habitual, lo cual era… sospechosamente calmante.

El verdadero problema era la ruta de red y los timeouts. Redis vivía en un nodo separado. Bajo ciertas condiciones de pérdida de paquetes, el cliente Redis se atascaba por más tiempo del timeout del upstream del tier web. Cada petición admin esperaba lecturas de cache, reteniendo un worker PHP secuestrado. Suficientes rehenes y el pool se satura. Entonces todo parece “WordPress caído”, cuando en realidad tu caché está caído de la forma más molesta: no muerto, solo lento.

La resolución incluyó establecer timeouts de cliente sensatos, añadir monitorización de salud de Redis e implementar una estrategia de “fail open” para la caché de objetos cuando procede. La optimización no falló porque la cache sea mala; falló porque el equipo trató una nueva dependencia como si fuera tan fiable como localhost.

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

Otra organización ejecutaba múltiples sitios WordPress en infraestructura compartida. No glamoroso. Lo que sí tenían era una práctica disciplinada de releases: directorios de deploy inmutables, un swap de symlink y un rollback documentado que cualquiera de guardia podía ejecutar a las 3 a.m. sin inventar sintaxis nueva.

Una noche una actualización de plugin introdujo un fatal de PHP en el bootstrap del admin para un subconjunto de peticiones—específicamente al cargar una página de ajustes que llamaba a una función inexistente bajo PHP 8.2. Las páginas frontend siguieron bien por el caching y porque la ruta fatal era solo de admin. El incidente se reportó como “los administradores no pueden publicar”. Eso es un outage de negocio, incluso si tu dashboard de uptime sigue en verde.

El ingeniero de guardia no hizo SSH para “hurgar”. Siguió el runbook: cambió el symlink al release anterior, reinició PHP-FPM para limpiar opcache, verificó el chequeo de salud de wp-admin y solo entonces empezó el análisis de causa raíz. Las operaciones del negocio se reanudaron en minutos.

Después, probaron el plugin en un staging con la misma versión de PHP que producción y publicaron una versión corregida. Nadie escribió un postmortem heroico sobre “quedarse despierto toda la noche”. Escribieron un ticket tranquilo: “Agregar cheks sintéticos en rutas admin y aplicar gates para actualizaciones de plugins”. Lo aburrido salvó el día, otra vez.

Listas de verificación / plan paso a paso

Paso a paso: restaurar acceso a wp-admin de forma segura

1. Confirma el alcance: ¿Es solo para ti, solo desde algunas redes o para todos? Prueba desde dos puntos (tu portátil + el servidor).
2. Captura comportamiento HTTP: código de estado, cadena de redirecciones y cabeceras de respuesta para /wp-admin/ y /wp-login.php.
3. Mira los logs del servidor web: empareja la marca temporal y el request ID si tienes uno.
4. Revisa la salud de PHP-FPM: está corriendo, saturado, registrando fatales, peticiones lentas.
5. Revisa la salud de la BD: conectividad, locks, consultas lentas, conexiones máximas.
6. Revisa el disco: espacio + inodos + espera de I/O. Aquí es donde vienen los comportamientos “aleatorios”.
7. Descarta plugins rápidamente: renombra wp-content/plugins. Si el admin vuelve, aísla el culpable.
8. Descarta el tema: cambia a un tema por defecto mediante actualización en BD si es necesario.
9. Confirma ajustes de URL canónica: siteurl y home. Arregla desajustes que causan bucles.
10. Sólo entonces ajusta timeouts/capacidad: los timeouts no arreglan dependencias rotas; son una barrera de seguridad.
11. Haz rollback si hubo un cambio reciente: Si wp-admin murió tras una actualización, no debatas—revierte y estabiliza, luego investiga.
12. Escribe la causa raíz mientras está fresca: tu yo futuro es una persona distinta con menos contexto y más alertas.

Checklist: saneamiento de proxy inverso y offload HTTPS

• El load balancer envía X-Forwarded-Proto y X-Forwarded-For.
• El servidor web pasa cabeceras/params relevantes a PHP.
• WordPress ve HTTPS correctamente (especialmente para cookies de wp-admin marcadas secure).
• siteurl y home coinciden con la URL pública, incluyendo esquema.
• No hay lógica de redirección duplicada (load balancer + plugin + servidor web) peleando entre sí.

Checklist: capacidad y salud de dependencias

• PHP-FPM tiene workers inactivos bajo carga normal.
• BD muestra bajas esperas de locks y tiempos de consulta razonables para options/usuarios.
• El disco tiene margen en espacio e inodos; los backups no colisionan con el tráfico pico.
• Redis/Memcached está saludable o configurado para fallar rápido/fail open.
• La monitorización incluye checks sintéticos que golpean /wp-login.php y un endpoint dinámico no cacheado.

Preguntas frecuentes

¿Por qué la página principal funciona pero wp-admin está caído?

Porque la página principal probablemente está cacheada (CDN, plugin de page cache, cache de proxy inverso). wp-admin es específico del usuario y dinámico, por lo que golpea PHP y la base de datos directamente. Las fallas en admin suelen ser problemas de capacidad o dependencias que la cache enmascara.

¿Cuál es la forma más rápida de saber si un plugin es el problema?

Renombra wp-content/plugins para que WordPress cargue cero plugins, y prueba wp-admin de nuevo. Si se recupera, has probado “falla inducida por plugin”. Luego restaura plugins gradualmente para encontrar al culpable.

¿Subir el límite de memoria de PHP es una solución real?

A veces. Si los logs muestran agotamiento de memoria, aumentar el límite puede restaurar el acceso. Pero trátalo como un torniquete. La causa subyacente suele ser una página admin que hace consultas pesadas o que carga payloads enormes en options.

¿Qué causa “demasiadas redirecciones” específicamente en wp-admin?

Usualmente confusión de esquema/host: terminación TLS en un proxy sin cabeceras correctas, home/siteurl desajustados, o un plugin de redirección forzando https mientras el origen piensa que es http.

¿Cómo depuro una pantalla blanca sin mostrar errores a los usuarios?

Revisa primero logs de Nginx/Apache y PHP-FPM. Si es necesario, habilita WP_DEBUG_LOG manteniendo WP_DEBUG_DISPLAY apagado, reproduce una vez y luego revierte. Lee wp-content/debug.log.

¿Puede Cloudflare/CDN/WAF bloquear wp-admin aunque el sitio cargue?

Sí. Las reglas del WAF suelen apuntar a /wp-admin, wp-login.php, REST API o patrones de admin-ajax. Además, los CDNs pueden enrutar rutas admin de forma distinta. Revisa logs de borde y reglas de enrutamiento por ruta.

¿Cómo sé si es saturación de PHP-FPM versus una única dependencia lenta?

La saturación de PHP-FPM se muestra como “idle: 0” y peticiones en cola, a menudo con timeouts de upstream. Entonces debes encontrar por qué los workers están ocupados: consultas BD lentas/locks, espera de I/O, o llamadas a APIs externas. No te quedes en “el pool está lleno”.

¿Cuál es el problema de BD más común detrás de cuelgues en wp-admin?

Contención de locks y consultas lentas en la tabla options. El admin carga options constantemente, y ciertos plugins actualizan options de forma que mantienen locks más tiempo del esperado.

¿Debería reiniciar servicios durante un incidente?

Reiniciar PHP-FPM puede ser una medida táctica válida si está colgado o el opcache está corrupto tras un despliegue. Reiniciar a ciegas, repetidamente, sin logs es la forma en que los incidentes se vuelven misterios. Captura logs y síntomas primero, luego reinicia con intención.

¿Cómo evito que las caídas de wp-admin pasen desapercibidas?

Añade monitorización sintética que golpee /wp-login.php y un endpoint dinámico (no cacheado). Alerta por aumento de 5xx, bucles de redirección y timeouts de upstream. “Homepage 200 OK” no es una estrategia de fiabilidad.

Conclusión: pasos siguientes para evitar repeticiones

Cuando wp-admin no se abre, deja de tratarlo como un enigma de WordPress y empieza a tratarlo como un incidente de producción. Identifica la clase de fallo (redirecciones, 5xx, timeouts, bucles de auth), confirma dónde muere la petición (borde, servidor web, PHP, BD, almacenamiento) y haz el cambio más pequeño y seguro que restaure el acceso.

Haz lo siguiente, en orden:

1. Añade checks de salud en rutas admin (página de login más un endpoint dinámico) para que la cache no pueda mentirte.
2. Instrumenta la pila: tiempos de upstream del servidor web, saturación de PHP-FPM, esperas de locks en BD, espera de I/O de disco y llenado de sistema de archivos (espacio e inodos).
3. Facilita los rollbacks: releases inmutables, swaps de symlink y un runbook de rollback con un comando.
4. Controla las actualizaciones de plugins: staging que coincida con la versión de PHP de producción y una puerta para plugins de alto riesgo que tocan mucho el admin.
5. Decide la postura de dependencias: si añades Redis, NFS, reglas WAF o una nueva capa proxy, también añades nuevas formas en que wp-admin puede fallar. Diseña timeouts y modos de fallo deliberadamente.

El panel no es especial. Es simplemente tu endpoint más honesto—no cacheado, con estado y despiadado. Trátalo en consecuencia.