docs: clarify htaccess.RewriteBase is a backend path, not public URL

The previous description implied the value should mirror the public URL,
causing users behind a reverse proxy to misconfigure the setting and hit
infinite redirect loops. The value is an Apache RewriteBase directive
and must reflect where Nextcloud is served on the backend (relative to
DocumentRoot), not the public-facing URL prefix.

Split into "Direct setup" and "Reverse proxy" sections with a concrete
example of each, and added a matching note in the Pretty URLs section of
the source installation guide.

Fixes #13428

Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>

Author: skjnldsv

admin_manual/configuration_server/config_sample_php_parameters.rst

@@ -1352,19 +1352,28 @@ htaccess.RewriteBase
 
 To have clean URLs without ``/index.php``, this parameter needs to be configured.
 
-This parameter will be written as "RewriteBase" on update and installation of
-Nextcloud to your ``.htaccess`` file. While this value is often simply the URL
-path of the Nextcloud installation, it cannot be set automatically properly in
-every scenario and needs thus some manual configuration.
-
-In a standard Apache setup, this usually equals the folder that Nextcloud is
-accessible at. So if Nextcloud is accessible via ``https://mycloud.org/nextcloud``,
-the correct value would most likely be ``/nextcloud``. If Nextcloud is running
-under ``https://mycloud.org/``, then it would be ``/``.
-
-Note that the above rule is not valid in every case, as there are some rare setup
-cases where this may not apply. However, to avoid any update problems, this
-configuration value is explicitly opt-in.
+This parameter will be written as ``RewriteBase`` on update and installation of
+Nextcloud into your ``.htaccess`` file. The value must be the path relative to
+Apache's DocumentRoot where Nextcloud is served on the backend, not necessarily
+the public URL prefix. In most direct (non-proxied) setups these are the same,
+but they differ when a reverse proxy rewrites the URL path.
+
+**Direct Apache setup (no reverse proxy)**
+
+The URL subpath matches the DocumentRoot-relative path, so use the URL subpath:
+
+- Nextcloud at ``https://mycloud.org/nextcloud`` → ``/nextcloud``
+- Nextcloud at ``https://mycloud.org/`` → ``/``
+
+**Reverse proxy setup**
+
+Use the path where Apache physically serves Nextcloud on the backend server,
+not the public URL prefix. For example, if a reverse proxy forwards
+``https://domain.com/nextcloud/`` to ``http://localhost:8080/`` and Nextcloud
+is installed at the Apache DocumentRoot on the backend server, the correct
+value is ``/``, not ``/nextcloud``.
+
+However, to avoid update problems, this configuration value is explicitly opt-in.
 
 After setting this value, run ``occ maintenance:update:htaccess``. Now, when the
 following conditions are met, Nextcloud URLs won't contain ``index.php``:

admin_manual/installation/source_installation.rst

@@ -191,8 +191,18 @@ if your setup is available on ``https://example.org/nextcloud`` or::
     'overwrite.cli.url' => 'https://example.org/',
     'htaccess.RewriteBase' => '/',
 
-if it isn't installed in a subfolder. Finally run this occ-command to update
-your .htaccess file::
+if it isn't installed in a subfolder.
+
+.. note::
+
+   ``htaccess.RewriteBase`` must match the path relative to Apache's DocumentRoot
+   where Nextcloud is served on the backend, not the public URL prefix. In a direct
+   Apache setup these are identical. Behind a reverse proxy that strips the URL
+   prefix — for example ``https://domain.com/nextcloud/`` forwarded to
+   ``http://localhost:8080/`` — the correct value is ``/`` even though the public
+   URL contains ``/nextcloud``.
+
+Finally run this occ-command to update your ``.htaccess`` file::
 
     sudo -E -u www-data php /var/www/nextcloud/occ maintenance:update:htaccess