I’ve configured Nextcloud behind a ngingx reverse proxy both in docker.
Everything works great. though, I have a specific problem and I can’t find a hint in the docs nor in the existing forum posts. Hope anybody can help me.
I can ping my proxy form my nextcloud server:
root@nextcloud:/var/www/html/config# ping system-servers_nginx.ramaekers-stassartbe_internal
PING system-servers_nginx.ramaekers-stassartbe_internal (172.19.0.4) 56(84) bytes of data.
64 bytes from system-servers_nginx.ramaekers-stassartbe_internal (172.19.0.4): icmp_seq=1 ttl=64 time=0.060 ms
If I configure my config.php with the hostname in trusted_proxies, my proxy isn’t trusted.
0 => ‘10.9.0.253’,
1 => ‘system-servers_nginx.ramaekers-stassartbe_internal’,
Nextcloud can’t be accessed…
If I use the ip-adress, all is ok
0 => ‘10.9.0.253’,
1 => ‘172.19.0.4’,
My problem is that depending on starting and restarting services, the ip of the nginx server can differ…
Why can’t nextcloud resolve the hostname of my nginx server like ping can regarding the array trusted_proxies?
Other services work nicely with hostnames
‘dbhost’ => ‘ramaekers-stassartbe_drive_db.ramaekers-stassartbe_internal’,
is no problem… I don’t have to resort to entering an ip-addres.
For now I’ve done a dirty fix by using 220.127.116.11/8 in the array… but i don’t like that because maybe in the future the subnet won’t be 172,x,y,z…
Just a few followup questions since I’m just curious about how this proxy thing works with the config.php file
Does nextcloud docker have a nginx webserver already baked into the container?
In terms of your reverse proxy – I’m interpreting that you are running two separate containers – both an nginx container and a nextcloud container? Is this correct?
Could you mind sharing your docker-compose file?
In terms of the config.php, once you made the changes to your config.php and added your proxy by name, did you restart the the docker network?
A couple other things you could try.
Create a docker routed network where container is identified by IP address. Basically assigns static IP addresses to each of the containers.
If your IP address of the reverse proxy changes, however you are fairly confident its going to be an address in the 172.19.0.0/24 block then you could add 172.19.0.0/24 to your list of trusted proxies rather than just 172.19.0.4.
on starting these services, I also run this line (in a startup script):
docker network connect ramaekers-stassartbe_internal system-servers_nginx
Regarding the remarks about the subnets: I would like to install my services on ‘setup-and-forget’ principle. So if the standard setup of docker changed the docker subnet, I would like to have it start my services out of the box without the need of changing my config.php…
Just curious – didn’t you have a post about having a domain name rather than an IP address within your trusted_proxies array with using the traefik reverse proxy?
@dominique In terms of the “setup and forget it”, the best would be to probably use domain names like you are trying to do, but I suppose you might try creating a routed docker network where you control all the IP addresses (so they wont change in the future) – it’s kind of like you are assigning static IP addresses to all your containers. I’ve done this a few times but I usually find other means:
I still find it strange the trusted_proxies won’t resolve the hostname. I have now implemented a redis server. The redis server is in the same compose file as the nginx server with similar network configuration. I configuring the redis server in config.php with its hostname and it works perfectly.
I’ll keep searching for a solution. I’ve yet to actually explore your problem. I’m still configuring everything here for intra-LAN communication, I’ve yet to add the reverse proxy in front of my Nexcloud installation in order to make in available to the outside world. I would agree based on the documentation I’ve seen thus far from Nextcloud, that the need to specifically specify an IP address rather than a host name is problematic. Maybe I’ll find a workaround when I get there.
This might not be exactly OPs problem, but in case someone comes across this while googling:
I thought I had this issue using the official nextcloud-apache image (nexcloud didn’t pick up on the https), but in my case it seems like apache itself trusted the traefik proxy (I assume because it’s using an IP in a private ip range), so nextcloud already received the real client IP in the REMOTE_ADDR parameter and thus ignored the HTTP_X_FORWARDED_PROTO part.