You seem to have pointed a Cloudflare Tunnel to your Nginx Proxy Manager instance, which is not necessarily a problem, but the fact that you are doing this suggests a misunderstanding about a Cloudflare Tunnel’s typical function. Cloudflare Tunnels can essentially be seen as replacements for reverse proxies like Nginx Proxy Manager and are particularly useful for people who cannot forward ports on their network (if, for example, your ISP doesn’t allow port forwarding). Therefore, pointing a Cloudflare Tunnel to an Nginx Proxy Manager installation would typically be redundant.
If you are able to forward ports on your network, then I would recommend forwarding external port 443 to port 30022 of your Nginx Proxy Manager machine, completely bypassing the need for a Cloudflare Tunnel. I prefer this approach because it doesn’t force you to rely on an additional third-party to route all of your traffic and because, officially, Cloudflare does not allow video or other large files to be served through them unless the content is also hosted by Cloudflare (and based on your description, it sounds like your server is self-hosted). Even if you stop using Cloudflare Tunnels, you should still be able to manage your domain on Cloudflare, which means you should still be able to use the SSL certificate you created with them. Otherwise, your proxy host configuration seems good, but I should mention:
I have never tried creating a proxy host with multiple domain names or multiple domains for the SSL certificate
You didn’t include the server IP for the proxy host configuration, but you might have just forgotten to write it out in your comment.
If port forwarding isn’t an option for you, then I would recommend pointing your Cloudflare Tunnel directly to your Nextcloud installation (thereby completely removing Nginx Proxy Manager from the picture). In other words, the Cloudflare Tunnel configuration would be something like:
One more thing you should try is not checking Use different port for URL rewrites, since this option should only be checked if you are not setting the host using the OVERWRITEHOST environment variable and are setting the host with the Host field (refer to Option 1 and Option 2 from the guide, which should be seen as mutually exclusive).
Nextcloud install:
Host: blank
Environment variable: OVERWRITEHOST - value: nextcloud.mydomain
Certificate: ‘truenas_default’ Certificate (use different port for URL rewrites is NOT CHECKED)
I’m still getting the same error with “Connection timed out Error code 522”
Thank you for any suggestion / correction to make my setup a working one.
You may find my comment in response to @PZ0013 helpful. I would try running the Port Checker tool that I linked there on port 443 for both your external IP and your domain.
Another thing I noticed is that you made it seem like the A record in your DNS settings is not for your wildcard domain since you wrote mydomain and not *.mydomain.
However, you also seem to have an A record for Nextcloud specifically, so maybe this isn’t the issue. In any case, it is important to understand that just an A record for mydomain will not redirect requests for nextcloud.mydomain.
The simplest solution would be to remove your A record for Nextcloud and just create a single A record for *.mydomain, since this will work for nextcloud.mydomain, collabora.mydomain and any other services that you decide to open to the outside world that end in .mydomain, but I suppose you could also create a unique A record for every single service/subdomain.
In any case, I’d be curious to see your results from the Port Checker tool. If it says that port 443 is open on your external IP but closed on your domain, then we would almost certainly be able to narrow things down to a DNS issue.
Your results are actually pretty promising. It is important to understand the difference between internal and external ports. When you set up the port forwarding rule on your router, you forwarded external port 443 to internal port 30022 of your Nginx Proxy Manager device:
This is why it’s called port forwarding. You are redirecting all outside traffic that comes in on external port 443 to your Nginx Proxy Manager internal IP (192.168.0.111) and port (30022). Depending on the exact URL entered by the user, Nginx Proxy Manager then redirects incoming traffic again to another internal IP and port, based on the configurations of your proxy hosts. As far as the outside world is concerned, though, the only open port should be port 443, so the fact that ports 80, 30022 and 30027 are closed is a good sign.
This is also what is so great about a reverse proxy. Without it, you would need to open a unique port for every service that you want to access from the outside world, which is not only a security risk, but also means that you would need to remember each service’s unique port number. With a reverse proxy, however, you only need to open one port (443), you can specify memorable subdomains for each service (e.g., nextcloud.mydomain) and any incoming traffic that doesn’t match any of the subdomains that you have set up in your proxy hosts will simply be blocked.
Anyway, two things from your response jump out to me:
You should be checking not only whether port 443 is open for your external IP address, but also whether port 443 is open for your domain (the tool can test both domains as well as IP addresses, even though the fact that it says Your IP Address makes it seem like it can only test IPs).
If you find that the tool reports that port 443 is open for your external IP but closed for your domain, then we could almost certainly conclude that the issue is with your DNS configuration.
Assuming that you have already changed the domain name in your A record on your DNS configuration page from mydomain to *.mydomain, you also need to ensure that the A record is pointing to your external IP address. The fact that you said this…
…made it sound like your actual IP and the IP listed in the A record in your DNS configuration are different, which would be wrong. The IP indicated on the Cloudflare DNS page should be your external IP.
If you have a dynamic IP address, then now would also be a good time to ensure that you have some type of working DDNS (Dynamic DNS) solution. Otherwise, the link between your domain and your IP address will be severed (and will need to be manually updated) each time your IP address changes. Since you are using Cloudflare for DNS, this page on Cloudflare’s website mentions two options for setting up DDNS with them. If that is too technical for you, then you may want to look into which DDNS providers, if any, your router natively supports and then switch over to one of those providers (this would also allow you to run DDNS entirely from your router, thus avoiding the need to run a script on another one of your devices).
Thank you for the latest information, it was helpful.
I have checked my domain with portchecker.co for the following ports:
80 and 443 - open
30022 and 30027 are closed
You are right, I have dynamic IP address.
Based on this: Cloudflare DDNS Setup on SCALE 24.10.2 I was able to setup a custom app on TrueNAS but it updated only mydomain and not the www, and other A records.
So this is useful but for me it updates only mydomain A record:
version: ‘3.5’
services:
cloudflare-ddns:
image: oznu/cloudflare-ddns:latest
restart: always
environment:
- API_KEY=
- ZONE=mydomain
- ZONE_ID=
- PROXIED=true
See my DNS setup on Cloudflare:
However, he also points out that doing this will remove Dynamic DNS for just the domain itself (without any subdomains). Directly below, favonia points out that this is a known limitation of the tool, referencing this thread.
If you need Dynamic DNS for your domain and its subdomains, then it looks like you will need to find a different solution. Otherwise, I would recommend adding that - SUBDOMAIN=* line to your yaml and removing all A records besides the one for your wildcard domain (with name *).
I have found another solution: GitHub - favonia/cloudflare-ddns: 🌟 A small, feature-rich, and robust Cloudflare DDNS updater
It’s constantly running and it updated my IP addresses on Cloudflare DNS record page to my external IP - so this is success.
The DDNS part seems working but I still get the same error message. When I simply enter nextcloud.mydomain to the browser it still displays the page with http:
That other solution looks promising. Without seeing your actual configuration, though, it’s hard to know what could be going wrong. I would be extra careful to make sure that you have the same subdomains for:
Your Nextcloud installation (nextcloud.mydomain.tld)
Your DNS configuration (*.mydomain.tld or at least nextcloud.mydomain.tld)
Your proxy host in Nginx Proxy Manager (nextcloud.mydomain.tld)
Your SSL certificate (*.mydomain.tld or at least nextcloud.mydomain.tld)
I also noticed that in your most recent screenshot, a connection was attempted over httpinstead of https. This suggests that there might be a problem with your SSL certificate. You haven’t mentioned how you are trying to generate an SSL certificate, so I would be curious to see your solution for that. You are also more than welcome to post your configurations for anything else in your current setup.
Since you are using Cloudflare for DNS, you should be able to generate an SSL certificate from a trusted certificate authority directly through Nginx Proxy Manager (which I would recommend), as opposed to using a self-signed certificate. This guide appears to show you how to do exactly that. It involves creating a Cloudflare API token, which you should have already done, seeing that the docker-compose file in favonia’s GitHub repository has a CLOUDFLARE_API_TOKEN field.
If you want to go the self-signed route, don’t forget that I made a guide for creating a self-signed SSL certificate in one of my replies to @PZ0013. I prefer not using self-signed certificates because you will typically be greeted with an obnoxious warning message whenever you try to access a website that uses them.
Your configuration seems more or less correct. Again, the only things I would try would be:
Removing mydomain and *.mydomain from your Domain Names in your proxy host configuration (leaving just nextcloud.mydomain)
Removing nextcloud.mydomain from your SSL certificate (leaving just mydomain and *.mydomain)
Removing the nextcloud and www A records (leaving just mydomain and *)
I don’t see why any of the aforementioned would necessarily pose a problem. I am just thinking that issues might be arising out of redundant name matches. For example, in your proxy host, SSL certificate and DNS configuration, the user-entered URL of nextcloud.mydomain would satisfy the conditions of both nextcloud.mydomainand *.mydomain, so changing things such that only one field could ever match a specific URL might make the server less “confused”.
Even if this isn’t causing any errors, there is no point in having nextcloud.mydomain in your SSL certificate, since that would already be caught by the wildcard (*.mydomain). Similarly, there is no point in having explicit A records for nextcloud and www, since those would be caught by the wildcard A record (*).
In the likely scenario, however, that none of the aforementioned helps resolve your issue, a good place to start might be this video (also see this video and this video). It seems that the error code 522 you are experiencing is specific to CDNs like Cloudflare. If the problem ends up having something to do with Cloudflare, then your guess (with respect to the exact cause of your problem) would be as good as mine, since I am not using Cloudflare as my DNS provider. Looking at several other videos that were also about troubleshooting error code 522, they all seemed to agree that the root cause of this error typically has something to do with Cloudflare.
Also, the error could have something to do with your client device, so you should try to access your Nextcloud server from a different computer to see if that changes anything.
Sorry I couldn’t be of more help! I hope you find the solution. The good news is that there still seem to be lots of things that you can try to troubleshoot your issue.
@owl
Thank you for your suggestions. You pointed me to the right direction and I was able to solve my issue.
The glitch was with Cloudflare DNS / SSL settings. Once I sorted that out, everything worked smoothly.
With the help of your detailed and welll elaborated guide and support I was able to install Nextcloud and Collabora.
You are great, thank you!
Thank you for the excellent guide. I tried both options 1 and 2 by following your instructions to the letter, but I continued to receive errors… One error was a timeout related to too many redirects. Another was an invalid SSL certificate error. Has anyone made a working setup recently?
I am using a duckdns domain that points to my public IP.
I have configured DDNS for this domain using the Windows client.
Port forwarding is enabled and tested working on my router.
I have created a Dynu SSL and associated it with the Proxy Host in Nginx using all of the same settings as you.
Any ideas related to why I am getting ERR_SSL_PROTOCOL_ERROR?
Never mind, I found the issue. I had mistakenly assigned the wrong port forwarding in my router (I forwarded 80 to https and 443 to http). Reversing these worked for me.
There is a problem with this solution. Docker Nextcloud is hardcoded to rewrite and redirect all forwarded traffic to port 443, no matter which port is in URL. NPM doesn’t work with IPs, only FQDNs, so if you use router DDNS, Nextcloud AIO will bounce back all forwarded traffic back to your router, as it’s occupying port 443 with Web UI on that domain name. So you have to install App with same port that you will use externally and you have to use overwritehost in Nextcloud config with you external domain and port. Which means that even inside LAN you will still have to access Nextcloud by domain, not by internal IP.
You still forward external port to 30022 of NPM.
NPM in the middle could have been avoided, if we could have an ability to set multiple Hosts to the app with own certificate to each, so you can forward port directly to Nextcloud
That isn’t difficult.
server {
listen *one port* ssl;
http2 on;
server_name *some or multiple IPs/domains*;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains;" always;
ssl_certificate /usr/local/etc/cert/nextcloud1.cer;
ssl_certificate_key /usr/local/etc/cert/nextcloud1.key;
ssl_trusted_certificate /usr/local/etc/cert/ca.crt;
include conf.d/nextcloud.inc;
}
server {
listen *another port* ssl;
http2 on;
server_name *other IPs/domains, like external*;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains;" always;
ssl_certificate /usr/local/etc/cert/nextcloud2.cer;
ssl_certificate_key /usr/local/etc/cert/nextcloud2.key;
ssl_trusted_certificate /usr/local/etc/cert/ca.crt;
include conf.d/nextcloud.inc;
}
