Microsoft 365 Copilot Chat / Word Copilot does not generate responses from corporate network, while Excel Copilot works

Question

Hello,

We are investigating an issue with Microsoft 365 Copilot in our organization.

Summary:

Microsoft 365 Copilot-related features are not working consistently. The behavior differs depending on the application and user.

Current symptoms:

• Microsoft Loop appears to be affected for all users in our organization.
• Copilot in Excel is working.
• Copilot in Word is not working for most users.
• However, users who also use Copilot Studio appear to be able to use Copilot in Word.
• Microsoft 365 Copilot Chat may open, but responses are not generated or remain in a processing state.
• The issue has been reproduced in Microsoft Edge InPrivate mode.
• General web browsing and other Microsoft 365 services appear to work normally.
• The issue seems to occur only from the corporate network path.

Additional test result:

When using a user account and PC that can normally use Copilot, Copilot without sign-in in Edge InPrivate mode still fails to generate responses from the corporate network.

On the other hand, Microsoft 365 Copilot Chat with a work account can generate responses in some cases.

Because Copilot in Excel is working, this does not seem to be a complete Microsoft 365 Copilot outage or a full network block.

The difference between Excel, Word, Loop, and users with Copilot Studio access suggests that we may need to check not only network behavior, but also license assignment, service plan availability, organizational settings, and feature rollout differences.

Network environment:

• Clients use WinINET proxy settings.
• Microsoft 365 traffic is partially handled by a network appliance used for Microsoft 365 local breakout / forwarding.
• A firewall and proxy are also in the path.
• We do not intentionally perform SSL/TLS inspection for this traffic.
• We are currently checking whether WebSocket Secure / WSS traffic is being blocked, interrupted, or timed out.
• We are also checking whether any proxy, firewall, or network appliance may be preventing WebSocket upgrade or maintaining long-lived WSS connections.

What we have checked so far:

• The issue seems to be limited to the corporate network path.
• We are focusing on Copilot-related real-time communication, especially WSS/WebSocket.
• We are reviewing access to Microsoft 365 Copilot-related domains such as *.cloud.microsoft and *.office.com.
• We are also reviewing whether Loop, Word Copilot, Excel Copilot, and Copilot Studio use different backend endpoints or service plans.

Questions:

1. Is it expected that Copilot in Excel can work while Copilot in Word fails under the same network conditions?
2. Are Copilot in Word, Copilot in Excel, Microsoft Loop, Microsoft 365 Copilot Chat, and Copilot Studio using different backend endpoints or different service plans?
3. Could license assignment, service plan status, organizational settings, or feature rollout differences explain why users with Copilot Studio access can use Copilot in Word while other users cannot?
4. Are there any recommended diagnostic steps for Microsoft 365 Copilot Chat or Word Copilot WSS/WebSocket failures?
5. Which domains and endpoints should be prioritized when checking firewall/proxy logs for Microsoft 365 Copilot Chat, Word Copilot, and Loop?
6. Is there any Microsoft 365 admin center report or network connectivity test that can confirm WSS/WebSocket failures related to Copilot?
7. Are there known cases where Copilot Chat opens normally but response streaming fails due to proxy, firewall, or network appliance behavior?
8. Should *.cloud.microsoft and *.office.com be excluded from proxy authentication, SSL/TLS inspection, caching, or aggressive timeout policies?

Any guidance or recommended troubleshooting steps would be appreciated.

Answer 1

Dear @Umino Tetsuya (海野 哲也),

Based on the symptoms you described, specifically that Copilot in Word, Loop, and Copilot Chat are failing, while Excel Copilot works, and the issue is isolated to your corporate network, the root cause is almost certainly a network configuration issue affecting WebSocket Secure (WSS) connections.

While the core Microsoft 365 endpoints might be reachable, Copilot's real-time response generation relies on WebSockets, which are often handled differently by network infrastructure like proxies and firewalls. Let me address your questions directly.

