502 Bad Gateway on a Live Web App: Which Layer Failed?

A 502 Bad Gateway tells you where the request stopped, not what broke. One server could not get a usable answer from the next one. In the apps App Rescue Desk handles, that handoff is often Vercel to a Next.js route, a Lovable app to a Supabase Edge Function, or Railway’s proxy to a backend process.

This matters when the broken URL belongs to a checkout, login, API route or webhook. A 502 means a gateway or proxy did not receive a usable response from the server behind it, according to the HTTP definition documented by MDN. Your first job is to find the last service that handled the request successfully. Restarting every service usually hides more than it explains.

We checked the platform details and public cases below against vendor documentation or the original report on 2026-10-05. App Rescue Desk is independent of the platforms mentioned.

TL;DR

• A 502 means a gateway could not use the response from the service behind it. It does not tell you whether Nginx, the hosting platform or the app caused the problem.
• Before restarting or redeploying, save the exact URL and method, timestamp with timezone, response body, response headers, request ID and matching platform logs.
• Ask one question first: Did the request reach the application? If it appears in the app logs, inspect the app or its dependencies. If it does not, check routing and reachability before changing code.
• connection refused is more useful than the 502 page. It narrows the search to the address, port, running process or container route.
• If the affected flow handles payments, account access or customer data, preserve evidence and avoid repeated production experiments. Start with the production web app bug-fixing service when the failing layer is unclear.

Can you fix a 502 Bad Gateway yourself?

You can often fix a 502 yourself when the logs point to one wrong setting and you can safely undo the change. Get help when the request disappears between services, the logs disagree or the broken flow carries business risk.

If the logs point to one wrong setting, correct it and test the same request again. If the request disappears somewhere between Vercel, Supabase, Railway and an external API, you are no longer dealing with a one-setting fix. You need to trace the request across the full path.

What a 502 proves and what it does not

A browser request in a Lovable, React or Next.js app may cross several components before the failing code handles it:

browser → Vercel/Railway/Cloudflare → Next.js route or Supabase Edge Function → Supabase/Stripe/external API

The component returning the 502 is reporting a problem with the next hop. The broken part could be the gateway, the service behind it or the connection between them.

Cloudflare splits 502 and 504 errors into two groups: errors from the origin and errors from Cloudflare. Its checklist covers server load, crashes, network failures, timeouts and blocked services. Cloudflare also asks for the exact URL, timestamp with timezone and a diagnostic trace. The same approach works on other platforms: start with Cloudflare’s 502 and 504 troubleshooting checklist, then map each item to your own request path.

500, 502 and 504 are different clues

These status codes are often treated as interchangeable “server errors,” but they describe different observations.

Platforms sometimes wrap an application error in their own response. Treat the status code as a clue, not the answer. Read it with the response body, provider error code, headers and runtime logs.

Where 502 appears in Next.js, Lovable and Supabase apps

Find the exact network request that failed. “The Lovable app returns 502” might mean the React page did not load. It might also mean the page loaded but one call to /api/create-checkout or /functions/v1/send-email failed. Those problems need different fixes.

Next.js and Vercel: the request reached the platform, but did the function answer?

A 502 on a Next.js app can come from an SSR render, Route Handler, API route or middleware rule. Find the same request in the Vercel function logs before changing React components. If the function ran and threw an error, inspect the function and its dependencies. If there is no matching invocation, check the route and platform configuration first.

Vercel documents one specific example: too many matching routes, often caused by a routing loop, can produce a TOO_MANY_FORKS 502. That provider code points to route evaluation, not an origin port. See Vercel’s TOO_MANY_FORKS error reference.

Lovable and Supabase: identify which request actually failed

The Lovable page may load even when a backend request fails. If saving, checkout or email is broken, open the browser Network panel and find the exact Supabase Function or custom API request. Do not assume that every Supabase Edge Function error is a 502. If the interface reports Edge Function returned a non-2xx status code, use the Lovable Edge Function status-code diagnosis to identify the underlying response.

If the request fails and Next.js then replaces the page, preserve both layers. The client-side exception after deploy diagnosis explains how to match the first browser error to that failed request.

The Supabase client separates three cases: the function returned an HTTP error, the relay had a network problem, or the function could not be reached. Supabase uses 504 when a function does not start responding before its timeout. Keep the actual status and error class. They tell you whether to inspect the function code, the network path or a slow external call. See Supabase Edge Function error handling and Supabase Edge Function 504 diagnosis.

Railway: startup is not the same as proxy reachability

For a Next.js server or custom backend on Railway, a successful startup message does not mean Railway’s proxy can reach the process. Compare Railway’s port with the address and port used by the app. A proxy log that says connection refused is more useful than the browser’s 502 page.

