Reverse proxy behind Cloudflare with Origin CA & HSTS

Hi,

I am running Ubuntu Server LTS on a thinclient at home and have had Hestia install Wordpress and Nextcloud in a subdomain wp.mydomain.com and nextcloud.mydomain.com respectively. The whole thing is proxied by Cloudflare and all that works very well, now I also have some other WebUIs of services that I would like to reverse proxy to, such as for example Calibre-Web ebook library and qBittorrent-nox. Like with the above I created subdomains calibre.mysite.com and torrent.mysite.com and now also created custom nginx templates for each passing the location to the respective ports of the WebUIs and assigned them in Hestia, but I am unable to reach the WebUIs via the domains. The official qBittorrent wiki on Github provides a page for running the WebUI behind Nginx reverse proxy, however it doesn’t cover HTTPS. NGINX Reverse Proxy for Web UI · qbittorrent/qBittorrent Wiki · GitHub
I have Cloudflare configured for maximum security, that is Origin CA, HSTS etc. This issue is about running qbt-WebUI behind Cloudflare CDN: WebUI Content Security Policy with Cloudflare CDN · Issue #10025 · qbittorrent/qBittorrent · GitHub
Both Calibre and qBittorrent-nox have built-in support for https and allow you to configure Certificate and Key, and both provide an option to ‘Enable reverse proxy support’ and add trusted reverse proxies, which option isn’t mentioned in the wiki at all. I am not sure what to add for Trusted reverse proxy header names or maybe custom headers. I have cp.mysite.com passing the Hestia CP and with only the proxy_pass directive in the nginx template and it is working perfectly fine, however I cannot reach the other WebUIs (Cloudflare Bad Gateway Host Error).

This is what the nginx configuration now looks like:




What happens when you set Cloudflare to DNS Only on those hostnames? Aside from an expected unknown CA warning on the origin CA certificate, do they work properly with a direct connection?

DNS Only I’m getting ‘Too many redirects’. CF encryption to Flexible I can access qbt WebUI but there is an Error rendering it unusable and that doesn’t appear when I access the same instance via the local network.

In the Github page of the Calibre-Web docker image they use uwsgi_pass instead but I installed from pip and dont have the necessary sock file, uwsgi_pass to the TCP socket %ip%:port; and nginx fails to start at all.

I’m a bit lost now after hours of trying today and yesterday, I might let it rest and try with docker as there’s images ready for qbt and calibre and the proxy manager. I wanted to save myself the resource hit.


That’s at least part of the problem. Don’t ever use Flexible. It is insecure and falsely indicates otherwise to your vistors. It’s also the most common cause of redirect loops at Cloudflare. Set your encryption mode to Full (strict).

https://community.cloudflare.com/t/why-you-should-choose-full-strict-and-only-full-strict/286652

It’s only torrent.mysite.com (and calibre) that’s via rule on CF configured to Flexible, the rest of the page is Strict and there isn’t going to be anybody else using the Torrent client other than me.
But ideally I want to use Strict eventually.
Also, turns out the Error:n appears only on Chrome Android, desktop and other browsers work.

It doesnt matter what the purpose domain is. Flexible causes endless redirect loops when the origin has an HTTP to HTTPS redirect of its own.

An HTTPS connection is made to Cloudflare. Cloudflare sends Flexible connections to the origin over HTTP. The origin redirects the browser to HTTPS which connects to Cloudflare. This process loops forever.

It’s s lot simpler to use Let’s Encrypt or a Cloudflare Origin CA certificate and Full (strict) to avoid endless redirects and other bad things.

That makes sense.
I have Calibre working via Full Strict now, this being the location block, in case anybody in the future looks for it:

I’m still struggling with qBittorrent. (Bad Gateway)

1 Like