Why does Copilot in Excel work while Word and Loop fail? Yes, this is expected. While both use WebSockets, the specific backend endpoints and the way they establish these connections can differ. The insight from the Microsoft 365 admin center is critical here: it explicitly detects WebSocket connection failures to *.cloud.microsoft, noting that "this will result in Copilot not working correctly for your users". Excel might rely on a different subset of these endpoints, or its WebSocket requirements are not being interrupted by the same network policy that blocks the endpoints used by Word and Loop.

Addressing Your Specific Questions

1. Are the apps using different endpoints?
   • Yes, they may use different endpoints or prioritize them differently. The primary domains to focus on are *.cloud.microsoft and *.office.com, which are used for real-time features across Copilot experiences. Additionally, Copilot Chat and Word often rely on a WebSocket at wss://substrate.office.com. Loop specifically lists *.svc.ms and *.office.com for its WebSocket connections. Your network team should ensure all these are exempt from inspection. Please refer to this document: Requirements for Copilot Pages and Copilot Notebooks | Microsoft Learn
2. Can license assignment explain this?
   • It is less likely the primary cause for the network-specific failure you've observed. However, the fact that users with Copilot Studio access can use Word Copilot is an important clue. This doesn't mean Studio changes network paths, but it suggests that Studio access might require a more comprehensive license (e.g., a "Microsoft 365 Copilot" license) that also correctly provisions Word Copilot. Users failing in Word may not have the full license assigned, which could be a secondary factor. The primary issue remains network related.
3. Recommended diagnostic steps for WSS failures:
   • Check the Microsoft 365 Admin Center: The most direct step is to navigate to Network Connectivity in your tenant. It may already be reporting the WebSocket insight. This confirms the network issue from Microsoft's perspective. Please refer to this document: Microsoft 365 Network Insights - Microsoft 365 Enterprise | Microsoft Learn
   • Proxy/Firewall Logs: Check for successful TCP connections on port 443 that fail to upgrade to the WebSocket protocol (look for 101 Switching Protocols responses) or for connections to the specific WebSocket endpoints that are terminated prematurely.
   • Timeouts: Ensure your network appliances are configured for persistent connections. Some Copilot services require long-lived streaming connections, and proxies must allow timeouts of 30 minutes minimum for these paths. Please refer to this document: Cowork network endpoints | Microsoft Learn
   Please refer to this document: Reviewing network connection failures for your tenant users when they connect to Microsoft 365 serv…
4. Which domains to prioritize? Prioritize these for immediate review and exemption from SSL/TLS inspection, proxy authentication, and caching:
   • *.cloud.microsoft
   • *.office.com
   • substrate.office.com
   • *.svc.ms
   • Also ensure config.edge.skype.com is allowed, as this is sometimes a required endpoint for Copilot services.

Recommended Action Plan

1. Network Configuration (High Priority): Engage your network team to explicitly allow WebSocket traffic to the domains listed above. Do not block or interfere with the protocol upgrade. Ensure that the WebSocket endpoints are excluded from:
   • SSL/TLS decryption/inspection.
   • Proxy authentication requirements.
   • Aggressive timeout policies. Implement a minimum 30-minute timeout for these connections if possible.
2. Verify License Assignment: While network is the primary suspect, ensure all users having issues are assigned the correct Microsoft 365 Copilot license, not just a basic Microsoft 365 license.
3. Admin Center Diagnostics: Use the built-in network insights in the Microsoft 365 Admin Center. They are a powerful first-party tool for identifying such issues.
4. Windows Troubleshooter: For affected user machines, you can run the Copilot connectivity troubleshooter via the Get Help app in Windows. This can sometimes identify local firewall or network policy blockers. Please refer to this document: Copilot troubleshooters | Microsoft Support

The core of the issue is a network path that fails to support the specific WebSocket requirements of several Copilot experiences. Prioritizing the exemption and proper handling of traffic to the listed domains should resolve the inconsistencies.

Please understand that, as a moderator, the real-world environment and specific challenges your users face may differ from my test setup. Rest assured that I am always here to help you bridge that gap. We will work closely together to guide you effectively and optimize this process for your issue. If you encounter difficulties or notice a step not working as expected, please do not hesitate to contact me. I am happy to continue learning and working alongside you until we find a suitable solution.

Please let me know if you need further details on any of these steps. I'm here to help.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.