> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting 502 and 504 Errors

> Diagnose and resolve HTTP 502 Bad Gateway and 504 Gateway Timeout errors when accessing Curator through a reverse proxy, load balancer, or other network appliance.

export const BackendNavPath = ({levelOne, levelTwo, levelThree, tab, section}) => {
  const levels = [levelOne, levelTwo, levelThree].filter(Boolean);
  const lastLevel = levels.length ? levels[levels.length - 1] : '';
  return <span>
      In the <a href="/setup/installation/linux_installation">backend of Curator</a> using the left-hand navigation,
      navigate to the
      {levelOne && <strong>{" " + levelOne}</strong>}
      {levelOne && levelTwo && " > "}
      {levelTwo && <strong>{levelTwo}</strong>}
      {levelTwo && levelThree && " > "}
      {levelThree && <strong>{levelThree}</strong>} page.
      {(tab || section) && <>
          {" "}On the {lastLevel} page
          {tab && <> click the <strong>{tab}</strong> tab</>}
          {tab && section && " and"}
          {section && <> expand the <strong>{section}</strong> section</>}.
        </>}
    </span>;
};

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.

<Note>
  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.
</Note>

<Note>
  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.
</Note>

## 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.

<BackendNavPath levelOne="Settings" levelTwo="Logs" levelThree="Event Log" />

Review recent error entries for details on what went wrong. For more information, see the
[Logging Overview](/site_administration/logging/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](/site_administration/logging/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](/setup/proxy_configuration/reverse_proxy#health-checks) 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

<Note>
  To check Curator's `max_execution_time`:

  1.   <BackendNavPath levelOne="Settings" levelTwo="Curator" levelThree="API Keys" />
  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.
</Note>