You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I am on my local LAN, I of course can't access cloud.mydomain.com over IPv4. Because of NAT, A record for cloud.mydomain.com is the IPv4 of my Firewall and not of my Nextcloud instance.
So it will go to my Firewall instead of my Nextcloud instance, where of course the cert isn't valid because of the wrong domain name.
I can access cloud.mydomain.com over IPv6.
When I insert cloud.mydomain.com in my browser, it will do happy eyeballs and reach my Nextcloud instance always over IPv6.
I can easily solve that issue by creating an unbound override rule, so that the DNS returns the Nextcloud IPv4 instead of my WAN IPv4, when clients ask for cloud.mydomain.com. That way IPv4 traffic flows to the right host.
You could also solve this by using Hairpin NAT.
But not everybody has the option to do DNS overrides or Hairpin NAT. Especially consumer routers are sometimes pretty limited.
Now, to the actual issue this bug report is about:
So for the browser itself, this isn't an issue. Thanks to happy eyeballing, all browsers will always use the AAAA record instead of the A record. But this does not seem to be true for Nextcloud on macOS after waking up from standby.
There will be a popup that warns out about the cert error.
I can close this popup, the Nextcloud icon will be grey, and then a few seconds later will turn green again because it is using IPv6.
I don't know what is causing this. It happens every time I wake up from standby. Maybe macOS is faster getting IPv4 ready? Maybe the client app isn't doing happy eyeballs all the time?
Uh oh!
There was an error while loading. Please reload this page.
Bug description
I have a dual-stack working Nextcloud instance.
When I am on my local LAN, I of course can't access cloud.mydomain.com over IPv4. Because of NAT, A record for cloud.mydomain.com is the IPv4 of my Firewall and not of my Nextcloud instance.
So it will go to my Firewall instead of my Nextcloud instance, where of course the cert isn't valid because of the wrong domain name.
I can access cloud.mydomain.com over IPv6.
When I insert cloud.mydomain.com in my browser, it will do happy eyeballs and reach my Nextcloud instance always over IPv6.
I can easily solve that issue by creating an unbound override rule, so that the DNS returns the Nextcloud IPv4 instead of my WAN IPv4, when clients ask for cloud.mydomain.com. That way IPv4 traffic flows to the right host.
You could also solve this by using Hairpin NAT.
But not everybody has the option to do DNS overrides or Hairpin NAT. Especially consumer routers are sometimes pretty limited.
Now, to the actual issue this bug report is about:
So for the browser itself, this isn't an issue. Thanks to happy eyeballing, all browsers will always use the AAAA record instead of the A record. But this does not seem to be true for Nextcloud on macOS after waking up from standby.
There will be a popup that warns out about the cert error.
I can close this popup, the Nextcloud icon will be grey, and then a few seconds later will turn green again because it is using IPv6.
I don't know what is causing this. It happens every time I wake up from standby. Maybe macOS is faster getting IPv4 ready? Maybe the client app isn't doing happy eyeballs all the time?
20250523_1341_nextcloud.log
Steps to reproduce
Expected behavior
Which files are affected by this bug
20250523_1341_nextcloud.log
Operating system
macOS
Which version of the operating system you are running.
15.5
Package
Official macOS 12+ universal pkg
Nextcloud Server version
31.0.5
Nextcloud Desktop Client version
3.16.4
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.4.2 to 3.4.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
The text was updated successfully, but these errors were encountered: