Could also be a stale DNS cache entry on one device or the router. If you ping your duckdns fqdn from the device that can’t connect while on your home network, does it resolve to the correct public IP?

I still think a firewall/nat issue is more likely tho.

What is your router make and model? You need to enable hairpin NAT.

The port is forwarded from your router to the pi, right? If so, you could test for the router as the bottleneck using the router’s WAN side IP address as the target.

This should give you a good data point for comparison. If it’s also slow then you can focus on the router performance. Some are slow when doing hairpin NAT.

I’d say your chances are very good. Even their high end rackmount models work with the usbhid-ups driver. Don’t think they would change things up in this regard since they would also need to change their software.

It’s probably still IPv6 related. If you use something like Network Analyzer on your phone while only connected to the mobile network you may find that it only shows an IPv6 address and DNS server, no IPv4 config. That could explain the difference. Particularly if you were using the maximum typically permissible MTU. Your provider might also be doing some 6to4 tunneling somewhere that adds overhead and causes size problems.

You might want to do a DNS leak test from your phone with the wireguard connection down and then with it up to make sure you’re tunneling DNS. This will be clearer if you set pihole to use something upstream that an ISP is unlikely to use - quad9 for example.