Cloudron Forum

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:
container-sans-rp.png
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.
container-rp.png

@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?

@girish Thanks. I'd already started down that route (reluctantly) because I could see no other option. I'll see how that goes ...

I'll have to get back to that tomorrow.

Thanks again for the clarification. (Some more detailed documentation on the main site would have been helpful.)

@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.