.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
The page is almost empty. Access through untrusted domain, a line telling you to contact the administrator and a link to the documentation. You are the administrator, which makes the advice less useful than it could be....
Nextcloud throws this screen in a handful of situations I keep meeting: you reached a fresh install by IP and now you're trying the new domain, you put a reverse proxy in front of a working instance, you moved the install to another server or port, or you pointed a second hostname at it without telling config.php. Your files are fine. The web server is fine. One array in one file is the entire problem, and on Nextcloud 34.0.3 it behaves exactly like it did back on 24 when I first tripped over it.
What trusted_domains checks
Nextcloud compares the Host header of every request against the trusted_domains array in config.php. That's the whole test. It doesn't resolve DNS, doesn't inspect the TLS certificate and doesn't care what Apache thinks its ServerName is. If the exact string the browser sent isn't in the array, you get the untrusted domain screen, even when the request landed on the right vhost with a valid certificate. The check exists to block Host header injection (password reset links get built from that header, among other things), so I leave it strict rather than looking for ways around it.
Knowing it's the Host header gives you the fastest diagnostic too. Each rejected request gets written to nextcloud.log as a trusted domain error, together with the literal hostname that was tried, so thirty seconds in the log tells you the exact string to add. If you don't know where that log lives on your setup, I've mapped the locations in where are the Nextcloud logs.
On my box the check is one grep:
sudo grep "Trusted domain error" /var/www/nextcloud/data/nextcloud.log | tail -n 3Each hit records the remote address and the host string it tried. Copy that host string exactly, port included, and that's your new array entry. When I first put a proxy in front of my instance, the log showed requests arriving with 127.0.0.1:8080 as the host, which told me in one line that the proxy was rewriting the header (that case gets its own section below). Guessing would have taken an hour, the grep took ten seconds.
Add the domain in config.php
On a manual install the file is /var/www/nextcloud/config/config.php. The setting is a numbered array, and the numbers matter for the occ command in a minute:
'trusted_domains' =>
array (
0 => '203.0.113.50',
1 => 'cloud.example.com',
2 => 'cloud.example.com:8443',
),That example holds the three entry shapes you'll ever need: a bare IP, a plain domain and a domain with an explicit port. The port one trips people constantly. cloud.example.com and cloud.example.com:8443 are different entries, because the browser sends the port as part of the Host header on anything except 80 and 443. Add both when you serve on a nonstandard port. Save the file and reload the page, config.php is read on every request, so there's no service to restart.
If you're mid-first-setup anyway (new box, no HTTPS yet), the initial setup and HTTPS guide in our knowledgebase covers the domain and certificate steps in one pass, which beats fixing them one error screen at a time.
The occ one-liner
When I'm already in a shell I skip the editor:
sudo -u www-data php /var/www/nextcloud/occ config:system:set trusted_domains 1 --value=cloud.example.comThe 1 is the array index. Check what's already there first with occ config:system:get trusted_domains, because writing to an index that's in use replaces it silently, and occ config:system:delete trusted_domains 2 drops a single entry when you're cleaning up old hostnames. I once overwrote index 0 (the IP entry I was actively connected through) and locked the browser session out of the very instance I was fixing. The shell kept working, occ doesn't care about Host headers, so the same command with index 2 put it back.
Docker and compose: NEXTCLOUD_TRUSTED_DOMAINS
The official image takes a space separated list in an environment variable:
environment:
NEXTCLOUD_TRUSTED_DOMAINS: "cloud.example.com 203.0.113.50"Here's the caveat that generates half the confused issue threads: on current images the env vars feed the auto-configuration that runs at initial install. The official image README notes that values written at install time stay in config.php even after you remove the variable, and the reverse holds in practice too, editing the variable on a container with an existing config won't reliably rewrite the array. Once the instance exists, treat the env var as documentation and change the real value with occ inside the container:
docker exec -u www-data nextcloud php occ config:system:set trusted_domains 1 --value=cloud.example.comSwap nextcloud for your container name. The config.php in the mounted volume works just as well if you'd rather edit it directly. My full compose layout for the official image is in the Nextcloud Docker compose guide, including where that volume ends up on the host.
Reverse proxy: the domain is right, the Host header isn't
This is the sneaky variant. You added cloud.example.com to trusted_domains, the browser shows that exact domain and the error persists. What's happening: the proxy rewrites the Host header before forwarding, so Nextcloud sees 127.0.0.1:8080 or the backend's internal name instead of your domain. In nginx that's a missing proxy_set_header Host $host; line. Fix it at the proxy when you can, that's the clean end of the problem.
When you can't (some proxies and tunnel services won't pass the original header), Nextcloud can override what it believes about itself:
'trusted_proxies' => ['10.0.0.2'],
'overwritehost' => 'cloud.example.com',
'overwriteprotocol' => 'https',trusted_proxies lists the proxy's address (CIDR ranges work) so Nextcloud accepts forwarded headers from it, and overwritehost pins the hostname used for generated links. Without overwriteprotocol you'll often trade the untrusted domain screen for redirect loops on HTTPS. The reverse proxy configuration docs cover the remaining knobs (overwritewebroot, overwritecondaddr) for the odd layouts. While you're in the file, 'overwrite.cli.url' => 'https://cloud.example.com' is worth setting too, it keeps the links that cron jobs and notification emails generate pointed at the public name instead of whatever the backend calls itself.
Snap installs keep config.php somewhere else
On the snap, the file lives at /var/snap/nextcloud/current/nextcloud/config/config.php and occ runs as sudo nextcloud.occ config:system:set trusted_domains 1 --value=cloud.example.com. Hunting for config in snap paths is part of why I moved off the snap years ago, the package works, I just never enjoyed how much it hides. If you're on it, everything above applies, only the paths change. The same goes for AIO, which manages trusted domains through its own interface and validates the domain at setup, so this error on AIO usually means the domain check was skipped during install rather than a missing array entry.
Traps that keep the error coming back
When the array looks right and the screen won't go away, it's one of these. First, wildcards: entries like node*.example.com are supported (the sample config ships an example in that shape), but a wildcard matching too little, say *.example.com not covering the bare apex domain, looks like a working config while covering the wrong strings. I list hostnames explicitly, there are rarely more than three. The one setup where a wildcard makes sense is a fleet of numbered nodes sharing a config template, and anyone running that already knew.
Second, the wrong config.php. If you've ever had two installs on one box (an old test copy in /var/www/html/nextcloud, the real one in /var/www/nextcloud), it's very possible to edit one while Apache serves the other. grep -r trusted_domains /var/www settles it in seconds.
Third, DNS that doesn't point where you think. The domain resolves to the old server, which runs an old Nextcloud, which rejects the Host header, and you sit there editing the new server's config wondering why nothing changes. Before a long debugging session I run the hostname through a DNS checker and confirm every resolver already returns the new address, propagation lag has burned me on exactly this error.
Once it works, add every name you'll realistically use in one sitting: the domain, the www variant if you'll redirect it and the IP if you ever administer by IP from a rescue console. Each one is a single array line now and a locked-out evening later. Mine has held the same four entries since spring, which is exactly how often you want to think about this setting.
