Why does Nextcloud say "Access through untrusted domain" behind a reverse proxy?

Because the hostname your reverse proxy passes on is not in trusted_domains, and in the official Docker image the variable you probably used to set it, NEXTCLOUD_TRUSTED_DOMAINS, is read once, during the automated install, and never again. Editing the compose file and recreating the container changes nothing. Add the name with occ, which writes it into config.php:

docker compose exec -u www-data app php occ config:system:get trusted_domains
docker compose exec -u www-data app php occ config:system:set trusted_domains 2 --value=cloud.example.com

Use the next free index. The first command prints the list one entry per line, and the first line is index 0. Setting an index that already exists replaces that entry: in our test, writing index 1 removed the domain that had been there, and that name started getting the error page instead.

Two answers circulate, and the popular one is wrong in both directions#

The first answer is "set NEXTCLOUD_TRUSTED_DOMAINS". It is right only before the first start. The image's docker-entrypoint.sh handles the variable inside its install block, which runs when the volume holds no installed Nextcloud, and only when NEXTCLOUD_ADMIN_USER, NEXTCLOUD_ADMIN_PASSWORD and a database are all set. If you finished the setup in the browser instead, the variable was never applied at all.

The second answer extends the first: "all of the proxy variables are install time only, so use occ for everything." That is also wrong, the other way. TRUSTED_PROXIES, OVERWRITEPROTOCOL, OVERWRITEHOST, OVERWRITECLIURL and OVERWRITEWEBROOT are read by reverse-proxy.config.php, a file the image copies into config/, which calls getenv() on every request. Change those in compose, recreate the container, and the new value applies at once.

What the README does say is narrower: "once set at install time, removing these environment variables later won't remove them from your config/config.php". The installer writes the merged configuration into config.php. So removing a variable does not bring back auto-detection; it brings back the install-time value.

What each variable does after install, measured#

We installed nextcloud:apache (Nextcloud 35.0.2) with SQLite through the automated install, with NEXTCLOUD_TRUSTED_DOMAINS=cloud.example.com, TRUSTED_PROXIES=172.16.0.0/12 and OVERWRITEPROTOCOL=https, then changed each variable and recreated the container with docker compose up -d.

The fourth row is the trap that keeps forum threads going. When a key is set by a variable, the image's config file is merged over config.php, so occ writes a value nobody reads and reports success. Rule of thumb: a key you set with an environment variable is changed in compose; a key you did not is changed with occ. occ config:list system shows what is actually in force, which is why the README recommends it over reading config.php.

The install also left overwrite.cli.url at https://localhost (http://localhost without the protocol variable). Nextcloud's installer builds it from the address of the install request. Set it to the public URL, because the reverse proxy page of the admin manual says it is the base for URLs generated "using any kind of command line tools", such as the notifications area.

Why the hostname is untrusted in the first place#

Nextcloud's installer, Setup.php, writes one trusted domain: the host of the request that ran the install. With the browser wizard, that is whatever was in the address bar, for example 192.168.1.10:8080 if the proxy was not built yet. With the automated install in Docker it is localhost, and NEXTCLOUD_TRUSTED_DOMAINS adds entries from index 1. Then the proxy goes up, forwards Host: cloud.example.com, and Nextcloud answers HTTP 400 with "Access through untrusted domain".

How the check matches, from TrustedDomainHelper.php and our requests:

• Ports are ignored. cloud.example.com:8443 passed with only cloud.example.com in the list.
• Localhost is always allowed, whatever the list says.
• Wildcards work. *.example.org accepted a.example.org and a.b.example.org, and refused example.org.
• overwritehost switches the check off. The code comment reads "overwritehost is always trusted", and a request with Host: evil.example.net got a redirect, not the error. Many threads fix the error this way. It works, and it removes the protection config.sample.php says trusted domains exist for, which is "host header poisoning".

If the proxy runs with a trusted proxy configured, Nextcloud checks X-Forwarded-Host instead of Host. Caddy and Traefik send the same name in both, so the entry is the public hostname either way.

What each proxy sends, and what Nextcloud needs from it#

We put Nextcloud behind Caddy 2.11.7 and Traefik 3.7.16 with no proxy settings at all, then pointed each at traefik/whoami to record the headers. For Nginx Proxy Manager 2.16.0 the headers come from the proxy.conf that every generated proxy host includes.

The redirect row is why trusted_proxies matters even when the domain error is gone. Nextcloud's Request.php believes X-Forwarded-Proto only when the request comes from an address in trusted_proxies; otherwise it sees plain HTTP from the proxy and builds http:// links. Either fix worked in our test: setting trusted_proxies to the proxy network, or setting overwriteprotocol to https, made the redirect https://. Set both. overwriteprotocol keeps the links right if the proxy's address changes, and trusted_proxies is what lets Nextcloud read the real client from the proxy's headers, which the admin manual says it uses "for access control and logging".

The client IP row comes from the image, not Nextcloud. The README says the Apache image replaces the remote address with X-Real-IP for any proxy in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Traefik and NPM send that header, Caddy does not, so behind Caddy Apache logged the proxy. If you want Nextcloud to take the client from X-Forwarded-For instead, the README's instruction is to set APACHE_DISABLE_REWRITE_IP=1 and list the proxy in TRUSTED_PROXIES. Why container logs show 172.17.0.1, not the client IP explains why trusting a whole Docker subnet can let a client forge that header.

The settings, in one block#

If you manage them in compose, this is the whole set for a proxy on the same Docker network:

services:
  app:
    image: nextcloud:apache
    environment:
      TRUSTED_PROXIES: 10.201.14.0/24
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.example.com

Replace the CIDR with the proxy's real network. docker network inspect <network> -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}' prints it. Do not copy 172.16.0.0/12 from a thread: on our test host Docker allocated 10.201.x.x networks, so that range matched nothing. Docker subnet clashes and address pools covers where those addresses come from. The admin manual lists addresses and CIDR ranges as the accepted forms for trusted_proxies, so a container name is not one of them, and the Docker README says CIDR notation is supported for IPv4.

The trusted domain still goes in with occ, as above, because no variable can add it after install.

When this answer stops applying#

• Not the official image. The variable behaviour above belongs to the official nextcloud image's entrypoint and its reverse-proxy.config.php. The occ command and the config.php keys are Nextcloud's own and apply to any install.
• An older volume. The README warns that the image's config files in config/ are not overwritten on upgrade. It says an outdated copy "may cause certain auto configuration environment variables to be ignored", and the startup log warns that the file "differs from the latest version of this image".
• Nextcloud served under a path. Add overwritewebroot, as in the admin manual's subdirectory example.
• We did not test the FPM image with a separate web server, IPv6 proxy addresses, or NPM against a live Nextcloud.

What to do next#

Run occ config:system:get trusted_domains, add the public hostname at the next index, set TRUSTED_PROXIES, OVERWRITEPROTOCOL and OVERWRITECLIURL in compose, recreate, and check the result with occ config:list system. If the proxy itself returns an error before Nextcloud answers, Why Nginx Proxy Manager returns 502 Bad Gateway reads the log line for you, and Reverse proxy and TLS has the rest of the proxy setup. If this is the moment you are wondering whether Nextcloud is worth the upkeep, OpenCloud vs Nextcloud and Nextcloud vs Seafile weigh the two lighter file servers against it, and the Nextcloud profile lists its other traps.