[solved] Nextcloud Desktop Client 2.5.2 Login Loop fails with Nextcloud 16.0.1 works with Nextcloud 15


#!/bin/hi *

I’m using Nextcloud on two different servers. The client OS is kubuntu 19.04. The desktop client works perfectly on the connection to the Nextcloud 15 server. Yet, the very same client runs into a “Log in -> Grant Access -> Log in -> Grant Access -> Log in …” Loop against a Nextcloud 16 server.

The Nextcloud 16 server runs fine, i.e. Web Access via https is fluent. It’s just the desktop client fails to overcome the login procedure.

I tried with an application token too, but this totally break the login GUI of the desktop client. All turns to the Window background color and with just 3 widgets somewhere without any text nor image.

I cannot downgrade the server to be 15 again. What should I do?



I just found some strange message in the log flow:

unknown Mixed Content: The page at 'https://NEXTCLOUDSERVER/index.php/login/flow' was loaded over a secure connection, but contains a form that targets an insecure endpoint 'http://NEXTCLOUDSERVER/index.php/login/flow/apptoken'. This endpoint should be made available over a secure connection.

Well, the nextcloud server is of course behind a reverse proxy which is the TLS endpoint (precisely it’s a caddy Webserver). And inside a docker container. So the Nextcloud Server thinks, it runs on a http:// which is not true (well, to some point at least), yet the account registration does somehow feel annoyed by it.

Could this be the reason? Can a nextcloud server not run behind a reverse proxy?



I ve just updated to desktop 2.5.2 and test stuff not being able to reproduce, but i am using apache2

Unfortunately, i am not using nginx ( caddy is based on nginx, right ?? ).
Having a reverse proxy shouldnt be a problem.
You may need to check the proxy_passe conf…
I know nginx may need upstream ssl to work properly as a tls endpoint in reverse proxy …


check on the caddy forum:



@Caddy: no, this is a full new slick webserver with security in mind written in Go with out-of-the box https (based on letsencrypt) and easy to use reverse proxy settup for docker container services. (I know apache and nginx, but this one is just … uhm … to easy to setup to ignore: https://caddyserver.com) It need’s just 2 lines.

However, I strongle feel its on the nextcloud sever side and precisely this setup , since the desktop client runs smoothly with another connection to a nextcloud 15 server.


Thx for the link, I know. But the caddy server is just passing by the http request. However, it’s the TLS endpoint and the nextcloud server runs inside a docker container, without any clue of the HTTPS or HSTS for that matter.

Currently I’m scanning the server sources, and I know that the return URL for this action is in the nextcloud server in lib/private/Server.php which provides a function as getRequest() which in turn asks a ServerContainer->query(“request”). I’m not that fit in PHP, but it seems to me, that this constructs the request URL in a bad way. It obviously does not reflect the URL, which is specified in the config/config.php on the server but tries to extract its own value from the HTTP-Request.

… which is wrong.

But, again, I’m not that fit in PHP to swear on the bible about this hypthesis.


Yep, i have just visited the caddy stuff … the go by google !!! Nop for me !!!

Exactly the kind of stuff i hate ! The two lines easy configuration miracles, witch end up creating more troubles for the admin when it fails !!! :skull_and_crossbones:


Hehehehe … well, I give you that. But for the mere act of being a simple reverse proxy with out-of-the-box certificates for HTTPS it’s perfect.

Even if this one has been created by the Dark Side, in this particular incident I do not judge it automatically guilt for been a Google offspring.

… it could be though… But truly believe it’s currently somewhere in the guts of Nextcloud Server 16.


I wind up in the lib/private/AppFramework/Utility/SimpleContainer.php, which does a new ReflectionClass("Request") instantiate it and does a getRemoteAddress() on it. Totally ignoring the service URL of the nextcloud in theconfig/config.php.

Since this is run behind a reverse proxy, which changes the HTTP Header, this is a server bug on the Nextcloud side, for it cannot deduce by this method the full real URL used outside and beyond the reverse proxy.

Still, this must happen to any http instance running behind a reverse proxy. Be it Apache, nginx or Caddy… hmm, I feel somehow lost.

Could anyone from the Server department have a look at this and correct me, if I’m wrong? Thx.


you should open a bug on github.


I quickly browsed around the server bugs on GitHub. There are around 2000 open one and a lot of people do have severe problems with Nextcloud 16 it seems.

I’ll open up a bug report, but I do not think, that the Devs do have any time left, since it feels to me, that my situation is rather exotic (Caddy Server, Docker, Linux clients). I assume, that’s not the typical configuration of the most customers.

Also, people are still quite nice, but the plethora of bug issues over there is quite astonishing.



Ha! And then I found https://github.com/nextcloud/server/issues/13431#issuecomment-456453585, hammered into my config/config.php and on the login of the desktop client I did not just type “NEXTCLOUD.tld.some” but “https://NEXTCLOUD.tld.some” and both changes make it work again!

So: solved!