admin-ajax.php de WordPress retorna 400 Bad Request: guia pràctica de diagnòstic

Què importa primer: WordPress ha rebut la sol· licitud AJAX però no ha pogut processar- la com una acció vàlida. La càrrega útil de la sol· licitud generalment revela si l’acció nonce o els falten els camps esperats.

Què indica realment aquest símptoma

Admin- ajax.php ofereix moltes accions no relacionades, per la qual cosa un error 400 en un no significa que AJAX estigui trencat de forma global. El nom de l’acció, càrrega útil i resposta que falla permeten distingir el codi del plugin dels problemes de memòria cau, seguretat o mida de la petició.

Recull proves abans de canviar res

• Captura la càrrega útil de la petició i Localitza el paràmetre d’acció.
• Compara el comportament d’accés i de sortida perquè utilitzen diferents ganxos.
• Llegeix el cos de la resposta i qualsevol entrada del registre de PHP en la mateixa data i hora.
• Comprova si una memòria cau, un WAF o una capa d’openció va alterar el cos de la petició POST o nonce.

Causes més habituals

• Ganxo d’acció absent: El plugin ha enviat una acció que no està registrada per a l’estat d’autenticació actual.
• Nonce caducat: Un administrador a la memòria cau o una pàgina frontal pot enviar un token de WordPress que ja no accepta.
• Carrega útil mal formada: JavaScript pot ometre camps requerits o enviar JSON on s’ esperen dades de formulari.
• Filtrat de seguretat: Un WAF pot eliminar o rebutjar camps que semblen codi, URLs o SQL.

Seqüència segura de diagnòstic i reparació

1. Reprodueix amb la memòria cau i l’optimització de l’script bypassed per a la vostra pròpia sessió.
2. Confirma que els ganxos PHP existeixen per a wp _ ajax _ i, quan sigui necessari, wp _ ajax _ nopriv _.
3. Regenera l’nonce d’una pàgina sense caixejar i comprova que la petició l’envia sota el nom de camp esperat.
4. Ajusta només la provada WAF o regla de sol· licitud, a continuació, torna a provar la característica exacta.

Com distingir entre les causes probables

No tractis Ganxo d ‘ acció absent i Nonce caducat com a causes equivalents. El plugin ha enviat una acció que no està registrada per a l’estat d’autenticació actual. En canvi, un administrador a la memòria cau o una pàgina frontal pot enviar un token de WordPress que ja no accepta. Per a distingir- les, useu aquestes dues comprovacions: Captura la càrrega útil de la petició i Localitza el paràmetre d’acció; i compara el comportament d’accés i de sortida perquè utilitzen diferents ganxos. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada —Reprodueix amb memòria caus i l’optimització de l’script bypassed per a la seva pròpia sessió— o si heu de conservar l’estat actual i ampliar la recerca.

En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.

Què no has de fer

No feu una llista blanca de totes les sol· licituds a admin- ajax.php. Aquest endpoint pot realitzar operacions privilegiades i ha de romandre protegit per la capacitat i les comprovacions nonce.

Com verificar la reparació

• L’acció original retorna la resposta prevista de l’plugin.
• L ‘ accés registrat i l ‘ accés registrat es comporten d ‘ acord amb el disseny de la característica.
• Les accions invàlides no relacionades amb AJAX continuen sent rebutjades.

Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.