Well you are really confusing me (and most likely also @trilbytim) with the yellow marked. Okay it is not specifically FreeDNS needen but some DynDNS is needed, except a static IPv4 or IPv6 will be used.
Sorry, I thought, that it is a service on a computer in your network.
If you use a DynDNS service, your router must tell to the FreeDNS-service, to determine its current IP-address(es). There are credentials needed, you will need to place them in the router.
So, please input the DynDNS data and credentials in the router, that FreeDNS knows the roiuter-IP. Only then you are able to call your network from outside, if port-forwardings are set and addressed to yor Nextcloud instance.
Finally, if you do a
ping your.nextcloud.domain
the answer should contain your router’s external IP-address.
Unfortunately although my router seems to support a fairly long list of DNS providers, FreeDNS is not one of them! 
No-IP is listed in my router set up and on the Nextcloudpi panel though, so I set up a new (free) domain name with them. I pointed my router DynDNS settings to the NO IP account. However when I run the NO-IP activation on my Nextcloudpi panel I get a load of errors shown below, although it says at the end “noip DDNS enabled”, if I go to the noip domain name I just get the login screen for my router. I do have port forwarding set correctly to point to the RPi
[ no-ip ] (Tue Dec 16 14:07:35 UTC 2025)
Auto configuration for Linux client of no-ip.com.
Only one host [all.ddnskey.com] is registered to this account.
It will be used.
New configuration file '/usr/local/etc/no-ip2.conf' created.
Failed to enable unit, unit /run/systemd/generator.late/noip2.service is transient or generated.
Cannot load Zend OPcache - it was already loaded
Cannot load Zend OPcache - it was already loaded
System config value trusted_domains => 3 set to string xxx.myddns.me
Cannot load Zend OPcache - it was already loaded
System config value overwrite.cli.url set to string https://xxx.myddns.me/
Cannot load Zend OPcache - it was already loaded
Cannot load Zend OPcache - it was already loaded
System config value trusted_proxies => 11 set to string 127.0.0.1
Cannot load Zend OPcache - it was already loaded
System config value trusted_proxies => 12 set to string ::1
Cannot load Zend OPcache - it was already loaded
System config value trusted_proxies => 14 set to string 192.168.1.157
Setup notify_push (attempt 1/5)
Cannot load Zend OPcache - it was already loaded
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
✓ push server is a trusted proxy
✓ push server is running the same version as the app
configuration saved
noip DDNS enabled
Please check, whether remote management to the router from outside is enabled and deactivate it
I haven’t necessarily read everything you’ve already written, and I don’t know which country you’re from, so there might be differences between providers. Therefore, just to illustrate and perhaps offer a troubleshooting tip, here’s a real-life example I recently encountered.
In this case, the internet connection uses a DS-Lite connection. The connection has both an IPv4 and an IPv6 address. However, the IPv4 address is not readily accessible, as this requires an additional subscription with the provider, which the customer does not want. Therefore, the connection must be established via the IPv6 address, which is static.
It’s important to note that the IPv6 prefix, the first fixed part, is generated by your router, in this case, a Fritz!Box. Since the server, and consequently its services that need to be accessible, are located behind the Fritz!Box, the Fritz!Box assigns an IPv6 address derived from the first part of the prefix and the second part of the DHCP address. Thus, each device receives its own unique IPv6 address. And it’s this address that I need to be able to access, not the Fritz!Box’s address itself.
I use ddnss.de as my dynamic DNS (DynDNS) service. This service is connected to my Fritz!Box as a DynDNS provider. However, I only check the connection via IPv4. If I were to do this via IPv6 as well, I would always end up on the router, which I don’t want. The DynDNS service is only there to assign a web address to my internet connection. You can find out how this connection is established and what the query looks like from your internet service provider. In most cases, this is set to “user-defined”/”custom”.
To route the web server via IPv6 through the Fritz!Box or router, I assigned the web server a static IPv4 address and the generated IPv6 address as permanent and always valid. This means that both addresses are still valid after a restart.
You now need to copy the IPv6 address specified in your router. In the DynDNS service settings, you must enable the DS (Dual Stack) option. This tells the service to check and use both IPv6 and IPv4 addresses. Then, paste the IPv6 address of your web server here – in your case, the address of your Raspberry Pi. This way, communication and connection between your router/internet connection and the DynDNS service will be maintained via IPv4, but the IPv6 address will point to the device that actually provides the web service. Of course, you also need to open the corresponding ports in your router for this device, otherwise all requests will be routed through the router. Because of this configuration, your IPv4 address will change after each new connection attempt by your router, but the IPv6 address will remain the same.
This circumvents the problem that IPv4 can be translated into web names, i.e., addresses, but IPv6 cannot. This task is handled by the DynDNS service. It also avoids the problem that with an older IPv4 connection, you could communicate using the IPv4 address. With an IPv6 connection, this is not possible; it is blocked by your provider. You will see an IPv4 address, but it only exists hypothetically and is not reachable from the outside. However, it can make outgoing calls and thus be used to establish such a connection.
For example, when you visit a website like www.strato.de, a DNS service is running on that server. This service internally manages the communication between IPv4 and IPv6 addresses, as well as the corresponding web address. The DynDNS service handles this process for you. However, you need to provide it with a slightly more complex explanation of how to reach you (this is done via IPv4 and the DynDNS web address/host domain that you create) and the IPv6 address of your web server/Raspberry Pi (which you configure manually and statically).
If you want to access multiple services, the IPv6 address must point to your reverse proxy, e.g., NGINX REVERSE PROXY. This then forwards the traffic internally via IPv4 and ports to the appropriate devices.
If I have some time, I’ll take a picture; that explains it a bit more concisely than a long, drawn-out explanation. Sorry 
From a global perspective, DS-Lite is used relatively infrequently. CG-NAT is much more widespread. However, the problems with CG-NAT are the same as with DS-Lite.
But you (@ThomasG8235) raise an important point. Anyone who has problems accessing their NC server from the WAN should check what type of Internet connection they have before submitting a support request here. That could be:
- Dual Stack
- CG-NAT
- DS-Lite but also
- Single Stack (IPv4 only)
Only with this knowledge can reasonable support be provided.
Note: It is relatively easy to check whether someone has CGNAT. In most cases, your ISP will have assigned your router’s WAN interface an IPv4 address from the 100.64.0.0/10 range. This is a special-use IPv4 block reserved for Carrier-Grade Network Address Translation (CG-NAT).
@adelaar ja global betrachtet ist es wirklich eher selten. Aber in Deutschland fast normal, jedenfalls bei uns im Norden. Und da fast alle hier immer auf Englisch schreiben, aber nicht sagen wo sie herkommen, und auch nicht was für einen Anschluss sie haben, macht es so schwierig. Und da dachte ich ich versuche mal die Erklärung anhand eines Beispiels und halbwegs simpler Worte. Ich weiß, daß die technischen Erklärungen bei nicht so technisch versierten Menschen oft zu mehr Fragezeichen als Verständnis führen.
Well, those two can’t really be separated that strictly. Or rather: DS-Lite (Dual-Stack Lite) always implies CGNAT (carrier-grade NAT) for IPv4, and I’d argue that DS-Lite is probably one of the most common scenarios in which CGNAT is used.
In theory, CGNAT could also be used with an IPv4-only connection. In practice, however, IPv4-only connections (at least in fixed-line networks like DSL, cable, or fiber) are not very common anymore. And if someone still has IPv4-only, it is more likely to be a dynamic public IPv4 address. Much more common nowadays is IPv4 behind CGNAT plus a public IPv6 prefix, aka DS-lite (Dual-Stack Lite).
Referring to your list, in the context of home internet connections, this usually results in one of the following scenarios:
Dual Stack
Typically a dynamic public IPv4 address and a public IPv6 prefix.
CGNAT
IPv4 connectivity via carrier-grade NAT, usually in combination with DS-Lite.
DS-Lite
IPv4 via carrier-grade NAT plus a public IPv6 prefix.
Single Stack (IPv4 only)
This can mean either a dynamic public IPv4 address or IPv4 behind carrier-grade NAT, with the latter being relatively uncommon on fixed-line home internet connections.
In a business context, there are usually additional options available, such as Dual Stack with static public IPv4 address blocks or even entire routed IPv4 network segments.
DS-Lite (Dual-Stack Lite) and CGNAT (Carrier-Grade NAT) are both techniques for addressing the shortage of public IPv4 addresses by routing IPv4 traffic over an IPv6 network. but DS-Lite uses IPv4-in-IPv6 tunnelling to connect the home router to the internet, while CGNAT is a large carrier-grade NAT where many customers share a common public IPv4 address, which often causes problems with services such as port forwarding. The main difference is that DS-Lite often provides customers with better access to services because it encapsulates IPv4 traffic more effectively, while CGNAT assigns a shared IPv4 address more directly, which limits functionality.
From the customer’s point of view, this means that the biggest difference lies in the configuration of the router at the customer’s location. The FritzBoxes, which are very widespread in Germany, regulate this automatically in the background. However, this is not the case if, like me, you operate a firewall (such as pfsense OPNsense) directly on the ISP’s fibre ONT (or DSL-Modem like Vigor 167).
In this case, the configuration of DS-Lite is more complex than that of CGNAT. With DS-Lite, a GIF interface must be configured as an AFTR (Address Family Transition Router) to tunnel IPv4 into IPv6. Without this GIF interface, you would only have pure IPv6-only Internet and can’t reach any IPv4-only networks.
However, configuring a pfsense on a CGNAT connection is no different from configuring it on a dual-stack connection.
Yes, DS Lite is more complex than “simple” carrier-grade NAT (IPv4 only), simply because it always involves IPv6 as well, hence the “DS” in the name (dual stack). The “Lite” in the name refers to the IPv4 part of the dual stack. 
And yes, the IPv4 part alone is more complex as well, because with DS-Lite, the IPv4 part is tunneled over IPv6 to the customer. However, this tunneled IPv4 connection still ends at the provider’s Carrier Grade Network (CGN), so carrier grade NAT is still involved.
According to Wikipedia:
The CPE (Customer Premises Equipment) uses its global IPv6 connection to deliver the packet to the ISP’s carrier-grade NAT (CGN).
Yes, carrier grade NAT is undoubtedly part of DS-Lite. However, since the thread starter (@trilbytim) also seems to be having problems with the correct configuration of his router, I have tried to highlight what I believe to be the key difference between DS-Lite and CGNAT from the customer’s point of view.
Going back to the original problem @trilbytim was experiencing, there are a few troubleshooting steps I would take to try and identify where the problem lies.
Using another internet connection (such as a cell phone plan)
ping mydomain.tld and
ping <nextcloud server’s external IP address>
If the freeDNS setup is correct, these should provide 100% proof.
Then try accessing the server through the external IP address directly, and the Domain. See if you get the same result.
In this case, they are getting a 401 nginx error. The questions I have here are: is the NC server configured to use nginx or Apache? If Apache (the default iirc), where is nginx coming from?
If you are getting interference from the router, you will really need to learn as much as possible about the router settings. Turn off any services you don’t need. Open every menu. Try to understand everything. And be careful that you don’t expose any of your home machines to connections from the full internet.
There is a little program called netcat which I believe can be used to verify that you are able to connect from outside the network to a specific machine and port on the raspberry pi server. But perhaps there are other methods to look at logs on the RPI itself to see if the outside connections are making it through.
If all that is verified, then it seems to point towards a problem in the nextcloud server configuration. Maybe it is using nginx instead of Apache, and there is a section in the nginx manual that would explain the 401 error.
If it were me, I would try reinstalling the AIO installation and seeing if that fixed any server configuration problems.