Origin Error Page Pass-thru - switch on in Worker code


For a specific route in my Cloudflare worker, I want to set the request to ensure the origin error passes through and a Cloudflare error page is not served. How do I set that (as code) in my worker?


Are you an enterprise customer, or are you looking to replicate this functionality?


I imagine you could create a worker that checks for the status code being a specific status, then instead of returning the error page you do your return your own fetch() call to an off-site resource with your custom error information.

@Judge thanks for the note, and yes I guess that’s what we want.

In our case, the response already exists, and is fed back correctly with a JSON doc from our API - stating the reason for the error. It’s over-written by a Cloudflare error page.

Nope - I’m not enterprise, and wouldn’t upgrade just for this.

In general, I guess that given some criteria e.g. non-200 HTTP code, I just want to return the actual error from the origin with the right code, not a Cloudflare error page.

For an API, a Cloudlare error page is useless, since the JSON response contains the reason for the error. If that’s hidden behind a Cloudflare error page, a client doesn’t receive it.

Hope that explains the use case better!

After some light testing, it looks like the Cloudflare error page removes the old body text before the Worker has access to the request, so there’s no way to use a worker to proxy the original body text.


Note: this was only tested on the workers test website, it may behave differently when deployed to the account it has access to, but I can’t test that.

Thanks @Judge

A question, if I knew the route that I wanted this to work on - could I use a page rule e.g. disable apps, disable security, disable performance or some other setting to suppress this error page?

Theoretically you could use the worker and if the status is not 200, then return the page that you add in the worker as a variable, for example.

Thanks for the note @matteo

What I’d like is much simpler.

Our REST API already returns a proper JSON error response.

An API does not return “pages”, it returns a HTTP code - often with a proper JSON payload specifying the error/issue.

I simply want the ability to bypass Cloudflare “error pages” as our API already returns the proper error.

An idea, not completely spec compliant, but still workable with Workers. Always return a 200 with the code in the JSON response (or a custom header probably easier and faster, specifically on the edge without the need to parse JSON) and substitute it at the edge. Not ideal, but a workaround. If for some reason the API is down then return a custom response saved as I previously said.

Noted, thanks all! Just chewing on this further later.

1 Like

@tallyfy I know this thread is from way back, but this was a blocker for me recently and I found a solution. While not ideal it works well. You can implement a simple api gateway as a worker to sit in front of your actual api endpoints and then route the requests accordingly. The gateway would be your public facing url, and the actual worker services can would be on whatever subdomain or endpoint. If a worker throws the cloudflare html error page, you can relay this back from your api gateway to the client as whatever JSON you want. You should also allow only specific domains, I.e. your api gateway, to make requests to those workers.

Not ideal I know but it works. It also means you can customise which workers are on which usage model and only require a single ‘A’ dns config pointing to the gateway.

Hope that helps anyone having similar issues.

1 Like

thanks for this! I’ll consider this model carefully.