WordPress error 431: reduce headers and regain access

Recognize a rejection caused by request headers

WordPress displays “431 Request Header Fields Too Large,” sometimes only in your usual browser. The server is rejecting request headers that are too large, either collectively or in a particular field. This information accompanies the request: cookies, authentication, or data added by an intermediary. The size of an uploaded image is a different matter.

The goal is working access with headers of a controlled size, followed by removal of whatever makes them grow. Clearing cookies can unblock a session; it does not automatically fix the component accumulating them. This guide therefore starts by comparing requests and sessions before considering server configuration.

The initial checks require neither a plugin nor hosting access. To fix a WordPress component, arrange a copy and an authorized account. Server limits require administrative access to the service. On WordPress.com or a managed plan, that setting belongs to the provider. In multisite, cookies may cover several subsites: check their scope before deleting them.

Preserve your work and understand the effects of clearing data

Before deleting cookies, save your drafts and finish any ongoing operations that can be completed without reproducing the rejection. Keep a private record of your cart, preferences, or useful selection. Session information may disappear after clearing data; copying a URL does not necessarily let you recover it.

Make sure you know how to log back in and have the second factor available if the account uses one. Do not save authentication cookie values in a shared document to try to restore the session later. Those values may grant access to the account. The expected recovery after clearing data is to create a normal session through the site’s login.

For component and server configuration tests, keep an appropriate backup and record the initial state. Work on a copy with outbound messages and commercial effects disabled. A read-only visit is enough for the initial diagnosis: you do not need to repeat a payment, deletion, or import to reproduce a header error.

Identify the request actually receiving status 431

In Chrome’s developer tools, open Network before a simple visit that fails. Enable Preserve log if a redirect follows, and keep the All filter so that both documents and Fetch/XHR calls remain visible. The rejected row may be a background request even though the main address looks short. Record its time and screen name without sharing authentication values.

The status sets the scope of the diagnosis. Code 414 concerns an address that is too long; code 413 concerns the submitted body. Some servers also use 400 for an oversized field: the exact message and logs can then confirm the limit. The word cookie appearing on a page is not enough to draw a conclusion.

1. Select the row receiving 431 and open Headers.
2. Record the address, method, and status of that specific request.
3. Look at the Request Headers names, especially Cookie, without copying their values into a public ticket.
4. Note whether the rejection follows an initial successful response or appears on the very first request.

Compare a fresh session before changing your usual session

Open the same public page in a fresh browser profile or an Incognito window that does not already have the site’s cookies. First close any other Incognito windows containing a session for the same site: windows in an Incognito session may share its cookies. Keep the same domain name and path. This check leaves your usual session intact and helps examine the role of its local history.

Success in this window points toward session data, without proving the cause conclusively. Browser extensions, third-party cookies, and login rules can also differ. If the problem affects only administration, a successful public page does not yet validate the authenticated request. Log back in only if the process is normal and authorized, then compare the same screen without a sensitive operation.

If a fresh session immediately receives the same 431, do not clear all data on your computer. Examine other headers and intermediaries. If it works and then fails after a specific sequence of visits, record that sequence and the approximate number of steps. You now have a scenario for finding the data generator, which is more useful than repeatedly clearing data without observation.

Remove an identified cookie instead of all data

This first fix is appropriate when a clearly identified preference or history cookie takes up excessive space. In Chrome, Application, Storage, Cookies shows each origin’s name, domain, path, and size. The domain and path explain which requests the cookie may accompany. The Size column indicates its size, but does not measure all of the request’s headers by itself.

Do not randomly delete a login cookie or a value whose role is unknown. Selective deletion does not guarantee that the preference can be recovered; plan to recreate it through the normal interface. If you cannot confidently identify a candidate, move on to clearing data for just the site after preserving your work. If the rejection page prevents DevTools from showing cookies for the relevant origin, use the single-site settings described in the next section; do not try to bypass the rejection by fabricating an authenticated request.

1. Open Application, then Storage, Cookies, and the relevant origin.
2. Examine names and sizes; keep values private.
3. Select only the identified cookie, then choose Delete selected.
4. Reload a simple read-only page and check whether the 431 disappears.
5. Recreate the useful preference through the site, then check that it does not immediately bring the rejection back.

Reset data for just the site if selective removal is impossible

