Title: RDM 2026.3.1.2 (macOS): Hub connection times out when hostname has unreachable IPv6 (AAAA) addresses, no fallback to IPv4
Remark
This bug report mostly serves for logging purposes and possible circumvention proposals in case any other Devolutions’ customers may experience related issues.
Environment
- RDM for macOS 2026.3.1.2 (.NET 10.0.12), updated 05/10/2026 from 2026.2.5.1
- macOS Tahoe 26.6.2
- Data source: Devolutions Hub Business (`example.devolutions.app`)
- Network: dual-stack (native IPv4 + IPv6)
Problem
Every HTTP call from RDM fails: the Hub login, the update check, and so on. Other apps on the same Mac work fine. RDM throws a connect timeout:
System.Threading.Tasks.TaskCanceledException: OperationCanceled
---> System.TimeoutException: net_http_connect_timedout
at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(...)
at System.Net.Sockets.SocketAsyncEventArgs.<DnsConnectAsync>g__Core|113_0(MultiConnectSocketAsyncEventArgs ...)
...
at Devolutions.RemoteDesktopManager.Business.DataSources.HubClientDelegate.SendWithTimeoutAsync(...)
at Devolutions.Hub.Clients.HubClient.GetServerConfigurationAsync(...)
at Devolutions.RemoteDesktopManager.Business.DataSources.HubConnectionDataSource.Login()
Cause
The local DNS resolver had DNS64 enabled without a NAT64 gateway. That's a misconfiguration on my side, now fixed. It caused the Hub hostname to resolve to unreachable IPv6 addresses alongside the working IPv4 ones:
$ dig +short AAAA example.devolutions.app
64:ff9b::8d65:5a60 (x4, unreachable)
$ curl -6 https://example.devolutions.app -> connect timeout
$ curl -4 https://example.devolutions.app -> HTTP 200
curl, browsers and other macOS apps fall back to IPv4 within milliseconds. RDM keeps trying the IPv6 addresses one after another ( MultiConnectSocketAsyncEventArgs ) until its own timeout in HubClientDelegate.SendWithTimeoutAsync expires, so it never reaches IPv4.
Workaround
Remove the unreachable AAAA records: disable DNS64, or turn off IPv6 on the Mac. RDM then connects immediately.
Request
The same failure will happen on any network with broken or partial IPv6, such as hotel, guest and some corporate networks. Could you:
1. Check whether something changed in 2026.3.1.2 in the HTTP handler or the connect timeout? I didn't see this with 2026.2.5.1 .
2. Consider IPv4/IPv6 fallback ("Happy Eyeballs", RFC 8305) in the Hub client. For example, use SocketsHttpHandler.ConnectCallback to race the addresses, or use a short per-address connect timeout instead of one overall timeout.