AVD browser session hanging on 'connecting' for some user/browser combos

Admin - Thank you for reaching Microsft QnA platform

The behavior points to an Azure Virtual Desktop web client issue that is browser/profile or network related rather than an AVD host problem, since the Windows App continues to work and different browsers succeed for different users.​

Validate basic prerequisites

Confirm users are using the current AVD web client URL https://windows.cloud.microsoft.com (or the region-specific cloud URL if applicable) and not the legacy rdweb or wvd.microsoft.com URLs.​ please verify browsers are on supported versions and fully updated (Edge, Chrome, Firefox, Safari current channels) because older builds can fail silently at the “Connecting…” stage.​

Also test from at least one device on a clean network (no VPN/proxy/filter) to rule out corporate routing or SSL inspection affecting WebSocket's.​

Browser and profile checks - Test in InPrivate/Incognito mode with all extensions disabled; if it works there, the issue is likely cookies, cached auth, or an extension blocking third‑party cookies or WebSocket's.​ In the affected browser, create a brand‑new profile and sign into the AVD web client from that profile; if only the old profile fails, perform a full sign‑out, clear site data for windows.cloud.microsoft.com and *.microsoft.com, and re-add the account.​

please ensure third‑party cookies and local storage are allowed for the AVD site; restrictive settings or privacy extensions can prevent the session bootstrapping.​

Network and security controls - Check whether users with failing browsers traverse a different path (VPN client, SSL-inspecting proxy, ZTNA agent, or secure web gateway) than those where it works; AVD web uses RDP over WebSocket's/TURN that must bypass SSL inspection and not be rewritten.​

Work with your firewall/network team to confirm required AVD endpoints and ports are allowed (HTTPS 443 plus UDP for TURN where applicable) and not categorized as general web that gets proxied or modified.​

If you recently deployed or updated endpoint security (browser isolation, CASB, DLP, etc.), test with those agents temporarily disabled on a pilot device to see whether they correlate with the break six weeks ago.​ - https://v4.hkg1.meaqua.org/en-us/previous-versions/remote-desktop-client/troubleshoot-client-web

Diagnostic data collection - While reproducing the issue, open F12 Developer Tools → Network/Console in the failing browser and capture logs when you click the AVD resource; look for 401/403 errors, blocked cookie messages, or WebSocket negotiation failures.​

Compare a failing trace (e.g., Chrome where it stays on “Connecting…”) with a successful browser on the same machine to see what requests differ, then align this with any conditional access, proxy, or extension behavior.​

Check Entra ID sign‑in logs for affected users to confirm whether any conditional access policy (device compliance, browser requirement, location) blocks the token used by the web client but still allows the Windows App.​

Session host and AVD service validation - Because the Windows App works consistently, a host-pool or session-host issue is unlikely, but you can still verify host status and connection diagnostics from the Azure portal to rule out intermittent back-end problems.​

Use AVD insights or Log Analytics (if enabled) to confirm that web client attempts reach the broker and whether any errors are logged at that layer when the browser gets stuck at “Connecting…”.​

If everything checks out and the issue is clearly isolated to the web client path, monitor the AVD service health and known-issues pages in case a service-side regression aligns with the six-week window you mentioned.​ - https://v4.hkg1.meaqua.org/en-us/troubleshoot/windows-365/known-issues-enterprise