What about Cloudflare, Nginx and AWS?

Cloudflare, Nginx and CloudFront use the same gateway-to-origin model. Their documentation can help with TLS, DNS and custom-domain problems, but a Lovable, Supabase or Next.js app does not require any of them.

For example, AWS says CloudFront can return 502 when TLS negotiation fails, the origin certificate is invalid, the origin port is wrong or closed, DNS fails, or an edge function returns invalid output. These are useful comparison cases, not the expected stack for every App Rescue Desk customer. See AWS CloudFront 502 troubleshooting.

Capture this evidence before changing production

Copy this record into the incident ticket. One complete failed request is more useful than ten screenshots that only show “Bad Gateway.”

502 INCIDENT RECORD

1. Exact URL and HTTP method:
2. Timestamp and timezone:
3. Expected result:
4. Actual status, response body and provider error code:
5. Response headers: server, via, request ID, trace ID,
   cf-ray, x-vercel-id or x-cache when present:
6. Scope: one route, one hostname, one region or the whole app?
7. Last known successful request:
8. First known failure:
9. Latest deploy, environment, domain, DNS, certificate or proxy change:
10. Platform status result at the same time:
11. Matching gateway/proxy log:
12. Matching application/function log:
13. Direct origin or health-check result, if safe and available:

Do not paste Authorization headers, cookies, access tokens, webhook secrets or customer payloads into a ticket. Redact secrets while keeping request IDs, timestamps, route names and non-sensitive provider headers intact. The production access and security policy explains what App Rescue Desk asks you to share and what should remain out of scope.

Follow one request from start to finish

Ask: “How far did this exact request get?”

1. Identify the responder. The page branding, server, via, CDN trace and provider-specific headers can show which gateway produced the visible response.
2. Correlate the same request. Search gateway and application logs using the request ID. If no shared ID exists, use a narrow timestamp, route and method.
3. Check reachability before code. A proxy-side connection refused means the connection failed before normal request handling. Confirm the configured upstream host and port against the process that is actually listening.
4. Check runtime failure if the app received it. If the application logged the request, follow the trace through middleware, route code and dependencies. An exception can still surface to the user as a gateway-generated 502.
5. Compare paths. If the origin or health endpoint works but the public hostname does not, inspect hostname, Host routing, DNS, TLS and CDN-to-origin settings.
6. Compare with the last known good state. Review deploy, environment-variable, DNS, certificate and routing changes. Do not assume the newest code commit is the only change.

If the incident began after an environment update, use the environment variable not updating in production checklist. If the application process cannot start because its database credentials fail, the visible 502 may be downstream of a connection problem covered in the Supabase SCRAM wrong password after deploy guide.

What public cases show

Public reports are useful when they include the original logs or a clear before-and-after result. They cannot diagnose your app, but they show how the same 502 page can hide different problems.

Case 1: “Application startup complete” but the proxy logged connection refused

In a public Railway community report, a FastAPI service printed a successful startup message and said it was listening on port 8080. Every public endpoint still returned 502. Railway’s HTTP log showed that the upstream connection was refused. The report did not confirm a final root cause, so we cannot blame Railway, FastAPI or one setting. Read the original Railway report.

What the evidence does establish:

• A framework startup line is not proof that the platform proxy can reach the process.
• The proxy log is more specific than the browser page. It narrows the search to the target address, port, binding, listener state or service routing.
• Repeatedly changing application routes would not address a connection that fails before routing begins.

The practical lesson is simple: a process can be running and still listen on the wrong interface or port for the platform proxy.

Case 2: Correcting a Stripe endpoint changed 502 into 400

In the same Railway discussion, another developer said Stripe was sending webhooks to the wrong Railway endpoint. After they corrected the URL, the response changed from 502 to 400 because the webhook secret was wrong. This is a community report, not a verified postmortem. Still, the new status code is useful.

A 400 is not success, but it shows that the request reached a route that could validate the payload. At that point, stop debugging gateway reachability and check the webhook configuration. Use the Stripe “No signatures found matching the expected signature” guide for that next step.

Case 3: An application exception surfaced as a platform 502

A historic Next.js issue reproduced an older serverless deployment where an exception in getServerSideProps appeared as HTTP 502 instead of the expected 500. The closed issue is from Next.js 9.5 in 2020, so it does not describe current Next.js behavior. See the original Next.js issue and reproduction.

The useful lesson is that a gateway status can hide an application exception. If the request appears in the runtime logs just before an exception, investigate that exception. Do not stop at the edge error page.

Case 4: A current provider 502 caused by routing recursion

Vercel’s current TOO_MANY_FORKS documentation links this 502 to too many matching conditional routes, often caused by a routing loop. It also lists unhandled exceptions as a possible cause. The provider code matters here; an Nginx port checklist would send the investigation in the wrong direction.

