@girish Thanks for responding so quickly! I'll need to revisit my DNS knowledge to get that up and running. Doesn't seem too crazy to do. Thanks for the link, and also for actually trying to answer Daniel's question inside your link. Too many times people say "just don't do that" or, "do this other thing instead". Drives me insane 🙂
I wonder if nginxproxymanager is an app or something that we have to make sure Cloudron should integrate with? I feel it's the latter. If that's the case, let us know what is needed on the Cloudron side to make proxying work.
What I mean is: nginx proxy manager should be your "front" and Cloudron is just one of the apps it proxies to.
If there is an API, maybe we can at some point look into integrating with nginx proxy manager i.e an app installation can add entries into nginx proxy manager. Of course, this is viable only if nginx proxy manager is a supported and reasonably popular product. I remember we had similar ideas for integrating with Cloud Firewalls to open up ports automatically.
I think there is a good use case for exposing a custom URL mapping via Nginx that doesn't necessarily go to a container on the local system.
This has use cases for a single (sub)domain providing proxy and load balancing services, as well as cluster management down the road.
As of now, the default nginx.conf loads all .conf files from applications/ directory.
Unless there is anything in the code that wipes out all conf files instead of only individual ones, adding a custom on there for a custom use case won't cause problems for other apps and won't be overwritten on upgrades.
If you want to feel safer, keep the custom .conf elsewhere and use a symlink from the applications/ directory.
Note: It took me a minute to put this together while @nebulon was responding and I got pulled onto something else for a minute, but I think the detailed writeup is worth having for posterity, so I'll post it anyway.
So what's going on here is that the app in question isn't reading the "right" headers to find the remote address. Basically, the inbound requests come in and hit the box-level nginx reverse proxy, which forwards the request on with the original inbound IP in the X-Forwarded-For header. Since from the sound of it, you're just routing straight to your app in the container, you'll want to either reconfigure your logging library to use the forwarded IP header as the client IP or drop nginx or similar as a reverse proxy in front of your app and configure it to rearrange the incoming headers as your app needs.
Sounds like you can just adjust a configuration so that this (your existing flow) works nicely:
Basically, here, the headers are adjusted in the "Step 1" processing as they reach the Cloudron so when they reach your app, the proxied headers have already gone into place. Again, this configuration should be fine with the configuration that @nebulon mentioned going in, since that should reconfigure your framework to read these adjusted headers correctly.
Failing that, or for apps with more complex setup or which aren't able to read those headers on their own by configuration, the solution is to further proxy those requests, by adding nginx or similar to take over the "Step 3" handoff and smooth out any specific details (like re-adjusting headers) for the app, and having it proxy those requests down to your app, all in-container, so that the logging and such in your app will all match up with expectations/reality. The whole point of the second reverse proxy when it's added it to make the world appear as it needs to for the app and/or its components inside the container.
@niko You have to convert the app into a Cloudron app for all this to reliably work. We don't support running/installing other things other than Cloudron on the same server. This is because Cloudron will overwrite nginx configuration etc from time to time (for example, updates bring in new configuration).
If your app has a Dockerfile, you can make it a custom app with not too much work - https://docs.cloudron.io/custom-apps/tutorial/ . Custom app will automatically get certs, backups, restore, clone features etc with no extra work. What framework/language does your app use?
@randyisscott I'm not entirely sure if the article I saw on https://www.proxies.com/ipv6 is attending to my question. I don't think I need all the additional trusted domains and trusted proxies stated there. Trusted domains are meant to tell nextcloud to allow access when you access it at cloudxxx or by IP address. They also have a duplicate in there, probably need to remove that. Trusted proxies I believe should only list the IP address of the proxy server, nothing else. I'm not sure if that affects the redirect loop but I would start there.