502 Bad Gateway: Diagnose the Cause and Fix Your Website

By Rahul S., Founder and SEO Consultant at SearchCounselCo. Updated October 6, 2026.

What 502 means, and how it differs from other server errors

An upstream is the next service a gateway expects to answer. A CDN may forward to Nginx, which forwards a PHP request to PHP-FPM. The service called “upstream” therefore depends on which gateway you are investigating.

1. Browser sends the request.
2. CDN or reverse proxy forwards it, if present.
3. Web server selects the application route.
4. Application or PHP-FPM produces the response.

This is a simplified delivery path, not a diagram of your hosting account. An error reported by one gateway may come from another gateway behind it.

These distinctions follow RFC 9110. Hosting layers can translate internal failures. An “nginx” label identifies software involved in the response; it does not identify the cause. Use the dedicated 503 Service Unavailable guide for that status.

How to check a 502 error as a website visitor

1. Retry an ordinary page once after a short pause. For a payment or form submission, check for confirmation before submitting again.
2. Compare a private window or another browser. If only one browser fails, investigate its extensions, stored data or proxy settings.
3. Compare another permitted network, such as mobile data. Note whether a VPN or personal proxy changes the result.
4. If independent clients reproduce the failure, send the owner the URL, time and screenshot. Report which comparison worked or failed.

At that point, stop repeating browser fixes and let the owner investigate the delivery path. These comparisons establish scope; they do not repair the upstream. MDN describes the local-network exception when others can access the site.

What website owners should capture before changing anything

Create one incident record before experimenting. Capture the original operation rather than testing only the homepage. Use the copyable incident record below to keep observations and changes together.

• Request: affected URL, GET/POST if known, public or authenticated context, and whether the failure is the page document or a background request.
• Time: first known failure and a fresh failed attempt, with timezone.
• Scope: original route, a public content page, static asset and relevant dynamic operation; note cache behavior where known.
• Evidence: response status, meaningful body, relevant headers, screenshot and request/Ray ID if present.
• Changes: deployment, PHP, plugin, DNS, CDN or hosting changes and their times.

Capture the actual failed request in your browser

1. Open developer tools and select Network before reproducing the failure. Enable Preserve log if navigation would remove the relevant requests.
2. Select the failed document or operation. In Headers, record its Request URL, Request Method and Status Code, plus useful response headers.
3. Save a redacted screenshot and note the time. If the document succeeds but an API request fails, record that API route as the original failure.

The Chrome DevTools Network guide explains these controls. A screenshot of the error page alone leaves the host without the request details needed to match logs.

Optional public GET capture

Command example: replace the URL with your affected public page

curl --silent --show-error --max-time 20 \
  --dump-header response-headers.txt \
  --output response-body.html \
  --write-out "status=%{http_code} total=%{time_total}s\n" \
  "https://example.com/affected-page/"
printf 'curl_exit=%s\n' "$?"

Inspect the saved body and headers. Record the transfer result separately: without a fail option, curl can complete a transfer successfully while receiving HTTP 502. A reported status of 000 is not an HTTP response code. A client timeout does not establish that the server returned 502. See curl’s manual.

This public GET does not reproduce a logged-in or POST-only operation. Do not automatically replay a payment or data-changing request; use the application’s approved test context.

Find the failing component: choose the next test

Match your observation to a branch. The cards are diagnostic guidance, not findings about your website. Each gives the next test, its owner and a limit on interpretation.

The branches build on PHP-FPM configuration, Nginx upstream behavior, FastCGI settings and the product-specific checks below.

How to fix 502 Bad Gateway in WordPress

Begin with the failing request and available access. A 502 does not establish that WordPress core or a plugin is broken. If all uncached PHP routes fail, inspect the shared runtime path before changing individual components.

1. If wp-admin also fails, request the host’s runtime checks

