Zoom and Teams Won't Connect in 2026: Clash Split Routing and DNS Troubleshooting Steps

Why “global proxy” is a risky default for video conferencing

A blanket policy is easy to explain—“just turn Clash on”—but video calls are unusually sensitive to latency variance, UDP treatment, and inconsistent exits. Meeting clients open many parallel connections: HTTPS for sign-in and licensing checks, TLS to vendor CDNs, and often UDP or WebRTC-style media paths for real-time audio and video. If your catch-all route sends unrelated browser tabs, cloud sync, and background updates through the same overseas node as the call, you may starve the session of headroom even when the raw megabits look fine on a speed test.

Worse, some exits block or deprioritize UDP, mishandle QUIC, or peer poorly with the specific cloud region your meeting service uses. The user-visible symptom is maddeningly specific: Slack messages load, email syncs, yet the camera preview never starts. Clash is designed for policy routing: you define proxy-groups, then write rules that send each connection to a group, to DIRECT, or to REJECT. The goal here is not to memorize every hostname Zoom has ever used; it is to pair a named outbound bucket for collaboration apps with DNS settings that make those rules fire for real desktop sessions—and to prove matches with logs before you blame “bad nodes.” If you are new to that model, start with the site’s Clash tutorial, then return here for a meeting-shaped overlay on the same YAML ideas.

What Zoom and Teams actually do on the wire (at a practical level)

Both products are moving targets. Zoom historically clusters traffic around zoom.us and a family of subdomains for web, client updates, and telemetry, while media may traverse additional hosts and IP ranges that change with region and feature flags. Microsoft Teams—especially in its modern Windows and macOS clients—leans heavily on Microsoft 365 identity and service endpoints: teams.microsoft.com, traffic under microsoft.com and office.com, and a long tail of *.microsoft.com, *.office.net, and related infrastructure. Browser-based Teams sessions can differ from the installed client; mobile apps add yet another stack.

From a routing perspective, the lesson is simple: treat any static domain list as a hypothesis to validate, not scripture. Your tenant, license SKU, and client version may pull different hostnames than a screenshot from last year. The reliable workflow is to reproduce a failed join attempt with logging enabled, read the Server Name Indication (SNI) or destination names your machine actually uses, then add or refine matchers. For broader pattern maintenance—especially if you use remote rule providers—see our custom rules tutorial, which covers merge order and how subscription updates can accidentally erase personal tweaks.

UDP, WebRTC, and why TCP-only thinking misleads you

Many proxy stacks shine at TCP TLS. Video conferencing often adds UDP for media when the network allows it, and clients may fall back to TCP when UDP is impaired—sometimes producing “connected but robotic audio” or one-way video. If your upstream path filters UDP differently from TCP, you can see perfect web browsing alongside broken calls. When you test, note whether Clash’s log shows UDP associations and whether your selected outbound supports the behavior you expect. Some setups require TUN mode to capture traffic that ignores application proxy settings; others need explicit allowances for QUIC or UDP in firewall products that sit beside Clash.

If you need deeper background on transparent capture and DNS coupling, read our TUN mode deep dive; many “rules look correct” mysteries disappear once the right packets enter the core.

Design a dedicated proxy group for meetings (and keep it separate)

Before editing rules, define a proxy-groups entry you can aim at—call it Meetings, Collab, or any label you will recognize months later. A select group is appropriate when you want manual control for different regions; a url-test or fallback group helps when you prefer automatic failover among several exits. The group should point at nodes that actually carry UDP cleanly to the vendor clouds you rely on, not merely nodes that win synthetic latency tests to a generic test file.

Keep this group separate from a generic Proxy catch-all so you can reason about collaboration traffic independently from streaming, social networks, or ad-heavy sites that might need different geolocation. Separation also makes logs readable: when Teams misbehaves, you filter for the policy name and immediately see whether connections match your intended bucket. For scheduling mechanics—selectors, nested groups, and health checks—our proxy groups guide walks through the YAML concepts without tying them to a single vendor workflow.

A practical domain baseline (always confirm in your logs)

The following hostnames and suffixes appear frequently in Zoom and Microsoft Teams sessions and are useful as DOMAIN and DOMAIN-SUFFIX matchers in Clash. They are intentionally conservative: they prioritize coverage of common flows over minimalism. Verify with logging before you treat any list as complete.

• Zoom (illustrative): zoom.us, zoom.com, and product subdomains such as *.zoom.us for client, web, and CDN assets—your logs may show additional regional hosts.
• Microsoft Teams and Microsoft 365 (illustrative): teams.microsoft.com, microsoft.com, office.com, office.net, microsoftonline.com, live.com, and wide suffixes such as microsoft.com / office.net for shared services—Teams touches more than one bucket during sign-in, presence, and calls.
• Supporting infrastructure: certificate chains, update channels, and crash telemetry may resolve to additional Microsoft or third-party CDNs; watch for repeated misses rather than guessing.

