Skip to main content
HTTP 502 (Bad Gateway) and 504 (Gateway Timeout) errors indicate a problem between the user’s browser and Curator, but Curator itself never generates these specific response codes. They are always produced by a network appliance sitting between the browser and Curator — such as a reverse proxy, load balancer, application gateway, or firewall.
Because 502 and 504 errors are generated by a middleman rather than Curator, they mask the actual underlying issue. The error you see in the browser tells you that something went wrong, but not what went wrong or where. The troubleshooting steps below focus on uncovering the real error that the 502 or 504 is hiding.
Support and troubleshooting of network appliances (reverse proxies, load balancers, application gateways, firewalls, etc.) is outside the scope of Curator support. You will need to work with your own network administrators to diagnose and resolve issues within those systems. Every network appliance is different, so any guidance in this document related to one of these network appliances is intended to be generic and will need to be adapted to your specific setup.

​
Understanding the Problem

When a request travels from a browser to Curator, it typically passes through one or more network appliances: Browser → Network Appliance (reverse proxy, load balancer, WAF, etc.) → Curator A 502 or 504 error means the network appliance could not get a valid response to pass back to the browser. The root cause could be any of the following:
  • Curator itself is returning an error — the network appliance received an error response and replaced it with a generic 502.
  • Something between the appliance and Curator is failing — a networking issue, DNS resolution failure, or certificate problem is preventing the connection from completing.
  • The network appliance itself has an issue — a misconfigured timeout, connection limit, or routing rule is causing the appliance to generate the error on its own.

​
Step 1: Bypass the Network Appliance

The single most important troubleshooting step is to see the actual response Curator is sending, without the network appliance rewriting it. There are two ways to do this:

​
Option A: Check the Network Appliance Logs

Many reverse proxies and load balancers log the upstream response they received from Curator before replacing it with a 502 or 504. Check the appliance’s access and error logs for entries corresponding to the failed requests. Look for the HTTP status code and response body that Curator returned.

​
Option B: Connect Directly to Curator

If the appliance logs don’t provide enough detail, access Curator directly — bypassing the network appliance entirely. Depending on your network setup, this might involve:
  • Using the server’s direct IP address (e.g. https://192.0.2.1)
  • Using an internal DNS name that resolves directly to the Curator server
  • Making the request from the Curator server itself
    • Linux: curl http://localhost
    • Windows: Navigate to http://localhost in a browser on the server
Once you can see Curator’s actual response, you’ll know whether Curator is the source of the problem or not.

​
Step 2: If Curator Is Returning an Error

If your direct request reveals that Curator is returning an error (such as a 500 Internal Server Error), use Curator’s logging systems to get the details.

​
Check the Event Log

Curator logs application-level errors to its Event Log. In the backend of Curator using the left-hand navigation, navigate to the Settings > Logs > Event Log page. Review recent error entries for details on what went wrong. For more information, see the Logging Overview.

​
Check the File System Logs

If the error is not in the Event Log, or if the Curator backend is inaccessible, check the system log files directly on the server: 
storage/logs/system-YYYY-MM-DD.log
These files are located relative to the Curator installation directory. For more details, see File-Based Logs.

​
Check the Web Server Logs

In cases where the error is severe enough that Curator’s application doesn’t fully boot — for example, a PHP fatal error or a misconfigured environment — Curator’s built-in logging may not capture anything. In this case, check the web server’s own error logs:
  • Apache (Linux): /var/log/apache2/error.log or /var/log/httpd/error_log
  • Apache (Windows): C:\InterWorks\Curator\libs\Apache24\logs\error.log
  • FastCGI / PHP-FPM: Check the PHP-FPM error log configured in your pool settings

​
Step 3: If Curator Is Not Returning an Error

If Curator responds correctly when accessed directly, then the issue is between the network appliance and the browser, or within the network appliance itself. At this point, focus your troubleshooting on the appliance:
  • Review the appliance’s error logs for connection failures or upstream timeouts.
  • Verify that the appliance can reach Curator’s IP and port from its own network.
  • Check for TLS/SSL certificate issues between the appliance and Curator.
  • Ensure health checks are configured to use the /ping route (see Reverse Proxy for details).

​
Common Cause: Timeout Mismatch

One of the most frequent causes of 504 Gateway Timeout errors is a timeout mismatch between the network appliance and Curator’s web server. Curator’s web server has a configured maximum execution time (max_execution_time) that controls how long it will spend processing a request before timing out. If the network appliance has a shorter timeout than Curator, the appliance will give up and return a 504 to the browser even though Curator is still processing the request and would have eventually responded successfully. Fix: Ensure the network appliance’s timeout is at least as long as Curator’s max_execution_time. Check timeout settings in all layers of your network path:
  • Load balancer — idle timeout, request timeout, or backend timeout settings
  • Reverse proxy — proxy_read_timeout (Nginx), ProxyTimeout (Apache), or equivalent
  • Application gateway / WAF — request timeout or backend connection timeout
  • CDN — origin response timeout
To check Curator’s max_execution_time:
  1. In the backend of Curator using the left-hand navigation, navigate to the Settings > Curator > API Keys page.
  2. Click to edit any API key.
  3. Use the drop-downs in the middle of the edit page to select portal and phpinfo.
  4. Click the resulting link below the drop-downs — this opens a new tab with the full PHP configuration.
  5. Search the page for max_execution_time to find the current value.
The network appliance’s timeout should be set to at least this value.