Ask the host to match the failed URL and time with web-server and PHP logs, verify the selected FPM pool and listener, and examine process exits or resource constraints. Hosting-panel access may be enough to open that support request; SSH is not required to supply useful evidence.

Use the incident handoff template. A dashboard outage does not require an immediate reinstall. Record the host’s findings and proposed correction so you can retest the same failure.

2. Use Recovery Mode only when the application error fits

WordPress Recovery Mode can activate after a fatal PHP error during a regular page load. If its email arrives, enter through the special link, record the notice identifying the failed component, and correct or deactivate that component. Exit Recovery Mode and verify normal public access.

3. Choose a targeted isolation method for your access

• Dashboard available: record the component’s active state, isolate the item implicated by evidence, then repeat the original operation.
• WP-CLI available: run in the verified installation as its appropriate user. Save the inventory and activation scope before deactivation.
• File manager or SFTP only: the documented fallback is a temporary rename of the implicated plugin folder. Record its original name, restore the directory when appropriate, and confirm the intended activation state.
• Managed host: ask the provider to perform the supported test and return the original state, change and request-matched result.

WP-CLI command examples: replace confirmed-plugin-slug with the evidenced component

wp plugin list --fields=name,status,version --format=json \
  --skip-plugins --skip-themes > plugins-before.json

wp plugin deactivate confirmed-plugin-slug \
  --skip-plugins=confirmed-plugin-slug --skip-themes

The plugin inventory records ordinary, network-active, must-use and drop-in statuses. WP-CLI documents targeted deactivation and its skip options. Must-use plugins still load with skip-plugins; a CLI bootstrap can therefore still fail. In multisite, confirm site versus network scope before changing activation.

Use the WordPress troubleshooting reference for alternate access. A command success message or a temporary folder rename is an isolation step. Verify the public operation and restore required functionality before declaring recovery.

4. Investigate logs and resource limits with a specific hypothesis

Review existing host logs first. For an application failure you can reproduce, use staging and WordPress’s debugging guidance. Keep error display off the public page. An empty WordPress log can mean the request failed before WordPress loaded.

For recurring incidents, connect failure times with the relevant worker limit, memory failure, process exit or slow route. Have the host/developer correct that condition, retest and record the result. Changing every limit together makes the useful intervention difficult to identify.

How to investigate a 502 error with Cloudflare

1. Identify the product and preserve the failed response

For an ordinary proxied site, follow Cloudflare’s 502/504 support guidance. It distinguishes origin and Cloudflare errors and describes branded/unbranded presentations. Treat appearance as a lead; match the URL, time and available request identifiers to origin evidence.

2. Compare equivalent public and origin requests

Keep hostname, path, method and relevant authentication context comparable. An administrator who knows the correct origin and its access requirements can use resolve while retaining the URL hostname. A bare IP may reach a different virtual host.

Comparison examples: replace the hostname, route and documentation-only origin address

curl --silent --show-error --max-time 20 \
  --dump-header public-headers.txt --output public-body.html \
  "https://example.com/affected-page/"

curl --silent --show-error --max-time 20 \
  --resolve "example.com:443:203.0.113.10" \
  --dump-header origin-headers.txt --output origin-body.html \
  "https://example.com/affected-page/"

Record both statuses, content and times. A certificate failure, blocked direct origin or different authenticated request makes the comparison inconclusive until interpreted. Preserve the intended access and TLS configuration; see curl’s resolve option.

3. Record cache evidence rather than assuming a fresh request

Save CF-Cache-Status when present and check its documented meaning. A HIT represents cached delivery; MISS and DYNAMIC describe different origin-interaction paths. Workers and application caches need their own context. A query-string change alone is not proof of uncached application recovery.

Development Mode temporarily bypasses edge caching and Polish. It does not purge existing cache, disable the firewall or remove the proxy. Keep its use tied to a cache investigation and repeat the original failure afterward.

4. Give Tunnel its own connector-to-service check

