The reason why nextcloud is different is that it - unlike most modern webservices - isnât a service itself. It predates modern web technologies, including widespread use of reverse proxies, and as such itâs a pile of PHP.
PHP isnât like other languages. Itâs a templating language, and is usually executed by a webserver on page load to produce the HTML you see. Nextcloud kinda only does half of what normal web services do.
The NixOS module for nextcloud uses nginxâ native php support. In other words, nextcloud itself simply doesnât run on a port; there is only nginx rendering nextcloudâs php templates directly.
This on the other hand is a quirk of nginx and the NixOS module system. If you lack a matching host block, nginx will serve the first host. This apparently happens to be adguard on your system.
Why is there no matching host block? Well, by default the nextcloud module doesnât set a listen. This leads to the nginx module using the defaults here. However, if you do set a listen block, that default is overridden, and the host no longer listens on the default port, so your normal access stops working.
This is what youâre telling nginx to listen on, after all. 127.0.0.1:8185, and you expect that socket to be accessed with the hostname you specify.
I think if you used curl -H 'Host: nextcloud.<domain>.com' http://127.0.0.1:8185 youâd get it to serve nextcloud. Maybe. Depends on how your ssl settings interfere.
From a more meta perspective, php needs to die, and I think nextcloud has passed its best days. Iâm still looking for a service to replace it, might just build my own at this rate.
Edit: Yeah, looking into this again, owncloud (now dubbed âocisâ) might have finally eclipsed the fork, despite the initial community/enterprise schism. It was rewritten from scratch in go. Also seafile is an option. Other alternatives have been sprouting like mushrooms, but they seem to be universally slopgineered one-man-wonder shows.