Un 504 significa que una pasarela o proxy esperó demasiado la respuesta del servicio posterior. Si solo falla una acción administrativa, probablemente la petición realiza más trabajo del que permite el tiempo del proxy: una importación, edición masiva, copia, llamada a una API o una operación lenta de base de datos.
No pulses el botón repetidamente. La primera petición puede continuar después de que el navegador muestre 504 y generar importaciones, mensajes o cambios duplicados.
Conserva los datos exactos de la acción
Anota URL administrativa, botón o acción, hora de inicio y fallo, registros seleccionados, rol y cualquier identificador de trabajo. Comprueba si el resultado previsto aparece unos minutos después.
Relaciona:
hora e ID del 504 del proxy
duración upstream del servidor web
proceso o registro PHP
consulta o bloqueo MySQL
registro del plugin o tarea en segundo planoNo incluyas datos personales ni nonces en pruebas compartidas.
Identifica la capa que agota el tiempo
Cloudflare, el balanceador, Nginx o Apache, PHP y las APIs externas tienen límites distintos. Revisa cabeceras y registros para descubrir qué capa generó el 504.
Aumentar max_execution_time de PHP no ayuda si el proxy deja de esperar antes. Del mismo modo, ampliar el proxy solo esconde una tarea ineficiente.
Utiliza ajustes compatibles con el alojamiento y documenta los valores efectivos en web y CLI.
Comprueba si el trabajo continúa
Antes de reintentar, revisa procesos PHP activos, tareas programadas y estado del plugin. Algunas herramientas encolan el trabajo y el navegador solo espera una confirmación; otras lo hacen todo sincrónicamente.
Si la petición original sigue en marcha, deja que termine o detenla mediante controles autorizados después de evaluar el riesgo de escrituras parciales.
Dos tareas masivas simultáneas pueden bloquearse entre ellas y empeorar el timeout.
Audita resultados parciales
Compara el conjunto previsto con lo que realmente cambió. Para una importación utiliza identificadores estables; para una edición masiva, fechas de modificación y el campo objetivo; para correo, identificadores del proveedor.
No tomes la última pantalla visible como punto de control: el servidor puede procesar más elementos después de que el proxy se desconecte. Crea una lista acotada de excepciones y decide para cada una si hay que reanudar, revertir o no hacer nada.
Rastrea esperas MySQL
Consulta pruebas de consultas lentas y bloqueos durante esa ventana. Una actualización masiva puede recorrer metadatos sin índice o esperar detrás de una transacción de copia o importación.
Ejecuta EXPLAIN sobre una consulta equivalente y anonimizada en staging. No mates hilos MySQL ni añadas índices sin entender las transacciones activas y el coste de escritura.
Haz commits en lotes acotados para liberar bloqueos con regularidad.
Examina dependencias remotas
Licencias, descarga de imágenes, CRM, DNS y APIs pueden esperar sin un límite razonable. Relaciona identificadores del proveedor y errores cURL del servidor.
Las llamadas HTTP propias deben fijar tiempos de conexión y respuesta, y tratar de forma segura un resultado desconocido. No reintentes a ciegas operaciones externas no idempotentes.
Pasa el trabajo remoto no esencial a una cola y muestra el progreso al administrador.
Convierte el trabajo síncrono en lotes
Importaciones, sustituciones y regeneración de medios deberían procesar un número conocido por petición o ejecutarse mediante WP-CLI o tareas del servidor.
Diseño seguro de lotes:
identificadores estables
punto de control tras cada lote
reintento idempotente
lista de errores visible
reanudar sin empezar de nuevoNo guardes todo el conjunto en una única opción de WordPress ni en un solo array de PHP.
Ajusta límites solo cuando esté justificado
Si el trabajo medido es eficiente pero supera legítimamente un plazo corto, ejecútalo por CLI o en segundo plano. Aumentar el timeout de la web pública retiene procesos y facilita una denegación de servicio.
Calcula workers PHP, memoria y capacidad de base de datos para tareas concurrentes. Programa la administración pesada fuera de horas punta.
Conserva una copia independiente antes de una mutación masiva.
Verifica finalización y reversión
Repite un lote pequeño y controlado y confirma que responde antes de todos los límites relevantes. Revisa recuentos, registros y resultados parciales de intentos anteriores.
Prueba páginas públicas y administrativas mientras se ejecuta el trabajo. El mantenimiento recurrente debe vigilar peticiones administrativas largas y tareas fallidas; un flujo reparado termina de forma predecible, permite reanudar con seguridad y no obliga al equipo a adivinar si el timeout cambió datos.