Fixing "mixed content" errors when using a proxy

If you’ve setup Nextcloud to sit behind a proxy, you may encounter the following errors and find not all content loads correctly:

Content Security Policy: The page’s settings blocked the loading of a resource at http://cloud.myserver.com/core/img/background.jpg?v=20 (“img-src https://cloud.myserver.com data: blob:”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://cloud.myserver.com/core/img/logo.svg?v=20 (“img-src https://cloud.myserver.com data: blob:”).

Normally this means the proxy is configured for SSL but proxies to Nextcloud over HTTP rather than HTTPS, like this:

ProxyPass / http://192.10.110.24/
ProxyPassReverse / http://192.10.110.24/

Or, in NGINX, like this:

proxy_pass http://192.10.110.24;

This configuration will terminal SSL on the proxy and have the proxy communicate with Nextcloud over HTTP. Since Nextcloud won’t be configured to respond over HTTPS, all internal requests for content (like stylesheets, images, etc) will also be made over HTTP, resulting in mixed content warnings.

In order to resolve this, make the following changes to your Nextcloud config.php:

'overwrite.cli.url' => 'https://cloud.myserver.com',
'overwriteprotocol' => 'https',

Nextcloud will then ensure all requests are made and returned over https:// rather than http://, mitigating the mixed-content errors.

Note: Be aware, if you access internally via IP over HTTP, this will either a) give you SSL errors or b) not work at all - 443 is not configured by default, so it may refuse to connect when it forces, due to that setting, the connection from http:// to https://

Hope that helps!

3 Likes

Hi @JasonBayton,

That’s similar to something I found out today. It finally made my NC Android client be able to register while being in LAN.

My full new entries:

 'trusted_proxies' =>
  array (
    0 => '555.555.555.555',
  ),
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => 'https://nc.domain.tld',
  'overwritecondaddr' => '^555\\.555\\.555\\.555$',

With “555” being the reverse proxy’s ip.

1 Like

Are you one of those who can’t resolve internal services when connecting to the external URL from inside the LAN? Normally not a problem but that’s definitely an option in that scenario. Equally an option if you have internal DNS is to simply override the URL externally with a local IP (of the proxy); no NC configuration required then :thumbsup:

Well, I do have an internal DNS resolving my external domain to the internal ip since ever, but that wasn’t enough :wink:

Maybe through the additionally enabled ‘overwrite.cli.url’ entry it will help me to finally being able to upgrade to 12.0.X (from 11.0.3). Calendar wasn’t loading after my last 4 attempts…

Btw, really nice to proactively post such infos - thanks.

1 Like

Oh sorry, I didn’t realise you didn’t have the overwrite url option in place! Glad it’s resolved in any case :slight_smile:

1 Like

For the android client it already worked without ‘overwrite.cli.url’. That’s what I needed (I guess the trusted_proxy was relevant, not sure):

But now I’m hoping overwriting cli as well will help for my next upgrade attempt - fingers crossed @JasonBayton , that would be great and a large glass of /insert your favourite drink here/ for you

1 Like

I have a NextCloud installation serving http sitting behind an NGINX reverse proxy handling https and I am experiencing the same conditions.

When it try to implement the overwriteprotocol example given above I get a 500 error. Any ideas on how to correct this?

Thank you.

Ok, I got overwriteprotocol working without the 500 error. I made a typo.:smirk:

Unfortunately, that did not resolve the original issue. I am still missing the background image and some of the favicons.

I got the issue resolved. For some reason adding includSubDomains to the Strict-Transport-Security line in my virtual host resolved the issue.

Sorry for the delay in responding chap, but pleased to see it’s fixed :slight_smile:

In my case I had to uninstall the First Run Wizard app to finally get this to go away. Running Nextcloud on Kubernetes exposed via a virtual load balancer on port 80 with NGINX in front terminating SSL.