If the fresh session works but no specific cookie can be identified, a reset limited to the site may restore access. Do this after saving your work and checking how you will log in again. It may log the account out and remove preferences or cart state; there is no general button for restoring this local data exactly as it was.

In desktop Chrome, use the procedure below. Check the domain you searched for before confirming. Data shared at a parent-domain level may affect several subdomains. Do not extend the cleanup to every site in the browser to address a single WordPress installation.

1. Open Chrome’s menu, then Settings.
2. Go to Privacy and security, then Third-party cookies.
3. Choose See all site data and permissions, and search for the relevant domain.
4. To the right of the exact entry, choose Delete, then confirm Delete after checking the scope displayed.
5. Reopen the site, log in normally if necessary, and check the same request.
6. If the error returns after a few actions, record that sequence and continue investigating the cookie cause.

Find out why cookies start growing again

A cleared session that fails again after several visits calls for a fix to the generator. On the copy, observe the sequence that creates new entries or lengthens a value. This may be a history, a list of preferences, or an identifier created for every interaction. Do not infer its owner solely from the beginning of its name; compare it with the component’s documented behavior.

Scope matters as much as count. Cookies may be sent to several subdomains when their domain allows it, or to many paths. A subsite may therefore be affected by data created elsewhere under the same domain. Cookies relevant to an administration path may also differ from those for a simple public page.

Keep names, domains, paths, and changes in size in a private record. A fix may reduce the volume stored or narrow its scope, but it must be made by the component that understands this information. Do not rewrite every value in the browser to simulate a repair. The expected result is a normal workflow that stops accumulating data without limits.

Compare the component on a copy with an optional plugin

Without a new tool, open Plugins, Installed Plugins on the copy and deactivate only the suspect. Follow the same sequence with a fresh test session, then reactivate it to confirm the comparison. Existing cookies may continue to be sent after deactivation: their continued presence does not prove that the deactivated component is still running.

Troubleshooting, by Marius L. J., can help compare component loading within your session. The recorded version is 1.0.2, requiring at least WordPress 5.8 and PHP 7.1, tested up to WordPress 7.1.4; these are not recommendations to use old versions. It does not create a separate database or raise a server limit. It cannot affect a request rejected before PHP: first regain access with a usable session. Must Use plugins remain loaded, and a cache may distort the comparison.

1. If the help is needed and compatible, install the official component from Plugins, Add New Plugin.
2. Open Tools, Site Health, Troubleshooting, then Enable Troubleshooting Mode.
3. From the Dashboard widget or the troubleshooting menu in the admin bar, reactivate the necessary components one at a time and compare cookie creation along the reference workflow.
4. Finish with Disable Troubleshooting Mode in the widget or admin bar, then confirm the result on the copy in its normal context.

Examine other headers when an empty session fails

Cookie is not the only field that can become too large. Enterprise authentication, an integration token, or an intermediary may add substantial information. If a session with no history receives the same rejection, record the field names present and have the successful context compared with the failing one.

Distinguish headers sent by the browser from those added later by a proxy. The browser does not necessarily show every transformation on the way to the origin. Repetition may also be introduced between two services without appearing as several cookies in Application. The person responsible must compare both sides of the route to confirm this mechanism.

Do not manually shorten an Authorization token or remove a control header to obtain a response. The request might then use a different identity or lose a necessary protection. If a component generates an excessive token, fix its documented mechanism. If a chain of intermediaries duplicates fields, fix that chain while preserving its initial state. Increasing a limit only delays growth that continues.

Identify the layer actually enforcing the limit

Before changing the server, have the domain, time, and request correlated with CDN, proxy, and origin logs. A page bearing a server logo does not establish which service rejected the headers by itself. The address may pass through several layers with different limits.

If the rejection is recorded at the first proxy and the origin never receives the request, changing PHP or the final server will have no effect on that rejection. If the origin receives fields enriched by the proxy, their size must be measured there. Avoid a test that bypasses protection by publicly exposing the origin’s direct address.

The configuration approach is appropriate for a legitimate request whose headers are bounded and necessary. Keep the active file, the initial value, and any mechanism that generates this configuration. Change only one layer at a time. On managed hosting, the administrator must use the durable setting provided by its panel instead of a file copy that will be overwritten.

Adjust Apache for an identified legitimate field

This approach requires administrative access to Apache, confirmed as the blocking layer. LimitRequestFieldSize limits the size of a request field; the documented standard value is 8,190 bytes. It is set in server or virtual host configuration, never in .htaccess. With name-based hosting, the value from the first host matching the address and port may apply.

