Reverse proxy = wrong configuration using default settings from example?

[aoeftiger]

Reverse proxy = wrong configuration using default settings from example?

[tzerber]

The last time I've updated the nginx conf(~two months ago) I had no such error, this is basically a copy-paste config with minor edits from my own production environment and it's known to work without any issues.

Are you sure you're using fresh example provided ? There's a chance we can solve this together, but I would need more info on that error and your environment.

[joshtrichards]

The Apache image has a means of auto configuring things so that the Nextcloud trusted proxy configuration is unnecessary in some types of environments (see https://github.com/nextcloud/docker?tab=readme-ov-file#using-the-apache-image-behind-a-reverse-proxy-and-auto-configure-server-host-and-protocol)

The fpm images do not have this ability.

You'll have to follow the standard Nextcloud Server config process (https://docs.nextcloud.com) for the reverse proxy stuff. Though you may be able to utilize the image's TRUSTED_PROXIES and OVERWRITE* environment parameter support to do most/all of it at deployment time.

My take regarding those examples: They are sort of a "best effort" thing and everyone has their own idea about what should be in them. There's been debate about removing some of them in the past, in part because it's challenging (for those of us that try to help out with this repository) to keep them up-to-date and troubleshoot all the variations since we don't necessarily individually use all those third-party image combinations. Ultimately the images in this repository are meant to be used by people that understand Docker and the various components well enough that the examples are more a rough base to start from. There are other deployment modes (and Docker images) for Nextcloud that are meant to be more turnkey. (That's just my perspective, don't take that as anything official).

[Deniero]

Hello! I fixed the same problem using .examples/docker-compose/with-nginx-proxy/mariadb/fpm by adding the IP address of the Docker network gateway like this:

  app:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - nextcloud:/var/www/html:z
      - data:/var/www/html/data:z
    environment:
      - MYSQL_HOST=db
      - REDIS_HOST=redis
      - TRUSTED_PROXIES=172.17.0.1
    env_file:
      - db.env
    depends_on:
      - db
      - redis

[aoeftiger]

Note that I have not modified the setup, this appears using the basic configuration presented in the example here!

[aoeftiger]

@tzerber much appreciated, I'm running on a raspberry pi 4b, with the nextcloud version & docker container SHA as in the 1st post. The exact error reads like this:

There are some errors regarding your setup.
The reverse proxy header configuration is incorrect. This is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. For more details see the documentation ↗.

@joshtrichards and @Deniero , thank you for the hint. Running docker inspect on the network ID of nextcloud_default, I find

[...]
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},

so I consequently used 172.18.0.1 in the TRUSTED_PROXIES environment variable just like @Deniero indicated.

This did resolve the issue, thank you very much!

[tzerber]

@tzerber much appreciated, I'm running on a raspberry pi 4b, with the nextcloud version & docker container SHA as in the 1st post. The exact error reads like this:

There are some errors regarding your setup.
The reverse proxy header configuration is incorrect. This is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. For more details see the documentation ↗.

@joshtrichards and @Deniero , thank you for the hint. Running docker inspect on the network ID of nextcloud_default, I find

[...]
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},

so I consequently used 172.18.0.1 in the TRUSTED_PROXIES environment variable just like @Deniero indicated.

This did resolve the issue, thank you very much!

I believe you just temporary fixed it, that IP (the whole subnet actually) can change in the future unless you specifically declared it in your compose file. I did however notice an error in the example compose file that i will propose a fix once i test to confirm it. In the meantime - make sure you have the app container and the web container in the same docker network, i.e. add this to the app service in the compose file:

    networks:
      - proxy-tier #or whatever your network is called