Place identity flows thoughtfully. Routing all of microsoft.com through an overseas exit may fix a call while subtly changing how Windows Update, Store, or unrelated Microsoft properties behave. Many teams either accept that trade-off for simplicity or split identity hosts using more granular lines discovered through their own connection logs.

YAML skeleton: high precedence, then meeting-focused matches

Assume your profile already defines proxies and a group named Meetings. The fragment below is illustrative: adapt names to your file, merge with your provider template, and keep LAN exclusions above broad matchers.

# Local and loopback first (adjust to your network)
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
IP-CIDR,127.0.0.0/8,DIRECT

# Collaboration-oriented matches (verify hostnames in YOUR logs)
DOMAIN-SUFFIX,zoom.us,Meetings
DOMAIN-SUFFIX,zoom.com,Meetings
DOMAIN,teams.microsoft.com,Meetings
DOMAIN-SUFFIX,office.com,Meetings
DOMAIN-SUFFIX,office.net,Meetings
DOMAIN-SUFFIX,microsoft.com,Meetings
DOMAIN-SUFFIX,microsoftonline.com,Meetings
DOMAIN-SUFFIX,live.com,Meetings

# Remaining traffic follows your profile (GEOIP, MATCH, etc.)
# MATCH,Auto

Notice the design: you are giving the core a repeatable place to send TLS connections whose SNI identifies vendor infrastructure. If a rule never triggers, the fix is usually capture or DNS, not an additional fifty random domains copied from a forum thread.

DNS: the hidden half of “Teams works in the browser but not in the app”

Misconfigured DNS is the fastest way to make split routing look broken. In fake-ip modes, Clash may return synthetic addresses that map back to domain names internally; that is powerful until an application uses a different resolver path and pins inconsistent results. Symptoms include intermittent TLS failures, endless spinner states, and “works once per reboot” behavior as caches diverge.

Align your strategy deliberately. If you rely on Clash as the system DNS handler, ensure upstreams are trustworthy and reachable from your exit path. If applications use DNS over HTTPS directly to public resolvers, those queries may bypass the assumptions your rules depend on—either route those DoH endpoints explicitly or accept that some flows will be classified differently. The objective is consistent name-to-policy mapping, not ideological purity about resolver brands.

Windows, Secure DNS, and enterprise profiles

On Windows 11, “Secure DNS” settings and enterprise policies can steer resolvers in parallel with Clash. If Teams works on one profile but not another, compare OS-level DNS settings, browser Secure DNS toggles, and any endpoint agent that injects its own filtering. The same advice applies to macOS profiles pushed through MDM: a hidden resolver override can make Clash’s view of the world disagree with the application’s.

IPv6 dual-stack surprises

On networks that advertise IPv6, your operating system may prefer AAAA records when both families resolve. If policies or upstream tunnels handle IPv4 and IPv6 asymmetrically, you can end up with split behavior: some Microsoft properties on one family, others on another. When symptoms correlate with moving between Wi-Fi and cellular, add IPv6 to your checklist and verify whether connections in logs show v4 or v6 addresses.

System proxy versus TUN: what actually captures the Teams client

Many users enable “system proxy” in a GUI and expect every application to obey it. Some desktop clients honor OS proxy settings faithfully; others use their own network stack, pinned sockets, or service accounts that bypass the user session’s proxy. TUN mode routes packets through a virtual adapter so more traffic is visible to the core at the expense of complexity and occasional conflicts with other VPN software.

A practical approach is to start with the mode you already trust on that machine, then escalate to TUN if logs show connections that never hit Clash. Remember to disable competing “full tunnel” VPNs while testing; two layers fighting for the same routes are a common source of “half the internet works” reports. If QUIC or UDP behaves differently under system proxy versus TUN, compare both carefully—browser flags that disable QUIC can be useful only as a diagnostic, not as a permanent security posture.

Corporate VPNs, split tunneling, and policy reality

This article assumes you administer a machine where installing a local proxy is permitted. Many employers forbid split tunneling entirely or require traffic to traverse a corporate VPN with its own DNS and filtering. In those environments, layering Clash on top can create contradictory routes: the VPN wants one exit, your YAML wants another, and the meeting client becomes the casualty.

If you are on a managed device, read internal policy before editing networking. When policy allows only selective exceptions, the winning approach is often to document the official split-tunnel list your IT team maintains rather than improvising domain guesses. For personal machines used for freelance calls, the opposite applies: you own the stack, so keep overrides in a user-controlled snippet that survives subscription refreshes.

