On this page
Work apps can be most frustrating when login and messages work but meetings, screen sharing, or attachments fail. Test the task that fails rather than opening the home page again. Check meeting media, message connections, and file access separately while preserving your company’s required internal-network access, so fixing a meeting does not disrupt other work systems.
Login works but meetings or attachments fail: which requests should you check?
Record whether Zoom, Teams, and Slack fail during login, attachment access, or audio and video, then check the corresponding services in the table below. UDP commonly carries meeting media, while WebSocket maintains real-time message connections. Testing a web page alone does not replace checks of meetings and message connections.
The most important distinctions in official network requirements
| App | Key traffic | Official information that remains relevant in 2026 |
|---|---|---|
| Zoom | Sign-in and web traffic use TCP 443; meeting media prefers UDP | Meetings commonly use UDP 3478-3479 and 8801-8810; IP ranges can change |
| Teams | Microsoft 365 separates sign-in, chat, files, and media | Direct UDP 3478-3481 is recommended for media, and endpoint lists are updated monthly |
| Slack | Messaging depends on a persistent WebSocket over TCP 443 | SSL inspection must support WebSocket or exclude the officially listed wss domains |
Domain rules work well for sign-in and ordinary HTTPS traffic, but media also depends on UDP, the corporate firewall, and the application process. Do not permanently copy an officially maintained IP list into a personal YAML file. Zoom and Microsoft both update their ranges; in managed environments, administrators should subscribe to the official lists.
Put work websites and real-time meetings in two separate policy groups
Chat, files, and sign-in need a stable outbound route, while meetings are more sensitive to UDP, upstream bandwidth, and jitter. Use Work-Web for ordinary requests and Meeting for nodes already verified to support UDP. If the corporate network permits direct Zoom or Teams media, keep DIRECT in the Meeting group as well.
proxy-groups:
- name: Work-Web
type: select
proxies: [REPLACE_WITH_WORK_NODE, DIRECT]
- name: Meeting
type: select
proxies: [DIRECT, REPLACE_WITH_UDP_NODE]
rules:
- DOMAIN-SUFFIX,zoom.us,Meeting
- DOMAIN-SUFFIX,zoom.com,Meeting
- DOMAIN-SUFFIX,teams.microsoft.com,Work-Web
- DOMAIN-SUFFIX,teams.cloud.microsoft,Work-Web
- DOMAIN-SUFFIX,slack.com,Work-Web
- DOMAIN-SUFFIX,slack-edge.com,Work-Web
- MATCH,DIRECTReplace both REPLACE_WITH names with node names already in the current configuration. If the original configuration defines how other traffic is handled by default, replace the example’s final MATCH,DIRECT with the original MATCH rule. Set the policy manually to avoid an automatic exit change during a meeting.
If Zoom can sign in but remains stuck on Connecting, inspect media UDP
Opening zoom.us in a browser proves only that the HTTPS sign-in endpoint is reachable. If the meeting remains on Connecting, video appears without audio, or sharing drops after a few minutes, inspect UDP in the Clash connections screen and firewall log. Zoom's current official list includes UDP 3478-3479 and 8801-8810 for meeting media.
On a personal network, first test Zoom audio and sharing through the same node. In a managed network, do not copy an entire IP allowlist yourself; administrators should maintain it from the official Zoom page. If a node lacks UDP support, changing the web proxy will not repair meeting media.
Teams files open but meetings stutter: check UDP media traffic
Teams sign-in uses Microsoft identity services, while chat and files may also use SharePoint or OneDrive, and real-time media uses another set of endpoints. Microsoft's 2026 network guidance continues to recommend bypassing proxies for media, keeping the path as short as possible, and allowing UDP 3478-3481.
If the organization enforces a proxy or SSL inspection, follow its policy. Personal Clash rules should not override private address ranges or internal DNS supplied by the corporate VPN. If web pages and chat already work, do not move all Microsoft 365 traffic to another region just to reduce meeting latency.
If Slack repeatedly shows a reconnect banner, run the official WebSocket test directly
Slack-specific checks
Open my.slack.com/help/test
Run the connection test from the current workspace and inspect the Primary and Backup WebSocket results.
Check SSL decryption
If a corporate proxy decrypts SSL but does not support WebSocket, ask the administrator to exempt wss-primary.slack.com, wss-backup.slack.com, and wss-mobile.slack.com from decryption.
Collect Net Logs
In the desktop app, use Help → Troubleshooting → Restart and Collect Net Logs to record the connection that actually drops.
Separate Huddle failures
If text is stable but Huddle fails, run the audio and video test under Audio & video settings instead of resetting the workspace.
When the corporate VPN already handles the intranet, do not layer a second TUN on top
If the computer also connects to a corporate VPN, preserve the private address ranges and internal DNS it supplies. Letting Clash handle only the external websites that require it is more reliable than having two virtual adapters compete for the default route.
The browser is signed in, but the desktop client returns to the sign-in page
Use the same Work-Web exit for authentication, the request returning to the app after login, and requests within the app. Check the system time and whether the default browser completes this redirect; do not switch nodes during login.
Corporate websites work until Clash TUN is enabled
Return to the Clash system proxy; continue leaving private address ranges and internal DNS to the corporate VPN.
Text messages work, but attachments will not open
Inspect the actual SharePoint, Slack file-hosting, or CDN requests without changing meeting UDP.
Meetings work on a mobile hotspot but fail on corporate Wi-Fi
Give the result to the network administrator, focusing on UDP and SSL/WebSocket inspection.
Connection drops after an automatic node switch during a meeting
Change the Meeting group to a fixed selection, then rejoin to establish a new session.
Real-world verification after routing is complete
- Zoom can sign in and complete sustained audio, video, and screen-sharing tests
- Teams can send messages, open files, and join one test meeting
- Primary and Backup WebSocket pass the official Slack test, and files and Huddle work independently
- Corporate intranet pages and internal DNS remain handled by the corporate VPN, and no system proxy remains after quitting Clash
