VirtualBox HAOS: cloud integration timeouts caused by IPv6 — fix inside

:warning: Intermittent cloud connectivity issues — root cause: IPv6 on VirtualBox host

Symptoms

On a HAOS VirtualBox installation, multiple cloud integrations were experiencing random disconnections and timeouts with no clear error:

  • Repeated timeouts on REST/WebSocket endpoints (e.g. Timeout on user/xxx/hubs, retrying…)
  • Fetch operations blocked for up to 105 seconds before recovering
  • WebSocket integrations receiving 429s and forcing a full re-login
  • Cascading integration reloads triggered by those failures

Root cause

aiohttp (the HTTP library used by Home Assistant and virtually all integrations) tries IPv6 first on a dual-stack host. If the upstream network infrastructure doesn’t properly route IPv6 — common with residential ISPs — the TCP connection opens but stays silent: no RST, no explicit error, just waiting until the OS timeout expires. The client then falls back to IPv4 and succeeds immediately, but the cumulative delay can reach several minutes.

This is especially visible on long-lived connections (SSE, WebSocket) and is often misattributed to cloud-side issues or integration bugs.

Fix

VirtualBox is configured in Bridged Adapter mode, so the HAOS VM inherits the host’s network stack including IPv6. The fix is to disable IPv6 on the bridged Windows host adapter:

  1. Open Network Connections (ncpa.cpl)
  2. Right-click the bridged adapter → Properties
  3. Uncheck Internet Protocol Version 6 (TCP/IPv6)
  4. Click OK — no reboot required

This is persistent across reboots and applies immediately to the VM.

Results after fix

Based on before/after log analysis:

  • Zero blocking timeouts over 2.5 hours of observation (vs. multiple occurrences per 30 min before)
  • Fetch duration back to ~0.6 s (vs. 105 s during incidents)
  • WebSocket integrations stable, no more forced re-logins
  • Remaining SSE reconnections are server-side (TransferEncodingError) and recover in 5 s

Potentially affected integrations

Any integration using aiohttp to reach a cloud HTTPS or WebSocket endpoint, particularly those with persistent long-lived connections.

Test environment

  • HAOS VM on VirtualBox (Bridged Adapter), Windows host
  • Residential VDSL+ ISP (France)
  • Confirmed affected: custom Ajax Systems integration, mbapi2020 (Mercedes)

IPv6 al ays takes pr cedence over IPv4.
This is a decision made by the organ responsible for the TCP/IP protocols, so lot really is to th HA devs.

IPv6 is a requirement for Matter, which is a decision made by the CSA, who is managing the Matter protocol.

Your suggestion would solve the issue in your case, but not in many more.
It is a solution to a symptom and not a solution to the root cause, which is the faulty IPv6 setup in the general network.

It is a solution to a symptom and not a solution to the root cause, which is the faulty IPv6 setup in the general network.
What do you mean exactly? There no IPv6 on this LAN whatsoever

You state you have an issue with IPv6 on the upstream network infrastructure.

That is the one that should be fixed.

There may be a misunderstanding here: as I mentioned, no IPv6 is configured on this LAN. It seems to be the way VirtualBox manages its network stack that causes the problem with HA. Disabling IPv6 at the host level (Windows 11 Pro) definitively fixes the intermittent timeouts. Since then I have migrated everything to Proxmox — what a relief.

It is good that you have solved it and VirtualBox is often frowned upon, due to issues. Windows is nearly always frowned upon, due to lack of update controls in home versions.
However you nearly always have an IPv6 network, because it will auto-configure and no network gear is needed. The device will simply configure itself with IPv6.