Un 504 significa que una passarel·la o proxy ha esperat massa la resposta del servei posterior. Si només falla una acció administrativa, probablement la petició fa més feina de la que permet el termini del proxy: una importació, edició massiva, còpia, crida a una API o una operació lenta de base de dades.
No premis el botó repetidament. La primera petició pot continuar després que el navegador mostri 504 i generar importacions, missatges o canvis duplicats.
Conserva les dades exactes de l’acció
Anota URL administrativa, botó o acció, hora d’inici i fallada, registres seleccionats, rol i qualsevol identificador de feina. Comprova si el resultat previst apareix uns minuts després.
Relaciona:
hora i ID del 504 del proxy
durada upstream del servidor web
procés o registre PHP
consulta o bloqueig MySQL
registre del connector o tasca en segon plaNo incloguis dades personals ni nonces en proves compartides.
Identifica la capa que exhaureix el temps
Cloudflare, el balancejador, Nginx o Apache, PHP i les API externes tenen terminis diferents. Revisa capçaleres i registres per descobrir quina capa ha generat el 504.
Augmentar max_execution_time de PHP no ajuda si el proxy deixa d’esperar abans. Igualment, ampliar el termini del proxy només amaga una tasca ineficient.
Utilitza ajustos compatibles amb l’allotjament i documenta els valors efectius al web i a CLI.
Comprova si la feina continua
Abans de reintentar, revisa processos PHP actius, tasques programades i estat del connector. Algunes eines posen la feina en cua i el navegador només espera una confirmació; altres ho fan tot de manera síncrona.
Si la petició original continua en curs, deixa-la acabar o atura-la mitjançant controls autoritzats després d’avaluar el risc d’escriptures parcials.
Dues tasques massives simultànies es poden bloquejar entre elles i empitjorar el timeout.
Audita els resultats parcials
Compara el conjunt previst amb el que realment ha canviat. Per a una importació, utilitza identificadors estables; per a una edició massiva, dates de modificació i el camp objectiu; per a correu, identificadors del proveïdor.
No prenguis l’última pantalla visible com a punt de control: el servidor pot processar més elements després que el proxy es desconnecti. Crea una llista acotada d’excepcions i decideix si cadascuna necessita reprendre, revertir o cap acció.
Rastreja esperes MySQL
Consulta proves de consultes lentes i bloquejos durant aquella finestra. Una actualització massiva pot recórrer metadades sense índex o esperar darrere d’una transacció de còpia o importació.
Executa EXPLAIN sobre una consulta equivalent i anonimitzada en staging. No matis fils MySQL ni afegeixis índexs sense entendre les transaccions actives i el cost d’escriptura.
Fes commits en lots acotats per alliberar bloquejos regularment.
Examina dependències remotes
Llicències, descàrrega d’imatges, CRM, DNS i API poden esperar sense un límit raonable. Relaciona identificadors del proveïdor i errors cURL del servidor.
Les crides HTTP pròpies han de fixar temps de connexió i resposta, i tractar amb seguretat un resultat desconegut. No reintentis a cegues operacions externes no idempotents.
Passa la feina remota no essencial a una cua i mostra el progrés a l’administrador.
Converteix la feina síncrona en lots
Importacions, substitucions i regeneració de mitjans haurien de processar un nombre conegut per petició o executar-se mitjançant WP-CLI o tasques del servidor.
Disseny segur de lots:
identificadors estables
punt de control després de cada lot
reintent idempotent
llista d'errors visible
reprendre sense començar de nouNo desis tot el conjunt en una sola opció de WordPress ni en un únic array de PHP.
Ajusta límits només quan estigui justificat
Si la feina mesurada és eficient però supera legítimament un termini curt, executa-la per CLI o en segon pla. Augmentar el timeout del web públic reté processos i facilita una denegació de servei.
Calcula workers PHP, memòria i capacitat de base de dades per a tasques concurrents. Programa l’administració pesada fora d’hores punta.
Conserva una còpia independent abans d’una mutació massiva.
Verifica finalització i reversió
Repeteix un lot petit i controlat i confirma que respon abans de tots els terminis rellevants. Revisa recomptes, registres i resultats parcials d’intents anteriors.
Prova pàgines públiques i administratives mentre s’executa la feina. El manteniment recurrent ha de vigilar peticions administratives llargues i tasques fallides; un flux reparat acaba de manera previsible, permet reprendre amb seguretat i no obliga l’equip a endevinar si el timeout ha canviat dades.