HTTP(s) Error Pages

You may supply any HTML content to display to clients in case of errors, these error pages will override the default X4B Pages. These error pages will not however override any error pages served from your web server which will not be touched by our services

Set a custom page

1. Open Services, choose the service's Action → Ports, then the HTTP/HTTPS port's Action → Error Pages.
2. Find the required error, such as 503: Service Unavailable, tick Enabled, and enter the HTML. Choose that error's Submit to save only that entry, or Submit All to save the whole page.
3. Reload and confirm the saved HTML. Preview opens the current HTML in a new tab; it does not save changes or reproduce a live edge failure.
4. To restore the X4B default, clear that error's Enabled checkbox and choose Remove for an HTML override, or Submit All for a redirect-only override. This removes the override, so retain your source HTML separately if you will reuse it.

Error Page defaults

All error codes (and mitigation pages) available for user override have default error pages provided by us. These error pages provided by us are available in multiple languages. Language contributions are largely provided by customers, if you wish to contribute a translation please contact us.

Default Error Pages (served by us) can be identified by a comment of <!-- X4B --> before the final HTML tag. Unless the error page relates to a billing matter (such as non-payment) we do not include visible branding in these pages. You can view HTML comments from the "View Source" page of your web browser or with software that displays HTML as text output (such as curl).

Error Page override

All HTTP Error Pages can be overridden by customers at the (virtual) port level.

The available error pages include:

• HTTP 403: Forbidden due to ACL
• HTTP 408: Client Timeout
• HTTP 481: Insecure Request
• HTTP 497: An HTTP request sent to an HTTPS port
• HTTP 500: Internal Service Error
• HTTP 502: Bad Backend
• HTTP 503: Service Unavailable
• HTTP 504: Backend Timeout
• HTTP 521: Too Many Connections (HTTP 503)
• HTTP 522: Request Limited (HTTP 503)

Redirection URL

Optionally a redirection URL may also be supplied. Redirection URLs may also include the following variables:

• $scheme - Either http or https depending on the clients connection
• $host - The connecting hostname
• $request_uri - The original request path, including the leading "/" and query string
• $uri - A legacy alias for $request_uri in error-page and maintenance redirects; it also includes the query string here

Use https://$host$request_uri to preserve the original path and query string, for example /search?q=test. Unlike error-page and maintenance redirects, normal zone and REDIR port targets expand $uri to the normalized path without query parameters. Prefer the explicit $request_uri variable for consistent meaning across these settings.

To redirect instead, clear the HTML, enter Redirection (optional), choose the status and Submit. An override accepts HTML or a redirect, not both. For example, https://status.example.net/ with 302 - Found sends visitors to a separate status page. Use a destination that remains reachable during an outage. 307 and 308 preserve the request method and body; choose them only when the destination should receive those requests.

On Error code "481: Insecure Request" this may be used to redirect HTTP (insecure) traffic received on an HTTPS port which can be useful for certain applications.

Maintenance

Configure maintenance mode in Access Control → Maintenance. You may supply custom HTML or an optional redirect URL; otherwise the default maintenance page is used.

Maintenance exclusions allow selected client IPs to reach the backend during maintenance. IP rules still apply. See Access Control for the combined controls and address format.

UUIDs

Default X4B error pages include a request UUID in the footer of each generated error messages (not compatible with Safari, including iOS). This UUID can be used to identify a specific request in the error log in your dashboard. This UUID is also sent to the backend server in a header defined by you if enabled (off by default), for more information see the HTTP Options documentation.

If you would like to include the request UUID in your custom error pages you may do so by including a version of the following HTML snippet in your error page:

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    entry.serverTiming.forEach((serverEntry) => {
		if(serverEntry.name == "x4b" && document.getElementById("uid").innerText.length == 0) document.getElementById("uid").innerText=serverEntry.description
    });
  });
});

["navigation", "resource"].forEach((type) =>
  observer.observe({ type, buffered: true }),
);

This will store the UUID in the element with the ID of "uid" which you can then display in your error page. You may modify this snippet to meet your needs. However note only the first observed uuid should be displayed (the failed request).