Tested verification workflow (repeatable)

Use a disciplined sequence whenever you change rules or DNS. First, confirm Clash is running the profile you think it is—remote subscriptions can overwrite local edits if merges are misconfigured. Second, open the log view and reproduce a minimal failure: join a test meeting, toggle video, wait for the stall. Third, locate the connection lines and note which rule matched and which outbound group handled the flow. Fourth, only then swap servers inside Meetings if latency or loss remains the problem.

When authentication misbehaves, widen your lens: watch for Microsoft identity hosts that still hit DIRECT because a broader MATCH line fired earlier than your collaboration rules—first match wins in Clash. When only part of the call works, check whether CDN or telemetry hosts split across policies. The log tells you which hypothesis is real; guessing wastes hours.

What to record in a one-minute capture

When filing notes—or an internal ticket—you speed resolution by recording facts that stay comparable across days. Include the Clash profile version string, the core flavor (Meta versus legacy), whether TUN or system proxy mode is active, the outbound group selected for meeting traffic, and three example destination hostnames from the failure window. Add your network type (Ethernet, Wi-Fi band, or LTE) because radio conditions change routing in ways that YAML cannot see.

Sanity checks before you blame the exit node

Swap two variables methodically. First, keep the same node but change DNS strategy in a controlled way—only one knob at a time. Second, keep DNS fixed but rotate among two exits in the same city family to see if the symptom tracks a specific ASN. Third, test a non-meeting HTTPS site through the same group to confirm generic TLS health. If generic sites fail the same way, your issue is probably not Zoom-specific; you saved time by not chasing imaginary vendor-only superstitions.

Symptom cookbook: mapping complaints to likely fixes

Use the following as orientation, not guarantees—your logs remain authoritative.

• Infinite “connecting” or sign-in loops: inspect identity hostnames for mixed policies—some flows on DIRECT and others on proxy—or conditional access rules that dislike rapidly changing exits. Align Microsoft identity domains to one outbound policy and retry in a clean profile.
• Audio works but video never starts: suspect UDP path issues, MTU problems, or QUIC/HTTP3 differences between browser and desktop clients. Test another network and compare IPv4 versus IPv6 behavior.
• Sharp latency spikes every few minutes: consider background sync, large downloads on the same node, or CPU throttling on laptops thermally stressed during calls. Separate meeting traffic from bulk transfers with split routing.
• Only Wi-Fi fails: compare against Ethernet or a phone hotspot; some access points break UDP or large MTU paths in ways that look like proxy failures.

Each bullet could be a chapter on its own; the point is to tie symptoms to connection classes instead of treating “Teams” as a single monolithic failure. Collaboration stacks are distributed systems; your proxy sees the edges it sees.

Making overrides survive subscription refreshes

Most users import a remote subscription that periodically replaces large sections of YAML—sometimes including the rules array—when the provider ships template updates. That convenience collides with personal tweaks: your carefully placed DOMAIN-SUFFIX,zoom.us line vanishes after an auto-update, and suddenly “Clash broke Teams” when the real story is “the merge order changed.”

Modern clients usually offer override files, prepend rules, or user snippets that load after provider content. Prefer those mechanisms for meeting-specific lines so they remain stable across subscription churn. After any refresh, rerun the short verification sequence: open logs, join a test call, confirm the rule hit. Treat that minute like a smoke test for infrastructure you actually rely on—not optional homework.

Privacy, terms of use, and realistic expectations

Routing changes path selection; it does not grant entitlement to services in regions where a vendor does not offer them, and it does not replace compliance with account terms, workplace policies, or local regulations. Respect Zoom and Microsoft acceptable-use rules and your employer’s data-handling requirements.

Also separate open-source transparency from installer habits. Reading upstream release notes on GitHub is sensible; fetching production binaries should still flow through approved channels. For personal setups, prefer the site’s download page when choosing a maintained GUI, keeping GitHub as documentation rather than the first click for every user.

Putting it together for everyday remote work

Reliable Zoom and Microsoft Teams sessions behind Clash in 2026 look less like a secret domain dump and more like a tight loop: observe hostnames, encode them into focused rules aimed at a dedicated Meetings group, align DNS with your capture mode, and prove matches with logs before you blame node quality. Compared with flipping a global proxy switch, that approach reduces random auth challenges, avoids sending unrelated browsing through distant exits, and gives you a checklist when a client update changes resolver behavior overnight.

If you have not yet installed a maintained Clash Meta-class client on your work machine, walk through our Clash tutorial, import your subscription, then layer the overrides from this article. When you are ready to standardize installers across machines, use our download page as the primary path—Download Clash for free and experience the difference.