Use Cases · Clash Technical Blog

Routing Zoom, Teams, and Slack with Clash: Troubleshooting Remote Meetings and Sign-In

Route Zoom, Teams, and Slack by testing sign-in, meeting media, files, and persistent messages separately while reserving the company VPN for internal systems.

Read the articleBack to blog
  • Zoom
  • Teams
  • Slack
  • Remote Work
On this page
Published
Updated
Estimated reading time
About 8 minutes

First identify which paths handle sign-in, files, and meeting media

Zoom, Teams, and Slack may all look like office apps, but sign-in, chat, file downloads, meeting audio and video, and the corporate intranet do not share one connection path. Stabilize sign-in first, then test UDP meetings and WebSocket separately. That gives “can sign in but cannot join a meeting” and “meetings work but attachments will not open” distinct troubleshooting paths.

The most important distinctions in official network requirements

AppKey trafficOfficial information that remains relevant in 2026
ZoomSign-in and web traffic use TCP 443; meeting media prefers UDPMeetings commonly use UDP 3478-3479 and 8801-8810; IP ranges can change
TeamsMicrosoft 365 separates sign-in, chat, files, and mediaDirect UDP 3478-3481 is recommended for media, and endpoint lists are updated monthly
SlackMessaging depends on a persistent WebSocket over TCP 443SSL 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.

Rules demonstrate only stable domains; use official lists for media IP ranges
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,DIRECT

Replace both REPLACE_WITH names with node names that actually exist in the current configuration. If the existing configuration already has a fallback policy, replace the final MATCH,DIRECT with its original MATCH rule. Pin the policy manually first so the outbound route does not change automatically halfway through 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.

If Teams files work but meetings stutter, they are not using the same path

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's most distinctive failure is not an unreachable website, but a reconnect warning that repeatedly appears above the message area. Run the official connection test to verify WebSocket first, then decide whether an administrator needs to adjust SSL inspection.

Slack-specific checks

  1. Open my.slack.com/help/test

    Run the connection test from the current workspace and inspect the Primary and Backup WebSocket results.

  2. Check SSL decryption

    If the proxy does not support WebSocket, an administrator should exclude wss-primary.slack.com, wss-backup.slack.com, and wss-mobile.slack.com.

  3. Collect Net Logs

    In the desktop app, use Help → Troubleshooting → Restart and Collect Net Logs to record the connection that actually drops.

  4. 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

Keep identity authentication, callbacks, and app requests on the same Work-Web route. Check system time and the redirect back from the default browser; do not switch nodes during sign-in.

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

References