Occasionally, users are presented with 5XX errors when implementing the StackPath Services with an Origin server. This article will help guide through some of the common issues.
Examples of 5xx Response Codes?
500-class response codes indicate a server failure occurred while processing a request. When using a CDN, it's helpful to think of them like this:
- 502 - Bad Gateway: The edge server(CDN), when acting as a proxy received an invalid response from the origin server. (Also referred to as the upstream server)
- Imagine the request as a phone call - Someone picked up the phone, but it wasn't who you expected.
- 504 - Gateway Timeout: The edge server(CDN), when acting as a proxy did not receive a timely response from the origin server.
- Imagine the same phone call, but it never even rings. It just says 'please try your call again later'
Viewing 500 Errors in the Browser
Since the base HTML for your site is not cached on the CDN by default, receiving a 502 or a 504 error in the browser is an indication that the web server is unable to respond to the CDN's initial request to your server for that HTML and then returns a 5xx error.
Let's take a look at a few examples of the different types of messages you might see in a browser when getting a 502 or 504 error.
502 Error:
- “502 Bad Gateway”
- “HTTP Error 502 – Bad Gateway”
- “502 Service Temporarily Overloaded”
- “Error 502”
- “502 Proxy Error”
- “HTTP 502”
- “502 Bad Gateway NGINX”
504 Error:
- “504 Gateway Timeout”
- “HTTP 504 Gateway Timeout”
- “HTTP 504 Error”
- “HTTP 504”
- “504 Gateway Time-Out”
- “Nginx 504 Gateway Timeout”
- “Gateway Timeout (504)”
- “504 Gateway Timeout NGINX”
Note each error has multiple examples with different wording, but they all mean the same thing. The wording can vary from site to site.
Viewing 500 Errors in the terminal
To confirm these errors via terminal, you can use the cURL command to send an HTTP request to your site via your CDN URL:
curl -I myCDNURL.stackpathcdn.com
HTTP/1.1 504 Gateway Timeout
date: Thu, 13 Dec 2018 14:53:45 GMT
accept-ranges: bytes
cache-control: max-age=10
X-HW: 1544712810.cds078.da2.h2,1544712810.cds117.da2.sc,1544712825.cds117.da2.p
access-control-allow-origin: *
Connection: keep-alive
Content-Length: 0
Fig A - an example of a 504 response while running 'curl -I' against a StackPath customer's CDN URL.
We cURL against the CDN URL to make sure that the CDN is proxying the connection to the origin. In the example above we can see a couple key bits of information to take note of:
- We see a response of 504 Gateway Timeout
- We see the X-HW header ends in '.p', indicating that this request was proxied to the origin, not served from cache.
- The X-HW is inserted by the CDN and can tell us where an asset is served from, what PoP the request is going to, and whether or not the response came from cache or was from a proxied connection to the origin.
When the CDN is proxying a request, it is just passing the request to the origin server and then reporting back to the browser what it receives. In this case, the server gave a 504.
There are some things we can look at to start narrowing down what the issue would be when we get these kinds of errors. Let's take a look at and go into some of the more common ones.
Troubleshooting the '502 Bad Gateway' error
Common causes for this particular error are:
- The CDN isn't actually connecting to the correct server
- Ensure that the IP address set in your Origin Information is correct.
- If using a domain in your Origin Information, ensure it resolves back to the correct IP address
- A firewall or other security device is blocking the request: Something that is not your origin is blocking the request from the CDN.
- Check that your firewall is not dropping requests from our CDN
- Make sure that any DDoS protection you might have has not been triggered by origin pull requests from the CDN.
- Some CMS security plug-ins may also be the culprit - try disabling them and refreshing your site to rule this out.
- Make sure you have Whitelisted all the Stackpath IP Blocks on your server's firewall (link will open a new window)
- Domain is not resolving properly
- Double check your DNS records are properly configured and properly propagated.
- You can use a tool like What's My DNS to check on how your records are configured.
- Origin pull is encountering a redirect loop
- Curl the origin URL and see where it is redirecting. Oftentimes a redirect loop is due to the origin trying to redirect to itself or the CDN, and we attempt to follow that redirect as the default behavior.
- The most common fix is to set the "Origin Pull Policy" in StrikeTracker to "HTTP or HTTPS". This will allow the CDN to obey any redirect protocol changes from your origin.
For more information on troubleshooting 502 errors, and what is going on during a request that returns a 502, feel free to take a moment to read over this article.
Troubleshooting '504 Gateway Timeout', and other common 5xx Errors
A lot of times this isn't your fault at all, but it's typically not on the CDN or Client side either. To diagnose some of this, we can do the following:
- Check that the host header is set correctly in the StackPath Control portal.
- Make sure the HTACCESS file is correct on the server.
- especially if WordPress has been recently re-installed or restored.
- Make sure you have Whitelisted all the Stackpath IP Blocks on your server's firewall (link will open a new window)
- Ensure that the server is not having problems at the WordPress level, the Apache/NGINX/WebServer level or at the Operating System level.
- Permissions issues in the operating system
- Database corruption
- Server hardware/infrastructure issues
- Issues with server's resources (RAM, Disk i/o, CPU)
- Server issues that prevent WordPress from properly accessing its database or other resources can result in the server returning a 504, or at times a 503 error.
- If you don't know how or what to check, or don't have access to your server's operating system, you will want to contact your hosting provider to help check on this with you.