Skip to main content

Fix 403, 429, 502, 503 and Redirect Errors

Find out where an error on a custom domain comes from, and fix 403, 429, 502, 503 and 504 errors, redirect loops and redirects to your own domain.

Written by Drago Crnjac

First, find out who sent the error

An error on a custom domain comes either from our proxies or from your upstream: your app, or something in front of it like Cloudflare, a CDN or a load balancer.

  1. Open the page in your browser and open the developer tools.

  2. Go to the Network tab, reload, and click the first request.

  3. Look at the response headers.

If you see headers from your hosting or your app, such as cf-ray and server: cloudflare, x-vercel-id, or headers your framework adds, we forwarded the request and your upstream sent the error.

💡 Our proxies never return 403 Forbidden unless one of your own Rules does.

403 Forbidden or Cloudflare error 1015

If none of your Rules blocks the request, this comes from your upstream. A common cause is Cloudflare or another firewall in front of it. All your custom domains reach your upstream from a shared pool of our proxy addresses, and a firewall can mistake that for bot traffic and block it for a while. Bubble.io apps sit behind Cloudflare and can be affected this way.

  • Allow requests that carry your upstream's auth token in your firewall. See Secure Your Upstream with the Auth Token.

  • On Bubble.io, you can't change Bubble's firewall, so message us with the domain and the time it happened and we'll look into it.

  • Check your own country and IP rules. Country lookups are based on IP addresses and aren't perfect, so a visitor on a VPN or a hosting network can be placed in the wrong country.

429 Too Many Requests

  • Your own limits on the Rate Limiting page and Rate Limit rules return 429 when a visitor goes over them. Check whether any of them match the requests that fail.

  • If the 429 has headers from your upstream, your upstream sent it.

  • Getting 429s with no rate limits set up on your side? Message us with the domain and the time it happened, and we'll take a look.

502 Bad Gateway

Our proxy couldn't connect to your upstream within 3 seconds, or the connection failed. Check that:

  • Your upstream is running and reachable at the host and port set on the upstream.

  • The TLS setting matches. If your upstream only serves plain HTTP, edit the upstream, turn off TLS and set the port to 80.

  • With TLS on, your upstream has a valid certificate from a public certificate authority. Self-signed certificates are rejected.

  • Your upstream's firewall doesn't block our requests. Requests can come from any of our regions, including our Asia region in India, so don't block countries or regions on your upstream. Use a Country rule on our side instead.

503 Service Unavailable

If your upstream keeps failing, with server errors or no response, our proxies can stop sending it requests for a short time so it can recover. Visitors get a 503 until then. Fix the errors on your upstream and the domain recovers by itself.

504 Gateway Timeout

Your upstream, or a load balancer in front of it, took too long to answer. Look for slow requests in your app's logs. The firewall advice under 502 applies here too, since a blocked request can also end in a timeout.

Redirected to your own domain

If opening a custom domain sends you to your app's own domain, for example app.yourapp.com, the redirect came from your upstream. We only redirect when you've set up a redirect, Redirect to www, or a Redirect rule.

  • Your app needs to accept requests for any domain and use the X-Served-For header to know which custom domain was requested. See Handling Forwarded Requests.

  • Using Bubble.io? Make sure the Bubble.io option is on for the upstream.

  • If a CDN sits in front of your upstream, add X-Served-For to its cache key. Otherwise a redirect cached for one domain gets served on all of them.

Too many redirects

  • A redirect or Redirect rule points at the same address it matches, for example www.customer.com redirecting to www.customer.com. Delete or fix it.

  • Two redirects point at each other, for example Redirect to www on our side and a www-to-root redirect in your app. Keep only one of them.

Errors that come and go

Message us with the domain, the time it happened (with timezone), the full URL, and a screenshot of the response headers from the Network tab. Adding a unique query parameter to the URL, such as ?debug=123, helps us find the request in our logs.

Until next time, keep building!

Need more help? Reach out via the Intercom chat widget and we'll be right with you!

Did this answer your question?