In each case, the useful step is the same: keep the provider error details and find the last service that handled the request.

A safe diagnostic order for a production 502

Work in this order so you keep the useful logs and limit customer impact.

1. Save one complete failure. Record URL, method, timestamp, headers, response body and request ID.
2. Check the provider status page. Match the incident window and affected region or product; a green page is context, not proof that your individual service is healthy.
3. Measure scope. Test the normal user flow, a known health endpoint and one unaffected route. Separate one function from the whole origin.
4. Match gateway and application logs. Use the same request ID or timestamp. Decide whether the app received the request.
5. Verify the configured hop. Compare the proxy’s upstream hostname and port with the running process or function target.
6. Test direct origin only when supported and safe. Preserve the expected Host header and authentication requirements. Do not expose a private origin as a workaround.
7. Compare the last known good configuration. Include code, environment, domains, DNS, certificates, health checks and platform settings.
8. Make one reversible change. Define the expected evidence before changing anything, then retest the exact failing flow.
9. Verify recovery beyond the home page. Re-run the affected login, API, checkout or webhook path and monitor recurrence.

Do not restart everything as your first step. A restart may restore service but remove the logs and process state that explain the failure. If you must restart to reduce customer impact, save the available logs and platform events first. Investigate the root cause separately.

What is a 502 fix you can safely try yourself?

A small, reversible fix is reasonable when the logs point to one setting. For example:

• Proxy log says connection refused to port 3000.
• Deployment configuration targets port 3000.
• The application log shows it is listening on the platform-provided port 8080.
• There is no conflicting evidence from another route or region.

Correct the upstream/listener configuration, deploy once and verify the exact failing request. Keep the before-and-after logs in the incident record.

This is safe to try because the logs show a clear mismatch between the proxy target and the app. Changing unrelated routes, dependencies or framework versions would only add noise.

When should you hire someone to fix a 502 Bad Gateway?

Hire a production bug-fixing specialist when you cannot trace the failed request to one setting, or when testing fixes could affect payments, authentication or customer data. Intermittent failures, missing application logs and problems that cross several providers need investigation, not another generic checklist.

App Rescue Desk investigates production 502 errors across Next.js and Vercel, Lovable and Supabase, and Railway or custom backends. We trace the failed request, make a focused change and test the real checkout, login, API or webhook flow. For apps built with Lovable or another AI builder, the Lovable app production bug-fixing service covers the published interface, backend and integrations together.

What App Rescue Desk needs to investigate

Send the evidence record above, plus read-only access to the relevant deployment and logs where possible. A useful investigation should answer four questions:

1. Which component returned the visible 502?
2. What was the last component to handle the request successfully?
3. What evidence identifies the failed handoff or exception?
4. What exact production flow proves the fix?

The result should be more than “the site loads again.” You should have a clear diagnosis, a reversible change and proof that the affected user flow works. If you have a live 502 and still cannot find the failing layer, start a 502 production bug-fix request with one complete incident record.

Frequently asked questions about 502 Bad Gateway

What does 502 Bad Gateway mean?

A gateway or proxy did not receive a usable response from the service behind it. The status tells you that a handoff failed, but it does not identify the broken service.

Is a 502 Bad Gateway a frontend or backend error?

Usually, it is a backend or infrastructure error. A React or Lovable page may display the error because an API route or function failed, but the frontend itself does not explain which server-side hop broke. Check the failed request in the browser Network panel.

How do I fix 502 Bad Gateway on Next.js or Vercel?

Save the failing request’s timestamp, x-vercel-id, response body and route. Then find the matching function invocation. If the function ran, inspect its exception and dependencies. If it did not run, check route rules, middleware and platform configuration.

Can a Supabase Edge Function cause a 502 error?

A 502 can appear in a request path that includes a Supabase Edge Function, but do not assume the function caused it. Check the actual HTTP status, the Supabase error class, the invocation log and any external API called by the function. Supabase also uses other codes, including 500, 504 and 546, for different failures.

What is the difference between 502 and 504?

A 502 means the gateway received an invalid or unusable upstream response. A 504 means the gateway waited for the upstream response and timed out. Both point to a gateway-to-upstream problem, but the next debugging step is different.

Should I restart the server when I see a 502?

Not before saving the logs, request ID and timestamp. A restart may restore the service, but it can remove the evidence needed to explain why the error happened and why it might return.

When should I get help with a production 502?

Get help when the error affects payments, login or customer data; when it comes and goes; or when the request disappears between Vercel, Supabase, Railway and another service. In those cases, use a production 502 bug-fixing investigation instead of testing unrelated changes on the live app.