Cuando navegamos tranquilos y de repente, el sitio devuelve un mensaje que no entendemos, es normal frustrarse. El error 431 (“Request Header Fields Too Large”) es uno de esos avisos raros que descolocan, la web funcionaba, refrescamos y de pronto nada. Pero no cunda el pánico. Este error tiene una explicación clara y mejor aún, soluciones concretas que podemos aplicar paso a paso.
En términos simples, el error 431 aparece cuando el navegador envía una solicitud con cabeceras o headers WordPress demasiado grandes y el servidor decide rechazarla. ¿De dónde salen esas cabeceras? De varios sitios que vamos a ver dentro de esta guía. Sin embargo, podemos decir que es un cúmulo de tipos de errores HTTP que, con el tiempo, todo se acumula hasta que la solicitud supera el límite permitido.
En esta guía vamos a recorrer, con calma y en orden, las causas más comunes y las correcciones que de verdad funcionan, desde la limpieza del navegador (lo inmediato y fácil) hasta las medidas en el sitio o el servidor (lo estructural, para que no vuelva a pasar). También veremos pistas para detectar si el origen está en un plugins WordPress, en un tag de analítica, en una política de cookies demasiado agresiva o en una URL que guarda demasiada historia.
La idea es que, al terminar, tengamos claro qué está pasando, cómo solucionarlo ahora y qué hacer para que no se repita. Vamos paso a paso. ¡Vamos a ello!
Tabla de contenidos
¿Qué es el error 431?
Cuando aparece el error 431, el servidor nos está diciendo, en pocas palabras, que las cabeceras de la solicitud son demasiado grandes. Dentro del protocolo HTTP, este código pertenece a la familia 4xx (errores del lado del cliente) y su nombre completo es Request Header Fields Too Large. No significa que hicimos algo mal, sino que la petición que se envía desde el navegador llega con información en las cabeceras que supera el límite que el servidor está dispuesto a aceptar.
Aquí conviene recordar algo, cada solicitud HTTP viaja con un sobre (las cabeceras) que incluye datos como el agente de usuario, el idioma, la política de cache, el host, entre otros. Ese sobre es independiente del contenido (el cuerpo o payload).
El error 431 se dispara cuando el problema está en el sobre, no en el contenido. Por eso no hay que confundirlo con un 400 Bad Request (genérico) o con un 413 Payload Too Large (cuando lo que excede el límite es el cuerpo de la petición, no las cabeceras).
¿Cómo lo vemos en la práctica? La página no carga y el navegador muestra el código 431, si abrimos las herramientas de desarrollador (pestaña Network), veremos la respuesta con ese estado y el texto Request Header Fields Too Large. En registros del servidor, suele aparecer el mismo mensaje.
Motivos del error HTTP 431
Cuando nos topamos con el error 431, el mensaje de fondo es claro: lo que viaja en las cabeceras de la petición pesa más de la cuenta. No es un único culpable, suele ser la suma de varias piezas que, juntas, inflan ese sobre de información. Para entenderlo bien, separemos los orígenes más habituales.
Cookies sobredimensionadas (o demasiadas cookies)
Las cookies WordPress son, con diferencia, el origen más común. Acumular varias cookies de Analytics, A/B testing, banners de consentimiento, preferencias de idioma/moneda, carrito, sesiones o, una sola cookie enorme (por ejemplo, con un token JWT muy largo) dispara el tamaño total de la cabecera Cookie. Si además trabajamos con subdominios o rutas distintas, es fácil que el navegador envíe más cookies de las necesarias en cada petición.
URLs excesivamente largas y cabeceras derivadas
Las URLs repletas de parámetros (UTM, filtros, estados de app, IDs) no solo complican la navegación, sino que también inflan la cabecera relacionada, como Referer, en peticiones posteriores (cargas de recursos, llamadas internas, etc.). En algunos casos, la combinación de ruta y parámetros también entra en los límites que protegen al servidor y acaba provocando el 431.
Encabezados personalizados y tokens pesados
Aplicaciones y APIs suelen añadir headers propios (Authorization con tokens extensos, X-Request-*, correlación de trazas, etc.). Cuando anidamos varios sistemas en el navegador, backend WordPress, pasarela, microservicios, esos headers se acumulan y pueden superar los límites aceptados por el servidor o el proxy.
Plugins, scripts de marketing y gestores de consentimiento
Ciertas integraciones de terceros añaden cookies y headers para segmentar. Si a esto le sumamos un gestor de consentimientos mal configurado (que crea varias cookies para cada estado) o reglas duplicadas, la petición termina viajando con un lastre innecesario.
Redirecciones, dominios y ámbitos de cookies
Los bucles de redirección entre www/no-www, HTTP/HTTPS o dominios y subdominios pueden generar copias de cookies con distintos alcances (path/domain). Teniendo como resultado que el navegador envíe más cookies de las que el sitio necesita, elevando el tamaño de las cabeceras en cada salto.
Límites en la infraestructura (servidor, proxy, CDN, WAF)
Cada capa, ya sea Apache/Nginx, proxies, CDN, WAF imponen límites de tamaño para cabeceras (globales o por campo). Si alguno de esos límites está más bajo de lo habitual, una petición válida para la app puede ser rechazada. También hay servicios que añaden sus propios headers (trazabilidad, seguridad), sumando bytes a la cuenta final.
SPA/AJAX y CORS con listas de headers largas
En aplicaciones SPA, las peticiones preflight (CORS) incluyen Access-Control-Request-Headers con la lista de cabeceras que se desean enviar. Si esa lista crece (por librerías o middlewares), el simple preflight puede cruzar el umbral y devolver un 431.
Navegador y extensiones
A veces el problema está de nuestro lado, extensiones de privacidad, depuración o automatización que añaden headers, perfiles de navegador con almacenes de cookies corruptos o perfiles que arrastran cookies antiguas que ya no tienen sentido para el sitio actual.
¿Cómo solucionar el error 431?
Cuando nos topamos con el error 431 (Request Header Fields Too Large), la clave es actuar en dos niveles. Primero, un ataque rápido desde el navegador para volver a entrar al sitio sin romper nada. Después, ajustes en el proyecto para que el problema no regrese.
Nuestro objetivo será, entonces, aligerar lo que viaja en cada petición. Si además gestionamos servidor o CDN, podremos afinar límites de cabeceras, pero eso siempre será el último paso, cuando ya hayamos reducido el tamaño real de lo que enviamos.
Vamos punto por punto, con un paso a paso claro para cada caso.
Cuando vamos a borrar ala cache de nuestro sitio es por qué el problema se escaló, o no depende de nuestro sitio, en este caso lo primero que tendremos que hacer es probar en modo incógnito o en otro navegador. Si el sitio abre, es casi seguro que el problema está en cookies/caché locales.
Entonces para solucionar este inconveniente tendremos que eliminar solo las cookies del dominio afectado, para ello ingresamos en la siguiente secuencia:
Abrimos ajustes > Privacidad > Cookies y datos del sitio > Buscamos el dominio > Eliminar.
De esta forma vaciamos caché del navegador (archivos temporales), mantener contraseñas si lo deseamos, de la misma forma podemos desactivar extensiones de bloqueo, depuración o automatización (añaden headers) para intentar de nuevo.
Recordemos el actualizar forzoso de nuestros exploradores (Ctrl/Cmd + Shift + R) y volver a intentar acceder. Si así funciona, ya tenemos pista el peso viene, sobre todo, de Cookie y/o Referer.
Ajustar los parámetros de consulta de URL
Muchas veces llegamos a la página desde un enlace con UTM u otros parámetros encadenados. Esa URL enorme puede inflar cabeceras relacionadas y disparar el 431. La prueba es simple, entramos al mismo recurso con una ruta limpia, sin nada después del ?. En la práctica es tan fácil como copiar la parte principal de la URL y pegarla sin los parámetros.
Si funciona con la ruta limpia, confirmamos que el problema está en la longitud de la URL y lo que arrastra (por ejemplo, el Referer en peticiones posteriores). Esto no corrige el origen, pero nos devuelve el acceso y nos da una señal clara de por dónde seguir.
Modificar el código de tu sitio web
Aquí vamos a la raíz. Si el navegador volvió a cargar tras limpiar cookies o acortar la URL, toca aligerar lo que enviamos desde el propio sitio.
Empecemos por las cookies. Revisamos cuántas emitimos, para qué sirven y cuánto ocupan. Si guardamos objetos grandes (JSON, tokens eternos o múltiples preferencias en una sola cookie), los acortamos. Mejor un ID corto que represente el estado, y el resto lo resolvemos en servidor. También ajustamos domain y path para que el navegador no envíe cookies en subdominios o rutas donde no hacen falta.
Si usamos un gestor de consentimiento, simplificamos categorías y reglas duplicadas para evitar que genere más cookies de las necesarias. Luego, miramos headers personalizados. Si enviamos Authorization con cadenas o cabeceras de trazabilidad en cada petición, reducimos el tamaño o cambiamos la estrategia.
Por último, verificamos scripts y etiquetas de marketing. Desactivamos, probamos y reactivamos de forma selectiva. Es frecuente que un tag de pruebas A/B o una integración mal configurada sea el que engorda cookies y cabeceras sin que nos demos cuenta.
Acortar o eliminar los parámetros de consulta de la URL
Si el arreglo rápido con rutas limpias funcionó, nos toca normalizar los enlaces para que el problema no vuelva. Empezamos por los menús, botones y plantillas del tema, dejamos solo los parámetros imprescindibles y movemos cualquier estado voluminoso a sesión o base de datos.
Para campañas, registramos las UTM al primer acceso y luego redirigimos a la URL canónica (sin parámetros), de modo que la navegación interna viaje ligera. En buscadores y listados con filtros, imponemos límites, nada de cadenas infinitas con paginaciones, colores, tallas y ordenaciones concatenadas sin control.
Si necesitamos conservar filtros, usamos identificadores breves o guardamos la selección del usuario en servidor. Y, si nuestro CMS genera enlaces con parámetros por defecto, ajustamos la plantilla para que los limpie tras resolver la vista.
Con estas cuatro acciones el limpiar el navegador, probar con URL corta, recortar cookies/headers en el sitio y normalizar URLs, atacamos el error 431 por donde duele, recuperamos el acceso y dejamos la casa ordenada para que no vuelva a aparecer.
Conclusiones
Si algo nos deja claro el error 431 es que, muchas veces, los problemas de acceso no tienen que ver con fallos misteriosos, sino con peticiones que viajan demasiado cargadas. Lo bueno, tiene solución, y no requiere romper nada. Empezamos por lo inmediato borrar cookies y caché, probar en incógnito, limpiar URLs con parámetros eternos para recuperar el acceso cuanto antes.
De esta forma, una vez dentro, vamos a lo importante, recortar cookies, ajustar su domain/path, evitar headers personalizados, desmesurados y normalizar enlaces para que la navegación interna no arrastre peso innecesario.
Si gestionamos servidor o CDN, siempre dejamos para el final el ajuste de límites de cabeceras (Apache/Nginx/Proxy). Subir umbrales sin reducir primero el tamaño real es solo patear el problema hacia adelante.
Con este enfoque primero alivio rápido, luego corrección de fondo y, por último, prevención, el error 431 deja de ser un dolor de cabeza y se convierte en una oportunidad para ordenar, aligerar y acelerar nuestro sitio. Y si nos atascamos en algún paso, mejor revisar en staging, medir con las herramientas de red del navegador y avanzar con calma.
¿Te ha resultado útil este artículo?
Equipo de soporte WordPress y WooCommerce en Webempresa.
