top of page

How to Quickly Fix the 502 Bad Gateway Error: Step-by-Step Guide

Updated: Jul 15


You open a website, expect the page to load, and instead see a blank screen displaying 502 Bad Gateway. The message may look technical, but it usually means that two servers failed to communicate correctly.


To Fix 502 Bad Gateway errors, you first need to identify whether the problem comes from your browser, hosting server, application, CDN, or another upstream service. The steps below start with simple checks before moving to server-level troubleshooting.


How to Quickly Fix the 502 Bad Gateway Error: Step-by-Step Guide

What Does a 502 Bad Gateway Error Mean?


A website request often passes through several systems before the page reaches your browser. A gateway server, proxy, CDN, or load balancer may receive your request and forward it to the main application server.


A 502 error appears when the gateway receives an invalid response or no usable response from the upstream server.


Think of it like ordering food through a waiter. The waiter takes your order to the kitchen, but the kitchen does not provide a clear response. Since the waiter cannot complete the request, they return with an error instead.


The browser is not always the source of the problem. In many cases, the issue exists somewhere between the gateway server and the server processing the website.


Common Causes of a 502 Bad Gateway Error


Several problems can interrupt communication between servers.


Server Overload

A server may stop responding when it receives more traffic or processing requests than its available resources can handle. High CPU usage, exhausted RAM, or too many simultaneous connections can cause delayed or invalid responses.


For example, an online store may work normally throughout the week but display a 502 error during a limited-time sale. The sudden increase in visitors can overwhelm its application server.


Faulty PHP Configuration

PHP-based websites, including many WordPress sites, rely on PHP workers and PHP-FPM processes. Incorrect timeout values, unavailable workers, broken extensions, or stopped PHP services can prevent the web server from receiving a valid response.


CDN or Proxy Issues

A content delivery network sits between visitors and the origin server. If the CDN cannot connect to the origin server, it may return a 502 error even when the domain itself remains active.


Incorrect DNS records, blocked CDN IP addresses, SSL configuration problems, and temporary network failures can all interrupt this connection.


Application or Plugin Errors


A recently installed plugin, theme, module, or application update may trigger a fatal error. The application may then close the connection before sending a complete response to the gateway.


DNS Problems

Incorrect or outdated DNS records can send visitors to the wrong server. DNS changes also require time to spread across different networks, which can temporarily produce inconsistent results.


Firewall Restrictions

A firewall may mistakenly block requests from a reverse proxy, CDN, monitoring system, or another server. The gateway sends a request, but the origin server refuses the connection.


Network Communication Failure

Temporary routing problems can occur between data centres, proxy services, and application servers. Even when each individual server is running, the connection between them may fail.


Server Timeout

The upstream server may take too long to process a request. Once the gateway reaches its timeout limit, it stops waiting and returns an error to the visitor.


Quick Checks Before Changing Server Settings


Start with the least invasive checks. A 502 error may disappear without requiring any server configuration changes.


1. Reload the Page

Wait for 30 to 60 seconds and refresh the page. A temporary traffic spike, service restart, or network interruption may have caused the error.

Use a normal refresh first. If the page still fails, perform a hard refresh:


  • Windows: Press Ctrl + F5

  • macOS: Press Command + Shift + R


Avoid refreshing continuously because repeated requests may add more pressure to an overloaded server.


2. Open the Website in a Private Window

A private or incognito window loads the website without relying heavily on existing browser cookies and cached files. If the site works there, the problem may exist in your regular browser session.


3. Try Another Device or Network

Open the page using a different device or switch from Wi-Fi to mobile data. This helps determine whether the issue affects everyone or only your current network.


For example, if the website loads on mobile data but not through office Wi-Fi, the problem may involve local DNS caching, firewall rules, or the internet service provider.


4. Clear the Browser Cache

Old browser files can sometimes interfere with updated website resources. Clear the cache, restart the browser, and test the page again.


This step is more useful when only one user sees the error. If every visitor receives the same message, the issue is probably server-side.


How to Fix 502 Bad Gateway Errors Step by Step


The following methods require access to the website dashboard, CDN account, hosting panel, or server.


Step 1: Confirm Whether the Website Is Down for Everyone

Ask another person to test the website or use an external availability checker. You can also test multiple pages on the same domain.


The results provide an important include:


Test result

Likely problem

One browser is affected

Cache, cookies, extensions, or local DNS

One network is affected

Router, firewall, ISP, or DNS resolver

One page is affected

Application code, database query, plugin, or script

Entire website is affected

Server, CDN, proxy, DNS, or hosting issue

Error appears only during traffic peaks

Resource shortage or server overload


This comparison prevents unnecessary server changes when the issue exists only on one device.


Step 2: Check the Hosting Server Status

Sign in to your hosting panel or server monitoring dashboard. Look for unusually high CPU usage, low available memory, full disk space, or stopped services.


