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:

1. El navegador resuelve DNS → llega a tu proveedor → pasa por un proxy/balanceador/CDN.
2. Ese “puente” reenvía la petición al servidor web origen (donde vive tu WordPress).
3. 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)
• 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.

1. En File Manager/FTP, ve a public_html/ y copia .htaccess a .htaccess.bk.
2. 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)

3. Guarda y prueba.
4. 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

1. Recarga/force refresh y prueba otro navegador.
2. Desconecta VPN y reinicia equipo/router.
3. Comprueba DNS si hubo migración.
4. Mira logs (servidor/WordPress).
5. Desactiva WAF/plugins recientes → luego todos → reactivación uno a uno.
6. Cambia al tema por defecto (prueba).
7. Restablece .htaccess a valores WP.
8. Pausa CDN / quita proxy.
9. Sube timeouts en Apache/Nginx/PHP.
10. 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.