A Tunnel 502 stating that the origin service is unreachable can mean cloudflared is connected to Cloudflare but cannot reach its configured service. Check connector logs, service state, protocol, port and origin TLS. Use Cloudflare’s Tunnel troubleshooting; do not treat tunnel connectivity as application health.

When escalating, include timestamp/timezone, failing URL and relevant trace details, plus any Ray ID and matched origin findings. Put sensitive evidence in the support channel.

How to investigate Nginx and PHP-FPM 502 errors

These checks require access to the affected host or container. Managed-host customers can request them. Use that deployment’s real executable, configuration, service and pool; the commands below are documented examples, not results from your environment.

1. Locate the log for the same request

Find the configured error log or container log stream and match the incident time, route and upstream destination. Nginx error logging has configurable destinations and severity thresholds. No entry in an assumed file is not evidence that the request succeeded.

Where already configured, upstream address, status and timing fields help distinguish attempted backends and retries. See Nginx’s upstream variables. Correlate the record with application/service logs rather than treating one phrase as a complete diagnosis.

2. Compare effective configuration and actual listeners

Nginx checks: use the deployment’s actual binary and configuration options

nginx -t
nginx -T

The command-line reference explains these switches: -t checks syntax and opening referenced files; -T also dumps configuration. If the service uses custom configuration/prefix options, use that same context. Keep full configuration output private and extract only the relevant redacted location/upstream block.

Linux listener inspection: TCP and Unix sockets, in the relevant network context

ss -lntp
ss -lxnp

The ss manual documents listening TCP and Unix-socket views; permissions affect process details. Compare the intended listener with the configured destination. Check the correct service/pool’s status and logs through your hosting or service manager. An active process alone does not prove its application routes work.

3. Test the correct protocol and application route

proxy_pass handles an HTTP upstream; fastcgi_pass uses FastCGI, as commonly used for PHP-FPM. Do not send an ordinary HTTP curl request to an FPM port/socket and call it an application test. Compare the pool’s listen setting, then verify a meaningful PHP route through the intended web-server path.

An existing, correctly routed FPM ping can check that runtime path. PHP’s FPM reference says ping.path is unset unless configured. Its response does not establish WordPress, database or business-flow correctness. An HTTP application’s health route must likewise actually exist and be interpreted for its scope.

4. Follow the failure shown by the evidence

• Connection refused: check the configured address/port and actual service listener; investigate startup failures or the wrong endpoint.
• No such file or directory: for a Unix socket, determine whether the intended listener is missing or the configured path is stale.
• Permission denied: compare worker identity, socket/directory access and applicable security policy; correct the specific relationship.
• upstream prematurely closed connection: inspect matching upstream evidence for termination, crash or interruption; the message alone does not establish which occurred.

5. Add the header, upstream-group and container checks when relevant

6. Correct one supported condition and retest

An endpoint mismatch, startup failure, access denial and process crash need different corrections. Preserve the original setting, validate the affected configuration and apply the supported reload/deployment procedure. Nginx documents reload behavior. Repeat the failing route after the change.

HTTP proxy read timeout concerns intervals between reads. A larger timeout cannot create a listener or prevent an upstream process from dying. Investigate the measured slow operation before tuning its timeout.

Illustrative incident: Nginx points to an old PHP-FPM socket

Suppose dynamic pages fail after a pool change. A request-matched error references an old socket, while the intended active pool has a different listener. The administrator must also confirm the pool is running, the socket belongs to that site and the web-server worker has the required access.

Illustrative evidence and proposed correction — not a runnable configuration file

Constructed log clue:
connect() to unix:/run/php/site-old.sock failed
(2: No such file or directory) while connecting to upstream

Illustrative Nginx destination before correction:
fastcgi_pass unix:/run/php/site-old.sock;

Illustrative intended FPM pool listener:
listen = /run/php/site-current.sock

Proposed destination after confirming the intended pool:
fastcgi_pass unix:/run/php/site-current.sock;

