"Access through untrusted domain" with reverse proxy, admin warnings

Regardless of how i configure trusted_proxies and/or trusted_domains, when trying to access my Nextcloud app container (Apache) through my ssl-terminating Apache reverse proxy running on the host, i get the “Access through untrusted domain” error.

Everything works fine if i expose the app container directly to the internet. The reverse proxy is setup to redirect cloud.<domain>.de to (the internal nextcloud docker port).

Container image: nextcloud:26.0.2-apache
OS: Debian 11


version: '3'

    image: postgres:alpine
    restart: always
      - db:/var/lib/postgresql/data:Z
      - db.env

    image: redis:alpine
    restart: always

    image: nextcloud:26.0.2-apache
    restart: always
      - nextcloud:/var/www/html:z
      - POSTGRES_HOST=db
      - REDIS_HOST=redis
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.<my-domain>.de
      - TRUSTED_PROXIES=<external-ipv4> <external-ipv6>
      - db.env
      - db
      - redis

    image: nextcloud:26.0.2-apache
    restart: always
      - nextcloud:/var/www/html:z
    entrypoint: /cron.sh
      - db
      - redis


For TRUSTED_PROXIES is just pasted the output of hostname -I.

Now it seems that in this version of the image, NEXTCLOUD_TRUSTED_DOMAINS is just broken (even with only a single domain), see: NEXTCLOUD_TRUSTED_DOMAINS only sets first domain in list · Issue #1666 · nextcloud/docker · GitHub

For me, setting this to anything seems to do nothing, since the output of
docker compose exec --user www-data app php occ config:system:get trusted_domains

keeps being
instead of

So then i used
docker compose exec --user www-data app php occ config:system:set trusted_domains --value="cloud.<my-domain>.de"
which seems to actuall set the config, but i still get the same error.

Edit: First problem solved
So i now tried
docker compose exec --user www-data app php occ config:system:get trusted_domains 2

which simply returned o (no idea why).

So then i did
docker compose exec --user www-data app php occ config:system:set trusted_domains 2 --value="cloud.<my-domain>.de"

and now it seems to work? I have no idea what is going on here and why this was so painful (took me two days to fix^^).

Next problem: Admin warnings

Ok so i can login, cool, however the admin console tells me the following:

You are accessing your instance over a secure connection, however your instance is generating insecure URLs. This most likely means that you are behind a reverse proxy and the overwrite config variables are not set correctly. Please read the documentation page about this :arrow_upper_right:.

However i do not want to fiddle with any config values any further without knowing exactly what the problem here is, because according to my understanding i should no need the use the override configs for a completely standard scenario like mine, right?

Any help would be appreciated!

Hey. Sorry you’ve been running into such an uphill battle.

IIRC the only address trusted_proxies generally needs in it is the externally used IP address of your proxy for the web path that needs to your Nextcloud instance (caveat: not all proxies are the same).

Were you fully rebuilding your containers each time you tried different environment variables settings in your Compose file (i.e. stopping/removing then doing an up -d)? If not that might explain some of your battles.

Also some environment variables are only used once then ignored if you’ve already ran through the install on your instance.

Lastly, to answer your main query: it’s unclear what your real config is now. Can you provide the output of:

docker compose exec -u33 app php occ config:list system

Thanks for looking at this, I guess reverse proxies are just complicated business.

Since my last post, i edited config.php directly and changed overwrite.cli.url (which already existed, i did not add the entry) from https://<my-domain>.de:8180 to https://cloud.<my-domain>.de, but i still get the admin warnings.

In terms of compose file, im quite sure docker compose up -d did automatically rebuild the containers for which I changed the env vars in the compose file, as is supposed to happen according to my knowledge. I did test this at some point by checking if environment variables were set inside the running app container correctly and that was the case.

Here ist the output of your command (replaced my domain with <my-domain>):

    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": {
            "2": "cloud.<my-domain>.de"
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "",
        "overwrite.cli.url": "https:\/\/cloud.<my-domain>.de",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "skeletondirectory": false