Reverse Proxy infront of Cloudflare


We currently have a reverse proxy infront of our Heroku app that serves certificates for 3rd-party domains.

We’d like to route traffic from through Cloudflare: Proxy => Cloudflare => Heroku.

It seems that Cloudflare doesn’t support that and returns a 403.

Is there any other solution for this? Maybe Argo Tunnel? We can’t afford SSL for SaaS at this point.


What is the reason you’d like to have that setup?

Generally it should work, but you should disable security and would lose that aspect of course.

The proxy generates and serves let’s encrypt certificates.

The security/ddos stuff is exactly why I want Cloudflare in-between :slightly_frowning_face:

Well, with a proxy in front of it you’d lose most of it as all requests came from the same host.

You do know you get a wildcard certificate from Cloudflare, right?

Since you mentioned SaaS, depending on how far along your business is, I would advise you contact Cloudflare for enterprise pricing. This would allow customers to CNAME your domain (this is called a managed CNAME), which would then get SSL issued for those domain names by the Cloudflare certificate authority service.

Without enterprise, you should have no problem reverse proxying your domain. You would need to set it up to where the HOST header is that of your actual domain, and the 3rd party domain is in a separate header, like x-forwarded-host (or a custom header key) and your heroku application would have to respect the x-forwarded-host header as the actual HOST.

@sandro: I’m strickly talking about 3rd-party root domains, not subdomains on our Cloudfare domains.

@Judge: Cloudflare Enterprise is outside our budget right now. Could you elaborate on your suggestion? I don’t quite follow.

That wouldnt work with Cloudflare anyhow. You need to have one domain for your account.

The solution would work somewhat like:

  1. customer sets as a CNAME pointing to a :grey: reverse proxy subdomain
  2. Reverse proxy adds the following headers to the request to Cloudflare
  • x-forwarded-host: the original hostname the CNAME is for. eg would be the value if the request came from that hostname
  • x-forwarded-ip: the visitor’s real IP address. You can’t rely on Cf-Connecting-Ip since that will be your Reverse proxy IP address.
  1. Reverse proxy will proxy traffic to a different subdomain on your domain that is :orange:.
  2. Your application behind Cloudflare must change its logic to obtain the visitor IP address from thex-forwarded-ip header and the original hostname ( from the x-forwarded-host header.

Also make sure your proxy’s IP is whitelisted in the Cloudflare firewall.

With this setup, you lose the Cloudflare Firewall/IP reputation, DDOS protection (someone could just DDOS your reverse proxy) and the performance of Cloudflare’s anycast network, but features like caching and WAF will still work.


Thanks a lot, that’s what I was looking for!

Good points, however I’d still question the point of the exercise.

It would only cache on the PoP close to the proxy though, he could achieve the same with a cache on his own proxy.

Which part of WAF would you exactly refer to? Considering the entire traffic will originate from one IP address and that IP address should be allowlisted the entire firewall idea will go down the drain.

WAF as in rule-based detections. Even with my own IP whitelisted on my website, I still get blocked by trying to access /.git/HEAD (SCM access rule).

Fair enough, though I assume you are talking about a paid plan, which I am not sure will be involved.

To be honest, I still question the setup :smiley:

I agree, that kind of setup probably does more harm that good, but it might make sense in some situations.

Primarily it complicates everything but leaves out most (all?) of Cloudflare’s benefits. Unless there is a convincing argument for it I’d strongly suggest to skip one of the proxies, either the own or Cloudflare.

Just my two cents if anybody asks :smiley:

This topic was automatically closed after 14 days. New replies are no longer allowed.