in general it is always better you start your own thread and describe your setup, the problem, what you tried so far…
the overwriteprotocol setting itself doesn’t change anything, it explicitly expected to make Nextcloud behave different. In this case you can access NC with plain http:// but it make all URL look like https://. the reason is majority of the users don’t want to use TLS behind reverse proxy - terminating TLS on your entry point (=reverse proxy) simplifies the setup - you only need to manage the complexity of certificate requests, issuing and configuring once and don’t need to replicate it to different endpoints like collabora, NC, another webservice (especially in case of docker and VMs on same physical server there is no security issues related to such setup).
Thank you for the explanation. Also good to see there are no security issues involved (the entire setup including docker is indeed running on the same physical server). That is also what I gathered so far, but it’s still nice to hear it confirmed. The reason I started tinkering with this (again) was the __Host-Prefix message of Nextcloud’s security scan, which is also why I wrote in this existing thread. Maybe I should have made that clear.
I guess I will leave my setup as it is since, from what I understand, this __Host-Prefix message does not seem to be that important. If you tell me I’m wrong about this, I’m happy to keep tinkering.
I access it via mycloud.mydomain.tld instead of mydomain.tld which, according to some of the messages above, seems to be the reason for the security warning. But, as also mentioned above I believe, this is the recommended setup and arguably also the safer setup. Anyway, I’m no security expert. I’ve just tried to read up on this and this is what I found out.
overwriteprotocol fixed it for me. Actually, it fixed the rating and “You are accessing your instance over a secure connection, however your instance is generating insecure URLs.”