From 7701c1756ccf625df1cde51beb415f9500aa4406 Mon Sep 17 00:00:00 2001 From: skjnldsv Date: Thu, 21 May 2026 11:23:08 +0200 Subject: [PATCH] docs(admin): document share link URL behaviour with multiple trusted domains When multiple trusted_domains are configured, generated URLs (share links, download links, notifications) use the hostname from the incoming request. This is a common source of confusion for admins running split-horizon DNS or dual internal/external access, as share links created internally contain the internal hostname and break for external users. Add a new subsection to reverse_proxy_configuration.rst explaining the behaviour and showing how to force a canonical hostname via overwritehost and overwrite.cli.url. Fixes #11623 Signed-off-by: skjnldsv --- .../reverse_proxy_configuration.rst | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/admin_manual/configuration_server/reverse_proxy_configuration.rst b/admin_manual/configuration_server/reverse_proxy_configuration.rst index c5b60536a5e..1891faa7daf 100644 --- a/admin_manual/configuration_server/reverse_proxy_configuration.rst +++ b/admin_manual/configuration_server/reverse_proxy_configuration.rst @@ -217,3 +217,34 @@ come from the proxy at **10.0.0.1**, which serves Nextcloud as the remote address matches. This is useful when the same Nextcloud instance is accessible both with and without a reverse proxy, or when different proxies serve the instance under different hostnames. + +Multiple trusted domains and share link URLs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When multiple entries are listed in ``trusted_domains``, Nextcloud accepts +requests on all of them but generates URLs based on the hostname of each +incoming request. This means share links, download URLs, and notification +links will reflect whichever hostname was used at the time they were created. + +A share link created while accessing Nextcloud via an internal hostname +(e.g. ``cloud.local``) will contain that hostname and will not be reachable +by users on a different network who only have access to the public hostname +(e.g. ``cloud.example.com``). + +To ensure all generated URLs always use a single canonical hostname, set +``overwritehost`` and ``overwrite.cli.url`` unconditionally: + +:: + + ['cloud.local', 'cloud.example.com'], + 'overwritehost' => 'cloud.example.com', + 'overwriteprotocol' => 'https', + 'overwrite.cli.url' => 'https://cloud.example.com', + ); + +.. note:: Unlike the ``overwritecondaddr`` pattern above, this applies the + overwrite to every request regardless of origin. Use this when you want + one authoritative public URL for all generated links, even when the instance + is also reachable internally under a different hostname.