The proposed action changes the affected destination through the host’s supported configuration method, validates it and applies it. This is one directive, not a complete WordPress configuration. Syntax success alone does not establish connectivity or recovery.

A successful retest would require the original dynamic request’s expected content/function, representative routes, matching log review and a declared observation period. Those results remain untested in this illustration. Record actual results using the checklist below.

How to verify that the 502 error is actually fixed

Repeat the original operation under comparable conditions. Declare the expected status and function for each route: a valid redirect or authentication response may be appropriate. A 200 containing an error page fails verification.

Use staging or approved test transactions for data-changing operations. Record cached success separately from uncached/dynamic behavior; adding no-cache or a query string is not sufficient evidence by itself.

Copy the incident and retest fields into your log. Keep each intervention and its same-request result together. If the error returns, reopen the relevant branch with the new time and evidence instead of marking the incident permanently fixed.

Does 502 Bad Gateway affect SEO, and what should you check afterward?

Google documents that 5xx responses slow crawling, their returned content is ignored, and persistent server errors can eventually lead to URLs leaving the index. Crawling increases gradually after healthy responses return. There is no universal ranking-recovery deadline. See Google’s HTTP status guidance.

1. Confirm the working site and current Google fetch separately

After delivery is stable, inspect an affected public URL in Search Console and choose Test live URL. Review availability, returned content and, where available, HTML, headers and the screenshot. Label that current test separately from the stored indexing result. URL Inspection’s documentation explains why a live success does not guarantee indexing or ranking.

2. Check robots.txt and crawl evidence

Include robots.txt and essential public resources in recovery checks. Google has separate handling for robots.txt server failures; do not turn those rules into a universal page-outage timeline.

In Settings → Crawl stats, review host availability, response categories and the incident dates, then correlate with host logs. Crawl Stats is aggregate evidence, not a complete incident log. Use the broader crawl-error investigation guide if access failures continue.

3. Review indexing and search performance as separate outcomes

Review affected URLs in Page indexing after stable delivery. For remaining exclusions, follow the indexing-problem workflow. Then compare the affected page set over comparable periods in the Search Console performance report. Keep repair time, fetch evidence, indexing and clicks/impressions in separate fields.

Copyable incident record for your host or developer

Copy these fields into your incident log or support ticket. Replace the bracketed fields with actual observations and leave unknowns identified. Share only the useful redacted evidence; exclude passwords, session cookies and personal data.

Copyable incident, change and recovery record

Subject: Reproducible 502 on [domain / operation]
Incident owner: [name or team]
Product / environment: [host, proxy/CDN, runtime if known]
First and latest failures: [dates, times, timezone]
Affected URL / operation: [redacted route]
Method and context: [GET/POST, public/logged in]
Scope: [routes, browsers, networks, recurrence]
Public result: [HTTP status, meaningful content, headers]
Request / Ray ID: [if present]
Cache evidence: [actual classification or unknown]
Recent changes: [change and time]

Matching proxy / PHP / application evidence:
[short redacted excerpt, time and evidence filename]
Upstream endpoint and service/pool: [verified or unknown]
Comparison location: [browser, host or proxy container]
Public/origin comparison: [matched results or not tested]

Change record:
[original state, one intervention, time, owner]
[same-operation retest, retained/restored, rollback]

Retest record for each selected operation:
[test ID, route, method/context, time]
[expected status and function]
[actual status, content/function, client transfer result]
[cache state, matching log evidence, pass/fail/blocked]

Observation window: [start/end, conditions exercised]
Requests / recurrences: [actual counts]
Untested conditions: [remaining limitations]
Final state and next owner action: [actual state]

Please identify the failed request in the matching logs,
explain the evidence for the correction, and verify the
original operation and representative routes afterward.

Frequently asked questions about 502 Bad Gateway

The one thing to do next

Capture one reproducible failed operation with its URL, time and response. Give your host or developer the matching incident record, then use the same operation to judge the supported correction.