---
title: "Cómo arreglar el error 504 Gateway Timeout en WordPress (11 soluciones probadas)"
description: "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/..."
url: https://wpdirecto.com/como-arreglar-el-error-504-gateway-timeout-en-wordpress-11-soluciones-probadas/
date: 2025-10-15
modified: 2025-10-15
author: "Editor WPDirecto"
image: https://wpdirecto.com/wp-content/uploads/2025/10/error504-gateway-timeout.jpg
categories: ["Actualidad"]
tags: ["error 504", "gateway timeout"]
type: post
lang: es
---

# Cómo arreglar el error 504 Gateway Timeout en WordPress (11 soluciones probadas)

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)
```

1. Guarda y prueba.
2. 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](https://wpdirecto.com/serveravatar), RunCloud, [flywp](https://wpdirecto.com/flywp), Ploi.io, Plesk o cPanel, DirectAdmin, [AAPanel](https://administraciondesistemas.com/aapanel) u otro) y qué **logs** ves y te guío paso a paso.