Why Nextcloud Is So Strict About HTTPS

Nextcloud treats the connection scheme as a first-class part of its identity. Unlike a simple blog that renders whatever URL it receives, Nextcloud builds absolute URLs for its WebDAV endpoints, share links, mobile sync clients, and federated connections. If the application decides it is running under http:// when the browser actually loaded https://, every generated link becomes wrong, the desktop and mobile clients refuse to connect, and the admin dashboard fills with security warnings. This is the source of the two most common complaints on shared hosting: an endless redirect loop after enabling SSL, and the "Accessing site insecurely" banner even though the padlock is green in the address bar.

The confusion almost always comes down to how the request reaches PHP. On the Hostiso stack, LiteSpeed Web Server terminates the TLS connection at the edge and then hands the request to your PHP worker. The PHP process frequently sees a plain internal request and relies on forwarding headers such as X-Forwarded-Proto to know that the visitor originally arrived over HTTPS. Nextcloud will not trust those headers unless you explicitly tell it which proxy to trust and which protocol to assume. When that trust is missing, Nextcloud's own logic and your redirect rules fight each other, and the browser bounces between schemes until it gives up.

Everything described here is done as a normal hosting user. You will work inside cPanel Jupiter or DirectAdmin Evolution, edit two files with File Manager (config.php and .htaccess), and read the application log. No root, SSH administration, or server-wide changes are needed or permitted, and none of these fixes require touching the web server configuration directly.

Step One: Issue a Valid Certificate and Confirm It

Before adjusting any Nextcloud setting, make sure a real certificate covers the exact hostname you use. A mismatched or missing certificate causes the sync clients to reject the server outright, and no amount of config editing fixes an untrusted chain.

In cPanel Jupiter, open Security » SSL/TLS Status. Every domain and subdomain is listed with its certificate state. Select the hostname that serves Nextcloud (for example cloud.example.com) and click Run AutoSSL. AutoSSL provisions a free Let's Encrypt-style certificate and installs it automatically, usually within a minute or two. If the domain shows a broken padlock afterward, confirm the DNS A record points to your Hostiso account and that no stale AAAA record sends IPv6 traffic elsewhere.

In DirectAdmin Evolution, the path is Account Manager » SSL Certificates. Choose Free & automatic certificate from ACME Provider (Let's Encrypt), tick both the bare domain and the www or subdomain entries you actually serve, then save. DirectAdmin also exposes a Force SSL with https redirect checkbox on that same screen; leave it unchecked for now, because you will control redirects inside Nextcloud's own .htaccess to avoid duplicate rules stacking on top of each other.

Verify the result by loading the site over https:// and clicking the padlock. The certificate common name must match the hostname Nextcloud is installed under. If you access Nextcloud through a subfolder or a different subdomain than the certificate covers, the clients will complain regardless of what config.php says.

Step Two: Set the Overwrite Parameters in config.php

The heart of Nextcloud HTTPS behavior lives in config/config.php, located inside your installation root (commonly /home/USERNAME/public_html/config/config.php or a subdirectory if you installed into a folder). Open it with cPanel File Manager or DirectAdmin File Manager, choose Edit, and take a backup copy first by using Copy to save config.php.bak in the same folder.

Add or adjust the following keys inside the existing $CONFIG = array( ... ); block. Do not create a second array; place these lines among the existing entries, each ending with a comma:

'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://cloud.example.com',
'overwritehost' => 'cloud.example.com',
'trusted_domains' =>
  array (
    0 => 'cloud.example.com',
  ),

The overwriteprotocol value forces Nextcloud to build every internal URL with https://, which directly kills mixed-content warnings caused by assets requested over plain HTTP. The overwrite.cli.url defines the canonical address used for background jobs and generated links, and overwritehost pins the hostname so proxied requests do not confuse the router. The trusted_domains array must contain the hostname you type in the browser; if it is missing, Nextcloud returns an "Access through untrusted domain" error instead of loading.

Because Nextcloud caches configuration, changes take effect on the next request. If the site does not reflect them, confirm the file still parses as valid PHP. A stray missing comma or unescaped quote will produce a white screen; check data/nextcloud.log or the account's error_log in the site root to catch a parse error before it becomes a mystery.

Step Three: Redirects, Trusted Proxies, and Clearing Mixed Content

With the certificate valid and config.php aligned, force every visitor onto HTTPS at the entry point. Edit the .htaccess file in your Nextcloud root and place this block near the top, above the long <IfModule mod_rewrite.c> section that Nextcloud generates automatically. Do not delete Nextcloud's own rules; only prepend your redirect:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

On LiteSpeed the %{HTTPS} variable reflects the terminated connection correctly, so this rule redirects HTTP to HTTPS without looping. If you previously enabled a redirect toggle in the control panel, remove it now, because two competing 301 rules are a classic cause of the "too many redirects" error.

Next, address proxy awareness. Because TLS is handled at the LiteSpeed edge, Nextcloud needs to trust the forwarded protocol header to avoid downgrading generated links. Add a trusted_proxies entry to config.php using your server's shared loopback or front-end address. On most shared setups the forwarding originates locally, so start with the loopback range and confirm against the actual value logged under Settings » Administration » Overview:

'trusted_proxies' =>
  array (
    0 => '127.0.0.1',
  ),
'forwarded_for_headers' =>
  array (
    0 => 'HTTP_X_FORWARDED_FOR',
  ),

If the admin overview still reports HTTP after this, it usually means overwriteprotocol was not saved correctly rather than a proxy problem; the overwrite key is the reliable lever on shared hosting where you cannot alter server-level header forwarding.

Mixed-content warnings that survive all of the above generally come from content stored inside Nextcloud itself, such as an external site link in Collabora, a theming logo uploaded over HTTP, or a hardcoded http:// in a custom theme. Open Settings » Administration » Theming and re-upload any logo or background so the stored URL regenerates as HTTPS. For persistent asset warnings, add a header that upgrades insecure requests. Because your PHP handler runs under a .user.ini-driven environment, apply this through .htaccess rather than editing PHP settings:

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

Test each change from a private browser window to bypass cached redirects, and re-run the security checks under Settings » Administration » Overview, which flags scheme and header issues in plain language. The same discipline of matching certificate, canonical URL, and forwarded protocol applies across most PHP applications; if you also manage a storefront, the PrestaShop SSL and HTTPS guide covers the equivalent redirect and proxy detection patterns. Once the overview page reports no warnings and your desktop client reconnects cleanly, the HTTPS chain is fully consistent from browser to sync endpoint.