Diagnosing Cloudflare 522 and 524 Timeout Errors with Next.js on Vercel

When a Next.js application deployed on Vercel is served through a Cloudflare proxy, the connection between Cloudflare and the Vercel origin can fail with HTTP 522 or 524. These errors come from Cloudflare, not from Next.js directly, but they often indicate differences in timeout behavior between the proxy and the serverless function execution environment.

Important distinction

522 (Connection Timed Out): Cloudflare could not establish a TCP connection to the origin within the timeout window. The origin may be unreachable, or the connection was refused.
524 (A Timeout Occurred): Cloudflare successfully connected to the origin, but the origin did not return an HTTP response before Cloudflare's proxy read timeout (default 100 seconds for free/pro; 125 seconds documented by official Cloudflare docs).

These are different failure modes with different root causes. Treating them as the same problem leads to incorrect fixes.

Per official Cloudflare documentation (developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/):

522: timeout before TCP handshake completes or before the origin acknowledges the connection.
524: timeout after successful TCP connection; origin did not respond with complete HTTP response.

Problem

A Next.js application works correctly when accessed directly through its Vercel deployment URL. When accessed through a domain using Cloudflare proxy, requests fail with 522 or 524. The symptoms vary depending on which layer fails first.

Common symptoms:

522 appears immediately; no HTTP response headers from the application.
524 appears after a delay; the browser waits, then receives a Cloudflare error page.
The error occurs only on certain routes (e.g., server-rendered pages or API endpoints) but not on static assets.
The Vercel function log shows either no execution (522) or a timeout message (524).

First diagnosis

Before changing any configuration, confirm which error appears and where the failure occurs:

Open the browser's developer tools and inspect the failing request. Confirm the exact HTTP status (522 vs 524) and the response headers (CF-RAY, Server: cloudflare).
Compare the failing URL with the direct Vercel URL. If the direct URL works but the Cloudflare URL fails, the issue is between Cloudflare and Vercel, not the application itself.
Check Vercel function logs for the deployment. Confirm whether the function executed, timed out, or was never called.

This order prevents fixing the wrong layer. Changing application code before confirming the error type is a common mistake.

Environment considerations

The interaction between Cloudflare proxy and Vercel serverless functions depends on plan settings:

Cloudflare proxy timeout defaults vary by plan (free/pro/business). The official documentation confirms the default proxy read timeout is 100–125 seconds.
Vercel serverless function execution time limits depend on the Vercel plan (hobby/pro/business/enterprise).
A serverless function that runs near the Vercel timeout limit may trigger a 524 (Cloudflare connected successfully but did not receive a response in time) even though the function eventually completes.

These are separate settings in separate systems. Changing only the Cloudflare timeout without checking the serverless execution time does not resolve the root cause.

Common causes

The serverless function execution exceeds the Cloudflare proxy timeout. (Verified by comparing Vercel execution time with Cloudflare timeout settings.)
The origin server (Vercel) is unreachable due to environment or deployment configuration differences between production and preview deployments. (Inferred from deployment behavior; verified by checking Vercel logs and deployment status.)
A database or external API call within the serverless function exceeds the available time, causing the function to time out before responding. (Common community-reported pattern; must be confirmed by Vercel logs showing timeout errors.)
The application responds correctly for static pages but fails for server-side rendered routes that invoke slower logic. (Verified by comparing failing routes in browser inspection.)

Troubleshooting steps

Confirm exact error code (522 vs 524) in browser response and Cloudflare response headers.
Confirm the same URL works when accessed directly via the Vercel deployment URL (without Cloudflare proxy). If it fails there too, the issue is in the application or deployment — see database-connection-production or nextjs-build-fails-example for related production-only failures.
Inspect Vercel function logs for the failing deployment. Confirm whether the function executed and how long it ran.
If 524: compare the function execution time with the Cloudflare proxy timeout. If the function takes longer than the proxy allows, the root cause is execution time — not connection.
If 522: confirm the Vercel deployment is active and the function is accessible. A 522 often indicates the origin was unreachable at the time of the request.
Confirm the failing route requires server-side execution. Static assets typically do not trigger 524 because they respond quickly.

Verification

After any configuration change (Cloudflare timeout settings, serverless optimization, or deployment redeployment):

Clear browser cache for the affected domain.
Retry the failing URL through the Cloudflare-proxied domain.
Confirm the exact status code has changed (from 522 to a working response, or from 524 to resolved) — not just that an error occurs differently.
Check Vercel function logs for the new deployment to confirm execution time and absence of timeout errors.
Verify both the failing route and a related static or simple route respond correctly.

Common mistakes

These patterns match verified deployment issues (official Cloudflare documentation, verified Vercel serverless behavior, and common reported symptoms — clearly distinguished):

Treating 522 and 524 as the same root cause. They indicate different failure points in the connection sequence. (Verified: official Cloudflare docs distinguish these explicitly.)
Changing only Cloudflare proxy timeout without confirming serverless execution time. This may mask the problem rather than resolve it. (Inferred from troubleshooting logic: verified by comparing timeout settings.)
Changing application code before confirming the error is a proxy-timeout issue rather than a build or database issue. See related articles for distinguishing these failure modes.
Not redeploying after environment changes. See deploy-nextjs-vercel-env for redeployment requirements.