Android Client not able to connect to private Nextcloud with local DNS resolver, other Apps (FolderSync) can connect just fine


I am using the latest NC Server (23.0.0, manually installed on Ubuntu 20.04.3 LTS using Apache as webserver) and Android Client (3.18.1).
My setup may be more on the non-standard side so here a quick tour about how it works and where the problem is:
My Nextcloud server is living in my basement and my network is configured to get http/s traffic routed to the server. I can access it from outside because I registered a DynDNS domain.
If i access this domain from local network the requests are send to the OUTSIDE IP of my router, crippling my bandwith from GigaBit to 50MBit.
To resolve this I made my server play DNS resolver himself, resolving the DynDNS domain to his internal IP and give everything else to Quad9.
After publishing the server as DNS resolver to the internal networks it works like a charm, only one problem remains:
The Nextcloud client for Android does not want to connect after the change, “server not available”.
It is available on the same device from the outside though (e.g. i disconnect WiFi and connect over LTE). On the other hand other apps on the same device (OpenSync, FolderSync) can connect just fine, and work better than before due to faster Network speed. I could only find this problem on the Nextcloud client.
After some time (some looooong time) troubleshooting i found the problem:
For DNS Resolving I installed dnsmasq and put the corresponding entrys into /etc/hosts:

This also is published (correctly) so nslookup on the network returns:

Non-authoritative answer:
Address: 192.168.X.X

The additional 127.X IPs were there because that was done in the tutorial when I first installed NextCloud years ago (I think it still were “OwnCloud” times), and i always kept it.
I could believe that the server himself can use that to route possible system-internal traffic without going on the wire, I am not sure if this is actually needed or in fact helping in any way.

However, if I remove those 127.X IPs and restart the DNS service, the Nextcloud client app directly connects without a problem.
NOTE: the default 127.X entrys should remain untouched, I am talking about additional entries I made because of a tutorial. So if i comment out the additional entries it looks sth. like this:

$ cat /etc/hosts localhost servername
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
# my own custom entries

I made this post so that others struggling with this issue, as hosting@home is a pretty good usecase, but crippling speeds for effectively internal communication is bad.
But also because I wanted to ask two remaining questions:

  • did those 127.X entrys in /etc/hosts serve a real purpose that will bite me later? (for now all seems to work)
  • can the client app be tweaked to ignore 127.X IPs when they are returned from DNS? My network knowledge is limited but 127 IPs are reserved for on-device usage afaik. Or maybe try ALL IPs that are returned instead of just one?



The ip address is by default the localhost ip address (loopback address). If your server tries to connect to “localhost”, e.g. to reach a locally installed database etc., it uses this address. If you add other names to point to a 127.x address these addresses aren’t resolved by an external dns. This allows you to block communication to these hosts. By default only one line should exist in /etc/hosts which is “ localhost”, not more.

Thanks for the response @j-ed, it made me aware that I should have specified that I was NOT talking about the default localhost entry but about additional ones. I have clarified that in my original post now so future readers do not accidentially break their systems.

If i understand correctly your description matches my my basic understanding of how the localhost communication works.
In general i would think that those additional lines are not needed since I see no reason that Nextcloud would adress the system it is build upon with anything other than directly.
But I did not make those entries up, they were in a guide and probably for a reason, then again this was about 10 years ago, so that might have changed :slight_smile:

1 Like