custom error pages via external service in Envoy Gateway

[rodrigoGA]

Hi,
I'm new to Envoy Gateway and currently migrating from NGINX Ingress to Gateway API with Envoy Gateway as the controller.

In my current NGINX setup, I have a global error handling mechanism using a service similar to tarampampam/error-pages. When any backend service returns an error (e.g., 404,500,...), NGINX redirects the response to that error page service, which then returns a styled HTML page with CSS, images, and even JavaScript based on the error code .

I'm trying to replicate this behavior in Envoy Gateway. I’ve seen that ResponseOverrides are available, but from the documentation, it looks like they only support a fixed text response with contentType. That won't work for us since we want to serve rich error pages that could be 10MB in size and are maintained separately in a dedicated service.

Is there a way to configure Envoy Gateway to route error responses to an external service (like a dedicated error handler) and return that response instead of the original one from the backend?

If this is not currently possible, would this be a candidate for a feature request?

Thanks!

[arkodg]

should be possible in v1.5 (end July) with Redirect in Response Overrides https://gateway.envoyproxy.io/latest/api/extension_types/#responseoverride

[rodrigoGA]

thanks, but I understand that if I do this with ResponseOverride -> redirect the behavior won’t be identical, meaning:

• Envoy returns a 3 xx to the client instead of the original 4 xx/5 xx. The browser (or calling service) now sees a 302/307, follows the Location header, and only then receives the HTML from your error-pages service. The original status code is lost.
• There’s an extra round-trip. Because the client must issue a second HTTP request, you add latency and a second TCP/TLS handshake
• Your error-pages endpoint must be externally reachable. Redirects point to a real URL; the client must resolve and call it. With the NGINX-style internal rewrite, the request never left the proxy and could stay on a ClusterIP.
• Logging, metrics and cache behavior change. Logs on the application show “200” for the error page, while Envoy access logs show a 3 xx. Any CDN or browser cache now has a concrete error-page URL it can store.
• HTTP method can be rewritten. Standard 302/301 redirects turn a POST into a GET, so the body is dropped. The internal-redirect approach inside Envoy preserves the original method.

In short, a redirect behaves like a true external redirect, not like NGINX’s internal error_page rewrite.