Q: Chrome 143.0.7499.41 blocks access to VVV local .test domains (ERR_NETWORK_ACCESS_DENIED)

[deividuska]

VVV v3.13.2

Chrome on Windows 10 stopped being able to access any VVV .test domains immediately after updating to Chrome 143.0.7499.41 (Official Build).

VVV itself works normally. Firefox and Edge load all .test sites with no issues.
Only Chrome fails, showing:

Your Internet access is blocked
ERR_NETWORK_ACCESS_DENIED

This happens with:

• http://vvv.test
• http://one.wordpress.test
• any VVV site on 192.168.56.x (VirtualBox host-only adapter)

Troubleshooting already done (extensive testing)

• Windows Firewall allows Chrome
• Disabling Windows Firewall entirely → no change
• No antivirus or third-party firewall installed
• Hosts file resolves correctly (vvv.test → 192.168.56.x)
• Vagrant VM responds to pings and loads correctly in other browsers
• Chrome Guest Mode still blocked
• Chrome Incognito still blocked
• Creating a brand-new Chrome profile → still blocked
• Removing Chrome user data and relaunching → still blocked
• Chrome extensions disabled → still blocked
• Checked Chrome enterprise policies → none applied
• Checked WFP (netsh wfp show state) → no blocking filters
• Checked host-only adapter bindings → normal
• ETL network trace: Chrome never sends a SYN packet at all
  (Firefox and Edge do — so VVV networking is working normally)
• Tested multiple Windows user accounts → same issue as soon as Chrome updates
• Verified with a clean Windows 10 user profile → works until Chrome updates

All evidence points to Chrome 143 introducing a regression affecting Windows 10 + VirtualBox host-only networking (192.168.56.x).
VVV itself is fine — the issue is fully Chrome-specific.

Question

Is anyone aware of:

• a Chrome flag,
• a workaround,
• or a configuration change

that restores Chrome access to .test domains on VirtualBox host-only networks under Windows 10?

Or is this a known Chrome 143 bug that requires a future Chromium fix?

Thank you

[tomjn]

If this happens when visiting the IP directly then it isn't related to .test, I'd expect you to either see the dashboard, or be redirected to vvv.test. Personally I'm on Helium with Chromium 142.0.7444.175 and haven't noticed issues but then I'm on MacOS.

My immediate guess is that there is some form of VPN extension or a VPN application active, which usually interferes. You end up requesting 192.168.56.x on the VPN network, rather than on the host network, leading to issues. I suspect that the newer chrome version is coincidental and not the cause, especially since both Chrome and Edge are chromium browsers, but Edge still works.

[tomjn]

I'd also note that VVV is configured to route all traffic to the dashboard, so you can add any domain you want or use the IP directly, it shouldn't depend on .test. likewise you can specify non-.test domains for sites. But I don't think this is likely to have had an impact, or for it to generate ERR_NETWORK_ACCESS_DENIED

[deividuska]

I don’t have any VPN applications active, and no VPN browser extensions installed.

To completely rule out VPN interference, I also checked:
No VPN adapters in Network Connections
No Chrome extensions with any network permissions
No proxy configured (auto-detect OFF, manual proxy OFF)
No enterprise policies controlling Chrome’s network behaviour

Regarding the domain routing:
I understand that VVV routes unknown hostnames to the dashboard and that .test is not required. This is why I also tested direct IP access:
http://192.168.56.x/
Firefox and Edge load the VVV dashboard or site as expected.
Chrome 143 shows ERR_NETWORK_ACCESS_DENIED immediately — even when accessing the raw IP.

Even WITH:
Guest mode
Incognito
New Chrome profile
Firewall fully disabled
Clean Windows user profile
Chrome still fails instantly.
The ETL network trace confirms Chrome never sends a SYN packet to any 192.168.56.x address at all, while Firefox and Edge do normally.

Since the IP fails the same way as the .test domain, and since VVV can’t generate ERR_NETWORK_ACCESS_DENIED, this strongly points to a Chrome-only networking issue on Windows 10 in version 143.0.7499.41, rather than anything related to VVV routing.

[tomjn]

@deividuska could it be related to https://developer.chrome.com/blog/local-network-access?

Chrome for Developers

New permission prompt for Local Network Access  |  Blog  |  Chrome for Developers

Learn about the new permission prompt for sites that connect to local networks.

[tomjn]

A local network is any destination that resolves to the private address space defined in Section 3 of RFC1918 in IPv4 (e.g., 192.168.0.0/16), an IPv4-mapped IPv6 address where the mapped IPv4 address is itself private, or an IPv6 address outside the ::1/128, 2000::/3, and ff00::/8 subnets.

https://chromestatus.com/feature/5152728072060928

chrome://flags/#local-network-access-check

Chrome Platform Status

[tomjn]

@deividuska did that help at all?

[deividuska]

@deividuska did that help at all?

Hi

All good now.

Thank you!

[tomjn]

@deividuska good to hear! I was wondering if the docs needed updating to document the new chrome behaviour, but if it was something unrelated that fixed it for you I wouldn't want to add that in?