Copilot Network Unreachable on a Corporate VPN: Safe Diagnostics

Official documentation checked October 14, 2026.

If Microsoft 365 Copilot fails only while a corporate VPN is connected, the network path is a useful lead, not a complete diagnosis. DNS, routing, proxy authentication, TLS inspection, blocked WebSockets, and access policy can produce similar symptoms.

Keep the managed VPN and security configuration intact while collecting evidence. End users should not add broad proxy exceptions, disable automatic proxy configuration, or make a permanent inspection bypass based only on an error banner.

Record the failure and compare like-for-like

1. Record the exact error, timestamp and time zone, app and version, account type, VPN profile, and whether the initial page loads or only sending a prompt fails.
2. Retry a harmless prompt in the same organizational account. Compare the browser and desktop app on the same approved network path. Save open work before restarting the affected app.
3. Ask IT to check Microsoft 365 service health and relevant sign-in failures. A sign-in policy denial requires an identity-policy investigation, not a firewall allow-list change.
4. If IT permits a comparison on another network, keep the account, device, and app consistent. A different result narrows the investigation; it does not prove that split tunneling is the only solution.

Do not send workplace content through a personal account or unapproved connection as a workaround. If only one application fails, record that distinction rather than deleting another app’s cache or reinstalling the entire Office suite.

Run the official connectivity test

Open the Microsoft 365 network connectivity test on the affected device and select Run test. Inspect the details for Copilot HTTP connectivity, WebSocket connectivity, and latency. Basic testing includes a Copilot WebSocket check; advanced checks may require Microsoft’s downloadable client, which should follow your organization’s software approval process.

When signed in, test reports are uploaded to your tenant and shared with its administrator. Share the results through the approved support route and avoid enabling a public report link. Microsoft’s test-tool documentation explains the results and sharing behavior.

A passing web test does not reproduce every desktop feature or confirm the user’s license and permissions. A failing result should be correlated with the timestamp in VPN, DNS, proxy, or firewall logs.

Have IT check the current endpoints and transport

Use the live Copilot requirements, including the linked Microsoft 365 endpoint data, instead of a fixed two-host list. Current enterprise guidance includes *.cloud.microsoft, with copilot.cloud.microsoft as the updated app entry point, and secure WebSocket support to the documented *.office.com and cloud.microsoft domains. Microsoft explicitly requires the complete cloud.microsoft domain rather than selectively allowing individual apps within it.

Ask the network team to identify which layer fails:

• DNS: Does the configured corporate resolver answer for the actual failed hostname? A lookup failure can have several causes; it is not automatically proof of intentional blocking.
• Transport: Is the required connection allowed through the VPN route, firewall, and proxy? Successful TCP or HTTPS access alone does not establish that WebSockets work.
• TLS and proxy behavior: Is inspection breaking trust or negotiation? Is the proxy closing the connection prematurely? Keep certificate validation enabled.
• Identity and tenant controls: Is the request being denied by a tenant restriction or Conditional Access rule? Preserve those protections while the responsible team reviews the event.

Microsoft’s network principles recommend optimized direct connectivity and avoiding intrusive inspection for published Microsoft 365 endpoints. Administrators should implement that guidance through approved network design and maintained endpoint data, not a user-created bypass for all of microsoft.com. Do not replace the approved PAC file or disable the VPN globally.

Verify the change and escalate with evidence

After an approved change, rerun the same connectivity checks and the original harmless Copilot action. Confirm that both authentication and responses work in the affected app, and check that unrelated corporate access still works. Record the changed rule, responsible owner, test results, and rollback plan.

If the issue persists, provide IT with the sanitized error, app version, failing hostname, test report, and matching timestamps. Remove tokens, cookies, authorization codes, and sensitive prompt content from captures before sharing. Do not keep an experimental exception merely because one request succeeded; the network owner must approve any lasting configuration.