Use Cases · Clash Technical Blog

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

Logging into Zoom, Teams, or Slack does not prove that meeting media, files, and persistent messaging connections work. Check capture and exits for the failing action, keep company systems on the organization’s required VPN, and retest with real meetings and file transfers.

  • Zoom
  • Teams
  • Slack
  • Remote Work
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

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

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

  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

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

References