Need Help: Nextcloud App really slow when accessing via External IP inside LAN

I am having a really hard time with this right now, and could use some help!

I installed the latest NextCloudPi (12_04_17) with all updates. It has NextCloud 12.0.4, and I am accessing everything through the latest iOS App, the latest macOS App and the Web Interface.

Right now, when using the iOS App, what happens is the following:

Access from Inside LAN with Internal IP: works very fast!
Access from Outside LAN with External URL: works very fast!
But access from Inside LAN with External URL: works, but VERY slow, with some timeouts.

Since I want to have access to my files everywhere, I configure the iOS App with the External URL, but this makes the experience miserable when I am home.

Meanwhile, everything seems to work fine when accessing it though the macOS App and the Web Interface via the External URL, even while at home. It syncs reasonably fast and it’s quite responsive (given the low power of the RasberryPi).

I have an ASUS RT-AC68U running MERLIN FW and dnsmasq. When I ping my External URL from inside the LAN, it resolves to my Public IP (not Internal IP). The services I have running in my LAN are very responsive from within the LAN when using the External URL/Public IP, except for NextCloud with the iOS App.

Can anybody help me fix this?

New findings:

When I access NextCloud thourgh the Web Interface from within my LAN using the External URL, the login page shows up really fast. But after authenticating, it’s slow to display the files…

If I am outside my LAN, everything is fast.

I would suspect, that these issues are caused by some routing issues. As your Asus will likely not perform inbound NAT, your NC will actually see the internal IP if your local host and it might not forward the packets to the router again, but transmits it out into the local LAN.

Your client might pick them up, but your router will not know, that your client has already gotton it’s packets and thus might at some time stall new entering packets, or send retries or your NC client will receive duplicate packets.

It’s not easy to tell and a thorough tcpdump would show that.

Nope, I don’t think it’s that.
The NextCloudPi does indeed sends the packets back to the router:

// Login page loads very fast.
// After authentication, some packets are transmitted:
19:31:39.629393 IP > RASPBERRY.https: Flags [P.], seq 1220:1449, ack 147, win 8192, length 229
19:31:39.630971 IP RASPBERRY.https > Flags [P.], seq 147:213, ack 1449, win 254, length 66
19:31:39.633909 IP > RASPBERRY.https: Flags [.], ack 213, win 8189, length 0
19:31:39.634226 IP > RASPBERRY.https: Flags [P.], seq 1449:1487, ack 213, win 8192, length 38
19:31:39.676037 IP RASPBERRY.https > Flags [.], ack 1487, win 254, length 0

// Then it stops here for many seconds.
// After that, there is this burst:

19:32:10.355441 IP RASPBERRY.https > Flags [P.], seq 213:838, ack 1487, win 254, length 625
19:32:10.395212 IP > RASPBERRY.https: Flags [.], ack 838, win 8172, length 0
19:32:10.436329 IP > RASPBERRY.https: Flags [P.], seq 1487:1753, ack 838, win 8192, length 266
19:32:10.436485 IP RASPBERRY.https > Flags [.], ack 1753, win 262, length 0

// Then it stops again for a few seconds more (30 seconds total).
// And finally it unclogs, a lot of packets flow back and forth, and the list of files appear.

19:32:19.148617 IP RASPBERRY.https > Flags [.], seq 838:2298, ack 1753, win 262, length 1460
19:32:19.149134 IP RASPBERRY.https > Flags [.], seq 2298:3758, ack 1753, win 262, length 1460
19:32:19.149456 IP RASPBERRY.https > Flags [.], seq 3758:5218, ack 1753, win 262, length 1460
19:32:19.149767 IP RASPBERRY.https > Flags [P.], seq 5218:5667, ack 1753, win 262, length 449
19:32:19.175957 IP RASPBERRY.https > Flags [P.], seq 5218:5667, ack 1753, win 262, length 449
19:32:19.197287 IP > RASPBERRY.https: Flags [.], ack 3758, win 8100, length 0
19:32:19.197586 IP > RASPBERRY.https: Flags [.], ack 5667, win 8041, length 0

I can try any other ideas!
This is making me crazy.

Can you try the tcpdump on your Mac? I must admit, that the one from the RPi doesn’t show anything particular unusual. So, let’s look at the other end of the connection.

There you go.
In this case, the Mac name is voladeux.

// Login page loads very fast.
// After authentication, some packets are transmitted:
18:34:50.153581 IP voladeux.56620 > Flags [.], ack 204, win 8190, length 0
18:34:50.153982 IP voladeux.56620 > Flags [P.], seq 1189:1227, ack 204, win 8192, length 38
18:34:50.154237 IP > voladeux.56620: Flags [.], ack 412, win 237, length 0
18:34:50.154455 IP > voladeux.56620: Flags [P.], seq 204:242, ack 454, win 237, length 38
18:34:50.154707 IP voladeux.56620 > Flags [.], ack 242, win 8190, length 0
18:34:50.155056 IP > voladeux.56620: Flags [.], ack 1189, win 254, length 0
18:34:50.196561 IP > voladeux.56620: Flags [.], ack 1227, win 254, length 0

// Then it stops here for 30 seconds total.
// And finally it unclogs, a lot of packets flow back and forth, and the list of files appear.

18:35:20.929884 IP > voladeux.56620: Flags [P.], seq 242:864, ack 1227, win 254, length 622
18:35:20.929994 IP voladeux.56620 > Flags [.], ack 864, win 8172, length 0
18:35:20.945447 IP voladeux.56620 > Flags [P.], seq 1227:1513, ack 864, win 8192, length 286
18:35:20.947597 IP > voladeux.56620: Flags [.], ack 1513, win 262, length 0
18:35:21.544336 IP > voladeux.56620: Flags [.], seq 864:2324, ack 1513, win 262, length 1460
18:35:21.544346 IP > voladeux.56620: Flags [.], seq 2324:3784, ack 1513, win 262, length 1460
18:35:21.544348 IP > voladeux.56620: Flags [.], seq 3784:5244, ack 1513, win 262, length 1460
18:35:21.544350 IP > voladeux.56620: Flags [P.], seq 5244:5700, ack 1513, win 262, length 456
18:35:21.544352 IP > voladeux.56620: Flags [P.], seq 5244:5700, ack 1513, win 262, length 456
18:35:21.544499 IP voladeux.56620 > Flags [.], ack 3784, win 8100, length 0

Just keep in mind that this only happens when I am inside my LAN and use the external IP.
Using the internal IP, or the external IP while outside my LAN, works fine.
This 30 second pause feels like a timeout of some sort.

Not a MAC expert. And definitely not an NextCloud expert…


This screams DNS to me. If you are using the external address and you do not have a record on your local DNS server to direct that traffic to the internal server you will be using your full upload to re-download … hence slow.

I had a similar issue on my first ownCloud server. I went into DNS and set an A record to point the web traffic back to the internal IP. it was night and day.

Not sure how to do this in a MAC short of Googling how to set something in a HOST file.

let me know if this was of any help :):worried:

if you have $20 to spare you can download an install OS Server app on Mac OS from the App Store.

It comes with a DNS and DHCP server. You can then control the host names on your network.

Yes, a full-fledged internal DNS would help, but remember, that it would have to be aligned with the external “hostname”. So, you would basically match your external DNS - should you happen to have one, with your internal network.

Regarding the DNS server, you could run that on the Pi, I guess, since out would need to be running at 24/7. You simply don’t want to setup or or anyone of those on your LAN.


I was in the same case, and I found this post and now my NC app work correctly.After update to v12 logon is very slow (only lan).

In resume you need to clean the bruteforce table entries who containe you internal network ip.