El 504 Gateway Timeout es uno de esos errores que duelen porque no suele ser “tu culpa”… pero sí afecta a tus usuarios y a tu SEO. En la práctica significa que un servidor intermedio (proxy/gateway/load balancer/CDN) no recibió a tiempo la respuesta del servidor que hospeda tu web. Resultado: tiempos de espera, páginas que no cargan y posibles deslistados si un crawler se topa repetidamente con el fallo.
La buena noticia: puedes acotar el origen y arreglarlo con un proceso simple de descarte. Aquí tienes 11 formas de solucionarlo, de más rápida a más técnica.
Antes de empezar: qué es un 504 y por qué ocurre
Un 504 es un HTTP 5xx (error en servidor/red). El patrón simplificado:
- El navegador resuelve DNS → llega a tu proveedor → pasa por un proxy/balanceador/CDN.
- Ese “puente” reenvía la petición al servidor web origen (donde vive tu WordPress).
- Si el origen no responde a tiempo (carga, fallo de red, mantenimiento, backend saturado…), el proxy devuelve 504.
Causas típicas:
- Origen sobrecargado o down (picos, mantenimiento, DDoS).
- Red entre proxy y origen con fallos/latencias.
- DNS sin propagar o mal configurado.
- Firewall/WAF/CDN bloqueando/atascando respuestas.
- Plugins o reglas de .htaccess que rompen flujos.
- Límites de tiempo demasiado bajos en Apache/PHP/Nginx.
Comprobaciones rápidas (locales)
Estas descartan que el problema sea “de tu lado” (caché, VPN, navegador).
1) Recarga y force refresh
- Espera unos segundos y recarga.
- Actualización forzada para evitar cachés:
- Windows:
Ctrl + F5
(Chrome/Firefox/Edge) - macOS:
Cmd + Shift + R
(Chrome/Firefox),Cmd + Opt + R
(Safari)
- Windows:
- Prueba en otro navegador o en modo incógnito.
2) Reinicia equipo/red y desconecta VPN
- Reinicia tu dispositivo y, si procede, tu router.
- Desconecta tu VPN y vuelve a probar (las VPN usan proxies; a veces, interfieren).
3) Revisa DNS si migraste recientemente
- Cambios de DNS pueden tardar hasta 48 h.
- Usa un comprobador de propagación global (p. ej., DNSMap).
- Si ya propagó, revisa en tu hosting los registros A/AAAA y nameservers.
Si sigue fallando, pasamos al servidor/WordPress.
Diagnóstico en servidor/WordPress
4) Consulta logs del servidor (y de WordPress)
- En cPanel: Metrics → Errors.
- En paneles propios, busca sección Logs (error/access logs).
- Si usas un plugin de logs en WordPress, revísalo.
- Anota timestamps, ruta afectada y mensaje (p. ej., upstream timed out, proxy_read_timeout).
Sin logs no siempre implica que todo esté bien: algunos hosts exponen registros mínimos.
5) Revisa el firewall/WAF de WordPress
- Si usas un plugin (Wordfence, iThemes, etc.), desactívalo temporalmente y prueba.
- Si se arregla, mira los logs del WAF o sus reglas (subidas, REST API, cron).
- Vuelve a activar tras la prueba.
6) Desactiva plugins recientes (y luego todos, si hace falta)
- Desactiva lo último que instalaste/actualizaste (CDN, seguridad, caché).
- Si no cambia, desactiva todos (desde Plugins → Acciones en lote → Desactivar) y prueba.
- Si vuelve a funcionar, actívalos uno a uno hasta identificar el conflictivo.
7) Cambia temporalmente al tema por defecto
- Activa Twenty Twenty-One (o similar) → prueba.
- Si con el tema por defecto funciona, tu tema está causando saturación o conflicto (evalúa soporte o cambio de tema).
8) Restablece .htaccess a valores por defecto
Plugins y hardening añaden reglas que a veces rompen el flujo.
- En File Manager/FTP, ve a
public_html/
y copia.htaccess
a.htaccess.bk
. - Sustituye su contenido por:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Lenguaje del código: HTML, XML (xml)
- Guarda y prueba.
- Si funciona, el problema era alguna regla añadida. Reconstruye activando plugins uno a uno.
9) Comprueba tu CDN (Cloudflare u otros)
- Si ves “cloudflare-nginx” en la página de error, apunta al CDN.
- Desactiva temporalmente el proxy (modo DNS only) o pausa el sitio en el panel del CDN y prueba directo al origen.
- Si así funciona, revisa: modo desarrollo, cache rules, WAF, origen disponible (si el origen está caído y el CDN no tiene cache HIT, devolverá 5xx).
Ajustes de tiempo de espera (host/servidor)
Nota: estos cambios pueden requerir permisos. Si no tienes acceso, envía esta sección al soporte de tu hosting.
10) Aumenta el timeout del servidor web
Apache: en httpd.conf
añade (o aumenta) y reinicia:
TimeOut 600
Rutas comunes:/etc/apache2/httpd.conf
· /etc/apache2/apache2.conf
· /etc/httpd/httpd.conf
· /etc/httpd/conf/httpd.conf
Nginx: en el bloque http
/server
/location
ajusta y recarga:
proxy_read_timeout 600;
proxy_connect_timeout 60;
proxy_send_timeout 600;
fastcgi_read_timeout 600;
11) Amplía el PHP max_execution_time
Si no puedes tocar Apache/Nginx, sube el tiempo de ejecución de PHP:
- En
php.ini
(raíz del sitio):
; respaldo previo: copia php.ini a php.ini.bk
max_execution_time = 300
- O en
.user.ini
/.htaccess
(si tu host lo admite):
; .user.ini
max_execution_time = 300
# .htaccess
php_value max_execution_time 300
Lenguaje del código: CSS (css)
Reinicia PHP-FPM si procede.
Cuándo escalar a tu proveedor
Si tras estas pruebas el 504 persiste:
- Abre ticket con hora exacta, IPs/URLs afectadas, capturas y logs (upstream timeout, connect() failed, 502/504 desde CDN).
- Pide revisión de: salud del origen, load average, límite de procesos PHP, límites de conexión, reglas WAF y tiempos de espera en LB/CDN/origen.
- Si migraste, confirma propagación DNS, IP del origen correcta y health checks.
¿Se puede prevenir?
Ninguna medida evita un fallo físico del hosting, pero puedes reducir probabilidades:
- Caché a varios niveles: página (plugin), objeto (Redis/Memcached), OPcache.
- CDN bien configurado: cache rules, stale-while-revalidate, Always Online (si aplica).
- Monitorización: UptimeRobot/healthchecks + alertas de errores 5xx.
- Cron optimizado: desactiva WP-Cron por visita y usa cron real del servidor.
- Escala vertical/horizontal según tráfico; limita peticiones costosas (búsquedas pesadas, imports grandes en hora punta).
- Mantén plugins/tema/core al día y evita extensiones que hagan consultas lentas.
- Asegura timeouts razonables en proxy/origen/PHP, adecuados a tu carga real.
Resumen de solución rápida
- Recarga/force refresh y prueba otro navegador.
- Desconecta VPN y reinicia equipo/router.
- Comprueba DNS si hubo migración.
- Mira logs (servidor/WordPress).
- Desactiva WAF/plugins recientes → luego todos → reactivación uno a uno.
- Cambia al tema por defecto (prueba).
- Restablece
.htaccess
a valores WP. - Pausa CDN / quita proxy.
- Sube timeouts en Apache/Nginx/PHP.
- Ticket al hosting con evidencias.
Sigue el orden de menos a más intrusivo; la mayoría de 504 se resuelven entre plugins/WAF/CDN y timeouts.
Preguntas frecuentes (FAQ)
¿Un 504 es culpa de mi navegador?
Rara vez. Es un error en servidor/red. Aun así, borra caché, prueba otro navegador y desconecta VPN para descartar lo local.
¿Un 504 afecta al SEO?
Sí, si se prolonga. Crawlers que encuentran repetidamente 5xx pueden degradar o desindexar URLs. Monitoriza y corrige rápido.
¿Cómo sé si es el CDN?
Si la página de error nombra al CDN (p. ej., cloudflare-nginx), probablemente el fallo está entre CDN ↔ origen. Pausa el proxy y prueba directo al servidor.
¿Aumentar timeouts es “hacer trampas”?
No, si se hace con criterio. Peticiones legítimas (importaciones, consultas pesadas, integraciones) pueden necesitar más tiempo. Úsalo junto con caché/optimización para no “tapar” problemas estructurales.
¿Puede un plugin causar 504?
Sí. Un plugin que sobrecarga consultas, un WAF demasiado agresivo o reglas en .htaccess pueden impedir que el origen responda a tiempo.
¿Te sigue fallando o necesitas ayuda con los ficheros de tu hosting? Cuéntame tu proveedor, panel (ServerAvatar, RunCloud, flywp, Ploi.io, Plesk o cPanel, DirectAdmin, AAPanel u otro) y qué logs ves y te guío paso a paso.