The 16,384-byte example is illustrative. It does not fix cookie proliferation or replace diagnosis of a limit on the total size or number of fields. The file must be the one actually loaded by the service.

1. Keep the active configuration and the initial value for the identified field.
2. Change only the effective definition, using a value proportionate to the confirmed need.
3. Check with apachectl configtest, using the binary, paths, and permissions of the instance actually in operation. The expected result is Syntax OK; if it fails, fix or restore the file without reloading.
4. After success, apply the change using the operational procedure; a standard installation may use apachectl graceful.
5. If the test is unhelpful or harmful, restore the value, check it, then apply the rollback.

LimitRequestFieldSize 16384

Adjust Nginx for both individual fields and the total

With Nginx confirmed as responsible, large_client_header_buffers defines buffers for client headers. The documentation specifies 4 8k by default. A field must fit in one buffer; increasing only their number does not solve an oversized individual field. This layer may reject the request with status 400 even if another layer uses 431.

The directive belongs in the http or server contexts, with a possible influence from the default server. The size example below does not belong in location, PHP, or .htaccess. It still needs to be sized according to measurements and permitted resources. These checks do not require publishing the full configuration: avoid attaching nginx -T output, which reveals it, to a public ticket.

1. Keep the configuration and identify the definition actually applied.
2. Adjust the size for an oversized field, or the sizing for the total, according to the diagnosis.
3. Check with nginx -t, using the same configuration and prefix parameters as the service. Wait for a successful check; if it fails because of syntax or an inaccessible file, do not reload.
4. After success, reload according to the operational procedure; a standard installation may use nginx -s reload.
5. If it fails or provides no improvement, restore the old definition, then check and reload the rollback.

large_client_header_buffers 4 16k;

Validate the complete workflow after the fix

Repeat the exact request that was rejected, with a normal session. Check its status and then the expected function: an error page returned with status 200 does not count as success. If administration was affected, open that screen with the same account after logging back in. A cached public page does not validate the authenticated route.

If cookies were deleted, repeat the steps that caused them to accumulate. Observe their count and sizes after several representative interactions, without triggering a real commercial operation. An immediate return of the rejection indicates that clearing data merely reset the counter. Find the responsible component instead of repeating the deletion.

If a server limit was adjusted, check that layer’s logs and a neighboring function. Document the chosen value and remove temporary changes that did not contribute to the result. Rolling back a configuration means restoring its initial definition, then checking and reloading it. It does not restore deleted local preferences. Keep those two operations separate in the intervention record.

Prevent accumulation and provide usable evidence

Record the component creating each useful cookie family, its scope, and the workflow that was checked. When an update adds history, personalization, or an integration, check that the volume remains bounded. One cookie per interaction can become a problem over time even if a fresh visit looks normal.

For a ticket, provide the exact status, domain, path, time with time zone, and session type. Add the names of the affected fields and redacted measurements, not their secrets. State whether a fresh session succeeds, whether clearing data for just the site changes the result, and after which actions the problem returns. A full header screenshot or diagnostic file may contain login information; prepare a version limited to the necessary evidence.

For the host, specify the confirmed layer and the limit reached, with the initial and attempted settings. For a component, provide the growth scenario on the copy and its version. A lasting repair combines restored access with a volume that stays controlled. It does not rely on a habit of clearing all browser data whenever the site rejects the session.

Keep a growth record containing no secrets

Create a small sheet with five columns: workflow step, cookie name, domain, path, and displayed size. Cookie values must never appear in it. Take three readings on the copy: a fresh session, after one visit, and after five equivalent visits.

Fictional teaching example: historique_vues, domain boutique.example.test, path /, grows from 120 to 900 and then 3,900 bytes. The language cookie remains at 5 bytes. This contrast points toward history rather than language; these numbers are neither a server threshold nor a real measurement of your site. The same name on two different paths deserves two separate rows.

After fixing the component, repeat the same number of visits in a new session. The size may vary normally, but it must follow the stated retention mechanism. Also check that the useful preference or history still works. A value becoming empty is not success if the function has disappeared. If cookies remain small while the rejection returns, give this record to the proxy administrator to examine other fields. This method works with the browser’s free tools; it does not require a WordPress plugin able to read every secret in the session.