Could you tell me which part of my guide you’re referring to here? I would love to update the guide to be more clear if I knew.
@ owl
Wow, just wow. Thanks for putting all this together and in such a thorough manner. Am also really glad to see you getting it working.
Unfortunately, it’s still not working on my end. Given the router provided DDNS in the format of subdomain.domain.tld, I’ve tried both *.domain.tld and *.subdomain.domain.tld in the Subject Alternative Name fields.
In both cases, I’ve get a 502 Bad Gateway, which seems to suggest NPM is not forwarding the traffic across to [FileBrowser/NextCloud] (?)
Not sure if this information is useful.
@ owl
I was actually referring to the Techworks guide above and at any rate looks like you’ve already picked up on it as above.
It’s worth noting that I myself have been using a free subdomain from Dynu for every part of this guide, and it sounds like you are in the same position as me (i.e., you have access to a subdomain but not the domain that it falls under).
As far as the scope of what you are trying to do is concerned, subdomains should function the same as domains, but it is important to remember that, if you are using a subdomain, you must replace all references to mydomain.tld in my guide with your subdomain (i.e., mysubdomain.domain.tld). This means that:
- Your Nextcloud host, OVERWRITECLIURL environment variable and Domain Name in Nginx Proxy Manager should all be something like nextcloud.mysubdomain.domain.tld.
- Your Collabora Server Name should be something like collabora.mysubdomain.domain.tld:443 and your Collabora Domain Name in Nginx Proxy Manager should be something like collabora.mysubdomain.domain.tld
- The Subject Alternative Name for your self-signed SSL certificate should be *.mysubdomain.domain.tld and not *.domain.tld.
Also, you mentioned that you are using the DDNS that is provided by your router, but you still have an online account with whichever DDNS service you are using, right? I’m just asking this because it might also be worth logging into your DDNS account and examining things like the DNS records to make sure there’s nothing fishy going on there.
Forgive me if you have already done all of this. I’m just trying to exhaust the obvious solutions first. The cause of a 502 Bad Gateway error can often just be one of the aforementioned things being set incorectly.
I see, good to keep in mind.
Thanks! But also, I don’t think I could have gotten it working without your input. I appreciate you keeping me in the loop. I am learning a lot, too.
@ owl
Yep that’s right
Yes that’s my understanding and what I’ve done also. (Just for completeness, I’m currently using FileBrowser instead of NextCloud now, and not using Collabora. That said, that’s hopefully not relevant as the issue seems to be about NPM).
The DDNS provided by my router acts like a function / value added service it seems. ie. Within the router interface, you switch on/off the function, select a DNS Service Provider and (sub)domain name) and it’s all set. There isn’t much scope for anything else to be checked, though that said, what else can I check?
No, thanks for giving it as much thought as you have.
Just to state my understanding explicitly in case I got something wrong:
- external traffic on port 443 is directed to NPM via port forwarding on the router;
- NPM then forwards the port 443 traffic to the internal ip (device) running the service (FileBrowser in this case)
The 502 Bad Gateway seems to be implying the traffic is indeed being forwarded to NPM, but NPM is forwarding it to the wrong place? (Otherwise the error would be about an unresolved domain name or similiar)
A question that comes to mind as I write this is how does NPM know what traffic received from which external port to forward to which internal port? eg. If I port forward on my router ports 100 and 101 to my NPM instance, in NPM we only set the destination address in the Proxy Host settings. There’s no setting that determines the destination address should receive traffic from which external port?
@ owl
jfc it finally worked
The 502 Bad Gateway errors did indeed suggest a traffic forwarding problem with NPM.
Changing to the Forward Hostname / IP to local IP running the FileBrowser instance from ```localhost`` was the critical change. Completely idiosyncratic but I’m going to take what I can get.
Conversely playing around with the SSL certificate settings didn’t have any impact for me (ie. wildcard settings on domain name, Common Name & Subject Alternate Name)
This has been a highlight for me poking around with networking, etc. Thank you again.
Some cleanup points for anyone else who might find this useful:
Back to a fundamental understanding of how network traffic works:
- access to a service (eg. FileBrowser/NextCloud/etc) as provided by a server is done by entering a domain name
- the domain name is converted to an IP, in particular an external IP if accessing externally
- receipt and transmission of traffic from the external network (WLAN/internet) to internal network is handled by the router
As such, what determines what traffic the Proxy Host should be forwarding to which destination address is the Domain Name input in NPM (and has nothing to do with ports).
This was enlightening for me at least.
Thank you so much, I was trying to run the built-in CODE server with no luck…this saved me.