How to Fix HTTP Error 431 in WordPress

The WordPress HTTP error 431 means a server refused the request because one header field, or the combined set of request headers, was too large. RFC 6585 defines the status as “431 Request Header Fields Too Large.” On WordPress sites, oversized cookies are the usual cause, although redirect loops, proxy-added headers, and browser extensions can produce the same result.

Why This Happens

Cookie data has grown too large

Browsers send every matching cookie with each request. A/B testing, membership, and e-commerce plugins may accumulate session or experiment data instead of rotating it. Third-party analytics can add more cookies, while stale wordpress_logged_in_* and authentication cookies may remain after their useful session has ended.

One large cookie can exceed a per-field limit. Many smaller cookies can exceed the web server's total header buffer even when each cookie is valid by itself.

A redirect or authentication loop appends state

A bad HTTP-to-HTTPS rule, inconsistent canonical host, or broken login callback can bounce the browser between endpoints. If each hop adds another cookie or grows a state value, the next request carries a larger Cookie header. The loop eventually ends as a 431 instead of an obvious redirect error.

A reverse proxy accumulates headers

A CDN, ingress, or load balancer normally adds forwarding information such as X-Forwarded-For. Incorrect proxy chaining can repeat an existing value or copy untrusted client headers instead of replacing them. Custom tracing and authentication headers can also grow across multiple hops.

Raising only the origin limit does not help if the edge rejects the request first. Conversely, a permissive edge can pass an oversized request that the origin still refuses.

A browser extension injects headers

Privacy, security, development, and corporate browser extensions can modify requests. This cause is less common than cookie bloat, but it becomes likely when the same URL works in a private window or another browser with a clean profile.

Diagnosing the Cause

Separate a browser-specific problem from a server-wide one before changing configuration.

Open the site in a private window, then try another browser or device. If that works, clear cookies for only the affected domain and temporarily disable extensions. A visitor should stop here; changing server limits is a site-owner task.
In the browser developer tools, select the failed request in the Network panel and inspect its request headers. Look for an unusually long Cookie value, repeated forwarding values, or a chain of redirects. Export sensitive headers only after removing session tokens.
Reproduce the request without browser cookies:
```
curl -I -L --max-redirs 10 https://example.com/
curl -I https://example.com/wp-login.php
```
If curl succeeds while the normal browser fails, client cookies or extensions are strong suspects. If -L reports too many redirects, correct the redirect chain before investigating buffer sizes.
Measure the cookie header from a saved, sanitized request rather than guessing:
```
awk 'BEGIN { IGNORECASE=1 } /^Cookie:/ { print length($0) " bytes" }' request-headers.txt
```
Then inspect the web server, ingress, load balancer, and CDN logs to identify which hop emitted the 431. PHP-FPM is not usually the enforcing layer because the proxy or web server parses request headers before PHP runs.
Review active WordPress plugins for code that creates sessions, experiments, carts, or authentication cookies:
```
wp plugin list --status=active
wp option get home
wp option get siteurl
```
The URL values help expose host or scheme mismatches behind redirect loops. Compare recent plugin changes with the cookie names in the failing request.

Fixing Each Cause

Clear domain cookies as a visitor

Remove cookies for the affected site, reload it, and sign in again. A private window is a useful confirmation but not a durable fix because the bloated profile will fail again. Disable extensions one at a time if clearing cookies does not isolate the problem. Trying another network rarely matters unless a corporate proxy modifies headers.

Stop cookie growth at its source

Site owners should map large cookie names to the plugin or script that owns them. Update or replace code that appends session state indefinitely, set appropriate expiration times, and keep server-side state on the server with a compact session identifier in the cookie. Do not place cart contents, authorization payloads, or growing analytics histories directly in cookies.

Invalidate stale WordPress login cookies by having affected users sign out and back in after correcting the underlying domain and HTTPS settings. Audit third-party tracking tags so only necessary cookies apply to the WordPress hostname and path.

Correct redirect and proxy behavior

Choose one canonical scheme and hostname, then make WordPress, the proxy, and TLS termination agree about them. A trusted proxy should sanitize incoming forwarding headers and append or replace values exactly once. Remove custom headers that duplicate data already available in logs or tracing systems.

When another network failure appears during this work, distinguish a header rejection from an origin that closed the connection early. They occur at different stages and require different evidence.

Raise web-server limits cautiously

After fixing unbounded growth, a modest limit increase can accommodate legitimate application headers. In nginx, place the directive in the http or relevant server context:

server {
    large_client_header_buffers 4 16k;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

The first value is the buffer count and the second is each buffer's size. Larger values consume more memory per connection and allow larger untrusted inputs, so treat this as a mitigation rather than the primary repair.

For Apache, use request-field directives in a supported server or virtual-host context:

LimitRequestFieldSize 16380
LimitRequestFields 100

LimitRequestFieldSize caps an individual header field; LimitRequestFields caps the number of fields. Confirm module and version behavior in the deployed Apache documentation before rollout. If a CDN or load balancer sits in front, align its supported limit with the origin. An edge with a lower fixed ceiling will continue rejecting the request regardless of origin settings.

Preventing It From Happening Again

Track total request-header size in controlled diagnostics, review new cookie-producing plugins, and test login, checkout, and experiment flows across repeated sessions. Add redirect-loop checks to deployment tests, and document header limits at every proxy hop instead of tuning only the final server.

Nova places a WAF and edge security layer in front of tenant sites on its managed WordPress hosting, while namespace-per-tenant isolation keeps workloads separated. If persistent 431 responses need deployment-specific review, contact the team.

FAQ

Is HTTP 431 a WordPress error?

No. It is an HTTP status defined by RFC 6585 and usually returned by a web server or proxy before WordPress executes. WordPress plugins often cause the oversized cookies that trigger it.

Will clearing cookies permanently fix error 431?

It fixes the affected browser profile immediately when cookie bloat is the cause. If a plugin keeps appending data, the error will return until the site owner corrects that behavior.

Should I increase PHP memory or PHP-FPM limits?

Usually not. nginx, Apache, a CDN, or a load balancer parses and limits request headers before PHP-FPM receives the request. Identify the rejecting hop first.

Can a CDN cause a 431 response?

Yes. A CDN may reject headers at its own limit or forward accumulated custom and forwarding headers to an origin with a lower limit. Both sides must be inspected, but unbounded header growth should still be fixed.