Important services may include:


  • Nginx or Apache

  • PHP-FPM

  • MySQL or MariaDB

  • Application runtime services

  • Reverse proxy services

  • Container services


If you manage the server, check whether these services are running. Restart only the failed service rather than rebooting the entire server without investigation.


Step 3: Review Error Logs

Server logs often provide the clearest explanation for a 502 response. Check logs immediately after reproducing the error so that the relevant entry is easier to find.


Common log locations include:


  • /var/log/nginx/error.log

  • /var/log/apache2/error.log

  • /var/log/httpd/error_log

  • /var/log/php-fpm/error.log


The exact location depends on the operating system and server configuration.

Look for messages related to:


  • Connection refused

  • Upstream timeout

  • No available PHP workers

  • Permission denied

  • Memory limit exceeded

  • Process terminated

  • Invalid response header

  • Socket connection failure


A message such as “connection refused” may mean the application service is stopped or listening on the wrong port. An “upstream timed out” message suggests that the application took too long to respond.


For a deeper checklist covering different server environments, refer to this guide on 502 Bad Gateway troubleshooting.


Step 4: Restart the Relevant Server Service

If a required service has stopped, restart it through the hosting control panel or command line.


For example, a server using Nginx and PHP-FPM may show a 502 error when Nginx is active but PHP-FPM has stopped. Nginx receives the browser request but cannot pass the PHP file to the application processor.


Typical Linux commands may include:


  • sudo systemctl restart nginx

  • sudo systemctl restart apache2

  • sudo systemctl restart php-fpm


PHP service names vary by version and operating system. Confirm the correct service name before running a command.


After restarting, test the website and check the logs again. If the service stops repeatedly, investigate memory usage, configuration errors, application crashes, and process limits.


Step 5: Check PHP-FPM and Application Worker Limits

PHP-FPM uses worker processes to handle PHP requests. If all workers remain busy, new requests may wait until the gateway timeout expires.


Review settings such as:


  • pm.max_children

  • pm.start_servers

  • pm.min_spare_servers

  • pm.max_spare_servers

  • request_terminate_timeout


Do not increase these values without considering the server’s available memory. Each additional worker consumes resources, so aggressive settings can make the server less stable.


A practical example is a WordPress website that runs several resource-heavy plugins. During a traffic spike, every PHP worker may become occupied, causing Nginx to return 502 errors. Increasing worker capacity may help, but removing inefficient plugins or improving caching may offer a safer long-term solution.


Step 6: Temporarily Disable the CDN or Reverse Proxy

Pause the CDN proxy and connect the domain directly to the origin server, where possible. If the website starts working, the problem may involve CDN settings, SSL mode, DNS records, or firewall restrictions.


Check that:


  • The CDN points to the correct origin IP address.

  • The origin server accepts connections from the CDN.

  • SSL certificates are valid.

  • The selected SSL mode matches the origin setup.

  • Firewall rules allow the CDN’s current IP ranges.

  • The origin server is listening on the correct port.


Re-enable the CDN after correcting the configuration. Leaving it disabled may affect caching, security controls, and website performance.


Step 7: Inspect DNS Records

Verify that the domain’s A, AAAA, or CNAME records point to the correct destination.


An outdated A record may direct users to an old server. An incorrect AAAA record can also cause problems when browsers attempt to connect through IPv6 while the server is not properly configured for it.


If you recently changed hosting providers or server IP addresses, allow time for DNS caches to update. Avoid making repeated DNS changes during this period because they can make troubleshooting more confusing.


Step 8: Check Plugins, Themes, and Recent Updates

If the error appeared after a website change, reverse that change first.


For a WordPress website, you can:


  1. Disable the most recently installed plugin.

  2. Switch temporarily to a default theme.

  3. Roll back the latest plugin or theme update.

  4. Check whether the website works without custom code.

  5. Review the PHP error log for fatal errors.


When the dashboard is unavailable, plugins can often be disabled by renaming their folders through a file manager or SFTP. Rename one plugin at a time so you can identify the exact cause.


Step 9: Review Firewall and Security Rules

Check whether the server firewall, security plugin, intrusion-prevention system, or web application firewall is blocking legitimate requests.


Pay particular attention to rules added shortly before the error started. Rate limits may also block a proxy or CDN when many visitor requests appear to come from the same group of IP addresses.


Use logs to confirm a block instead of disabling the entire firewall. Turning off all security controls may hide the original problem while creating new risks.


Step 10: Increase Timeouts Carefully

A timeout increase can help when the application needs slightly more time to complete a legitimate task. However, it should not become the default fix for slow code or overloaded infrastructure.


Relevant settings may include:


  • Nginx proxy_read_timeout

  • Nginx fastcgi_read_timeout

  • Apache ProxyTimeout

  • PHP max_execution_time

  • Load balancer idle timeout


Suppose a reporting dashboard performs a large database query and takes 70 seconds to respond, while the gateway waits only 60 seconds. Raising the timeout may allow the report to finish, but optimising the database query would provide a better permanent solution.


