I'm experiencing persistent ARC connectivity failure (error 1016, status 530) despite confirmed working inbound TCP transport to my Core.
Environment: • Roon Server Core on macOS Sonoma 14.8.2 • Core LAN IP: 10.1.1.13 • Router WAN IP confirmed matching public IP (no CG-NAT) • Manual port forwarding configured; DMZ also tested • IPv6 set to Link-Local only • System clock verified correct
Network-layer verification: Using tcpdump on the Core host, I confirmed from an external 5G connection (not hairpin NAT): • Full TCP three-way handshake (SYN → SYN-ACK → ACK) • ~405 bytes data transfer from external client • Proper ACK from server • Graceful FIN teardown • No RST from server
I have ruled out: ISP port blocking, local firewall interference, double NAT, IPv6 interference, and CG-NAT.
Remediation already attempted: • Toggled ARC on/off multiple times over several days • Deleted the entire Roon database and all Roon folders under ~/Library • Reinstalled Roon Server from scratch • Tested with DMZ enabled + Firewall disabled on macOS • Verified router NAT state and port forwarding
Suspected root cause: I recently rebuilt my OpenCore EFI (upgraded from 0.8.8 to 1.0.6), which probably changed the SMBIOS identity of the machine (system UUID, serial number, board ID). The Core is likely now presenting a different hardware identity to your cloud infrastructure than the one originally registered.
I believe the previous Core identity is likely still registered cloud-side, and the new identity is being rejected during ARC validation — which explains the 530 response despite successful TCP connectivity.
I cannot see any option to deauthorize old Cores or force a re-registration from my Roon account portal.
Request: Could you please purge any stale Core registrations associated with my account and/or reset the ARC cloud-side state so the current Core identity can register successfully?
Happy to provide any additional diagnostic information needed.
Hi, Roon Arc fails to connect both locally on wifi and over 4G/5G. Whereas the proper Roon app connects internally on WIFI and plays and controls devices.
Hello. I followed the steps - noting that 4 and 7 did not apply to me as I’m not running full Roon on any macos remote devices. Only Roon server on macOS and Roon and Roon Arc on iOS. Anyhow, I followed the other steps and had to reconfigure Roon to tell it to use my macos machine as server - this presented me with the screen to show that I had to unauthorise my current machine etc. And Roon on macOS set itself up again.
I tried turning on Roon Arc after this - in the Roon App on my macOS Roon Server and got the same type of error:
{
“ipv4_connectivity”: {“status”:“NetworkError”,“status_code”:530,“error”:“error code: 1016”},
“external_ip”: {“actual_external_ip”:“139.aaa.bbb.ccc”,“actual_external_ipv6”:“null”,“router_external_ip”:“139.aaa.bbb.ccc”},
“natpmp_autoconfig”: {“status”:“NotFound”},
“upnp_autoconfig”: {“server_ip”:“10.1.1.1”,“found_upnp”:true},
“multinat_autoconfig”: {“status”:“Failed”,“error”:“No uPnP Routers found on LAN”}
}
Thank you for taking the time to follow those troubleshooting steps.
Since clearing that file did not resolve the problem, we can safely rule out a corrupted coreidentity as the root cause.
Looking at your latest diagnostic data, we can see exactly where the process is failing. Your remote device is currently completely unable to reach our authentication servers to perform the initial login:
Plaintextrequest to auth service failed Instance of 'Response' #0 NativeHttpClient._sendRequestWithTimeout (package:music_app_shared/connection/native_http_client.dart:122) <asynchronous suspension>
This connection failure is a direct result of the major, ongoing Cloudflare service disruption that began yesterday. Cloudflare handles the web traffic and security routing for our authentication servers. Because their infrastructure is currently down, your Roon Remote simply cannot reach our login servers, resulting in this timeout error.
There is no further troubleshooting you need to do on your local network or devices right now. We must wait for Cloudflare to restore their services.
Once they report that the incident is resolved, please try logging in again. If you still encounter this error after the outage is cleared, let us know here and we will investigate further!
Upstream errors with both Roon cloud services (the port test error 530) and Cloudflare scheduled maintenance both affected the diagnostic message in Roon Settings → ARC. Both of these conditions should now be resolved.
We’re glad to hear ARC is working properly. The connectivity test within ARC Settings itself (the Cloud and Server connection lights) will be the authoritative connectivity status, since the port test within Roon doesn’t actually ping the phone itself.
If you encounter any further issues, don’t hesitate to reach out in a new request hereand we’ll promptly merge threads accordingly. Thank you!