Recurring 494 REQUEST_HEADER_TOO_LARGE across all routes, including clean browser profiles

Hello,

Our production project repeatedly returns 494 REQUEST_HEADER_TOO_LARGE before the application runtime is reached.

Project: volcano-manager Project ID: prj_LbfOQFkgxEEfIEenGCOJLQAantVr Production domain: https://volcano-manager.vercel.app Latest production deployment: volcano-manager-kq5ieppqy-volcanoindustrys-projects.vercel.app Region shown by the error: fra1

The issue affects all routes, including /login and /dashboard, and occurs intermittently but very frequently.

Tests already performed:

Deleted all site cookies and data after closing every application tab.
Tested normal and incognito browsing.
Tested with a completely new Chrome user-data directory.
Tested with extensions disabled.
Tested with HTTP/2 and QUIC disabled.
Reproduced on desktop and mobile devices.
Plain curl requests without an existing browser session reach the application successfully.
No corresponding 494 entry appears in the application runtime logs, suggesting the request is rejected by the Vercel routing layer before middleware/runtime execution.

Application-side mitigations already deployed:

Removed a large shopping-list payload previously stored in Supabase user_metadata.
Prevented middleware from rewriting authentication cookies.
Added detection and cleanup for abnormally large authentication sessions.
Restricted temporary OAuth cookie paths.
Verified build and all 46 automated tests.

We also temporarily renamed the project and assigned the same production deployment to a new vercel.app alias. The new hostname did not return 494, although it was inaccessible without Vercel Authentication because of the project’s deployment-protection configuration. We reverted the rename and removed the temporary alias.

Could this hostname have stale platform-level routing, cookie, or header state? Is there any Vercel-side metadata or edge configuration that can be cleared or reset for volcano-manager.vercel.app?

This is severely affecting normal use of the production application. Any assistance investigating the request at the routing layer would be greatly appreciated.

Hi Volcanoindustry,

The new alias test is a useful clue: a different hostname would not receive the same browser cookies as volcano-manager.vercel.app, so I’d still treat this as a request-header/cookie-size issue before assuming stale Vercel routing state.

Vercel documents this error as being triggered when an individual request header is over 16 KB or total request headers are over 32 KB, and cookies count toward that total.

One way to separate it:

curl -I https://volcano-manager.vercel.app/login
curl -I https://volcano-manager.vercel.app/login \
  -H 'Cookie: paste-redacted-cookie-header-here'

If the first request works but the second one returns 494, the app is still generating a cookie/header set that is too large, even if cleanup logic exists. I’d check the failing request in DevTools Network and compare the total Cookie header size, especially auth/session cookies, Supabase auth cookies, OAuth temp cookies, and any duplicated/stale cookie names with different Path or Domain attributes.

Also, because this happens before middleware/runtime logs, middleware cleanup may not get a chance to run on the oversized request. In that case, the durable fix is usually to reduce what gets stored in the session/JWT/cookies and expire the old cookie names/paths with small Set-Cookie deletion headers from a route that the browser can still reach.

Can you share the failing request’s redacted Cookie header names and approximate sizes, without values?