Step 11: Check Database Performance

A slow or unavailable database can prevent the application from generating a response. Confirm that the database service is running and accepting connections.


Look for:


  • Long-running queries

  • Locked tables

  • Connection limit errors

  • High memory usage

  • Full storage

  • Incorrect database credentials

  • Corrupted tables


Database problems may appear as application errors rather than direct 502 messages. Always compare web server, application, and database logs for the same time period.


Step 12: Evaluate Server Resources

Frequent 502 errors may indicate that the website has outgrown its current environment. Shared resources can become a limitation when an application requires predictable CPU, memory, storage performance, or worker capacity.


Moving demanding workloads to an environment with isolated resources, such as reliable VPS hosting, can make resource usage easier to monitor and control. However, server capacity alone will not fix inefficient code, incorrect proxy settings, or broken application services.


How to Fix 502 Bad Gateway Errors in WordPress


WordPress users can follow this focused sequence:


  1. Clear the WordPress and CDN caches.

  2. Disable recently added plugins.

  3. Temporarily activate a default theme.

  4. Check the PHP error log.

  5. Confirm PHP-FPM is running.

  6. Increase the WordPress memory limit only when logs show memory exhaustion.

  7. Test database connectivity.

  8. Restore a recent backup if the error started after an update.


Avoid reinstalling WordPress immediately. A full reinstall may not help when the real cause is PHP-FPM, Nginx, DNS, or the database server.


Common Mistakes to Avoid


Rebooting Without Checking Logs

A reboot may remove the error temporarily, but it also clears useful evidence from active processes. Check logs and resource usage before restarting the server whenever possible.


Changing Several Settings at Once

If you modify DNS, PHP, Nginx, firewall, and CDN settings together, you may not know which change solved—or worsened—the problem. Make one controlled change, test it, and record the result.


Increasing Every Timeout

Longer timeouts can hide slow applications and keep server workers occupied for longer. Find out why the upstream server is slow before raising timeout values.


Disabling Security Completely

Turning off the firewall or web application firewall may make the website accessible, but it can expose the server. Review blocked requests and create narrow exceptions instead.


Assuming the CDN Is Always Responsible

A CDN may display the error, but the origin server can still be the real cause. Test both the CDN connection and the origin server before assigning blame.


Ignoring Disk Space

A server with no free storage may fail to create logs, sessions, temporary files, or database records. Include disk usage in every server health check.


Upgrading Resources Before Fixing the Application

More CPU and memory may reduce symptoms, but poorly written queries, broken plugins, and incorrect service settings can continue causing errors. Optimize the application and configuration alongside any infrastructure upgrade.


How to Prevent Future 502 Errors

You cannot prevent every temporary network failure, but you can reduce the frequency and duration of these errors.


Use practical safeguards such as:


  • Monitor CPU, RAM, disk space, and service availability.

  • Set alerts for high resource usage and stopped processes.

  • Keep the operating system and application software updated.

  • Test plugin and application updates in a staging environment.

  • Configure PHP workers according to available memory.

  • Optimize slow database queries.

  • Use page and object caching where appropriate.

  • Review CDN, proxy, and firewall logs regularly.

  • Maintain tested backups.

  • Document configuration changes.


Monitoring is especially valuable because it shows what happened before the error appeared. Without historical data, a server may look normal by the time an administrator signs in.


Frequently Asked Questions


Q. Is a 502 Bad Gateway error caused by my browser?

A. Sometimes, but not usually. If clearing the cache or switching browsers solves the issue, the problem may be local; if all visitors see it, the server or gateway is the more likely cause.

A. The error itself does not normally damage website files. However, repeated errors may point to server crashes, database problems, or resource exhaustion that should be investigated.

A. A temporary error may disappear within a few minutes after a service recovers. Configuration errors will continue until someone corrects the underlying DNS, proxy, application, firewall, or server problem.

A. Yes. A plugin may trigger a fatal PHP error, consume excessive resources, or create a slow request that exceeds the gateway timeout.

A. Clearing the browser or CDN cache can help when outdated data or a cached error response is involved. It will not fix a stopped server service, incorrect DNS record, or application crash.

A. A 502 error means the gateway received an invalid response from the upstream server. A 504 error generally means the gateway waited for a response but did not receive one within the allowed time.

A. Restart the affected service first when you can identify it. Reboot the whole server only when necessary, and review the logs so the same problem does not return unnoticed.


Conclusion


To Fix 502 Bad Gateway errors effectively, begin with basic browser and network checks, then examine the server, application, CDN, DNS, firewall, and database in a logical order. Logs are usually more useful than guesswork because they show where communication failed.


When resource limits contribute to repeated errors, learning how a VPS provides isolated server resources can help you evaluate whether your current hosting environment still suits the workload. The reliable VPS hosting overview offers a useful starting point for further learning without replacing proper application and configuration troubleshooting.

Comments


bottom of page