Why Zoom and Google Meet need deliberate Clash rules

A video meeting is not one tidy HTTPS request. Zoom, Google Meet, and Slack may use separate sign-in pages, configuration services, update hosts, WebSocket connections, and media transports. During a call, audio and video can depend on sustained flows that behave differently from the brief requests used to load a calendar or open a chat. A browser may reach the meeting page quickly while the media path is congested; Slack may show new messages only after a reconnect; or an authentication window may finish loading while its return to the desktop app stalls.

Clash makes routing decisions per connection, not per intention. A rule for a meeting website does not necessarily route every connection made by the desktop client, and a rule for a desktop process may not cover a browser tab using the same service. The exact result depends on the client, the Mihomo core version, the operating system’s proxy behavior, DNS mode, and whether traffic is captured through a system proxy or TUN. “Connected” in a dashboard confirms that a listener or proxy group is active; it does not prove that every media flow is using the intended route.

The practical goal is not to send every application through a proxy. It is to choose a dependable route for the services that need it, keep ordinary local and domestic browsing on a suitable direct path, and avoid changing several network layers at once. This is particularly useful on a work laptop where a company VPN, endpoint security agent, or managed proxy may already control traffic. Start by understanding what your device is allowed to do, then make the smallest routing change that addresses the observed problem.

⚠ Workplace policy: Before changing system proxy settings, enabling TUN, or routing meeting traffic through a third-party service, check your employer’s network and data-handling rules. Do not proxy confidential calls or work accounts through an unapproved provider. If the device is managed, ask IT whether Clash, local proxy listeners, and split routing are permitted.

It also helps to separate symptoms before editing rules. If the meeting page itself cannot load, investigate DNS, the browser’s proxy settings, and the route for the relevant web host. If the page loads but audio or video repeatedly freezes, investigate the media path, packet loss, latency, and whether UDP is supported end to end. If calls work in a browser but not in the Zoom desktop app, the two clients may be using different proxy mechanisms or different traffic-capture paths. A single broad domain rule cannot reliably diagnose all three cases.

Choose a routing model before editing YAML

First decide which traffic you want to control. A system proxy is a convenient starting point for applications that honor the operating system’s HTTP or SOCKS proxy settings. It is generally easy to enable and undo, but it does not capture every program. Some desktop clients use their own proxy preferences; others use network libraries that do not consult system settings. A command-line tool or background service may therefore follow a different path from the browser that opened the meeting invitation.

TUN mode can capture a broader set of application traffic by routing it through a virtual network interface. That may help when an application ignores the system proxy, but it adds more variables: permissions, route priorities, DNS handling, IPv4 and IPv6 behavior, and interaction with corporate VPNs. Do not turn on TUN simply because a video call stutters. Test the simpler system-proxy path first, and use TUN only when your client and operating system support it and you are permitted to change network routing.

For the routing policy itself, begin with a small set of readable rules rather than a long list copied from an unrelated configuration. A typical policy has an intentional group for approved proxy traffic, a separate direct route for local resources, and a final rule that makes the default behavior clear. The group names below are illustrative; use names that already exist in your profile, and do not paste a rule into a configuration without checking its order and syntax. 

rules:
  - DOMAIN-SUFFIX,zoom.us,Work-Route
  - DOMAIN-SUFFIX,google.com,Work-Route
  - DOMAIN-SUFFIX,meet.google.com,Work-Route
  - DOMAIN-SUFFIX,slack.com,Work-Route
  - GEOIP,private,DIRECT
  - MATCH,DIRECT

Treat that example as a starting point for discussion, not a complete vendor endpoint inventory. Zoom, Google, and Slack can use multiple hostnames, cloud services, and delivery networks; their infrastructure changes, and an organization may use its own domains or gateways. A suffix match can also affect more than the meeting component—for example, routing all of google.com through a work group may change the path for search, account pages, or other browser activity. If your goal is only to fix a meeting connection, prefer a narrower rule where the service and your configuration support one.

Rule order matters. Clash evaluates rules in sequence and applies the first matching rule, so a broad rule placed above a more specific one may make the specific rule ineffective. A catch-all such as MATCH should appear only after the exceptions and service rules you intend to use. Keep private addresses, office subnets, printers, local file servers, and other internal destinations on the paths required by your network. A meeting configuration that breaks an internal calendar or file share is not a successful work setup, even if the call connects.

ℹ Useful distinction: Domain rules classify connections by destination name when that information is available to the core. Process rules classify by application only where the operating system, client, and core support process matching. Neither method should be assumed to capture every flow in every setup.

Set up the desktop route and test one change at a time

Before making a change, record the current state. Note the active profile, proxy mode, selected group, system proxy setting, TUN state, and whether another VPN is connected. If you edit YAML, save a separate copy of the working configuration. This baseline makes it possible to undo a change and helps distinguish a routing issue from an update, permissions problem, or service outage.

  1. Confirm the application and policy. Identify whether you use Zoom for desktop, Google Meet in a browser, or both. Check whether the device is personally managed or controlled by your employer. Ask IT before adding a proxy or changing tunnel settings on a managed computer, especially if a company VPN or security client is active.
  2. Check the existing route first. In your Clash client, confirm that the profile loaded successfully and that the group used by your meeting rules has a valid selectable node or policy. A rule can match perfectly but still fail if its target group is missing, unavailable, or set to an unusable option. Review the connection log during a test call rather than relying only on the green connection indicator.
  3. Start with the least invasive mode. If your application honors the operating system proxy, enable the client’s system-proxy option and test a short call. Do not enable TUN and system proxy together as a first experiment. If the desktop app does not appear in the connection log and the system proxy has no effect, consult the client’s documented support for application proxy settings or TUN capture before changing more settings.
  4. Add a narrow, ordered rule. Add only the service rules needed for the test, place them above broad fallback rules, and ensure that the referenced group exists. Keep internal destinations and local network traffic on the appropriate direct route. Avoid replacing the whole ruleset or adding a large third-party rule provider just to test one meeting.
  5. Test the actual call, not just the landing page. Join a short test meeting with camera and microphone enabled. Check whether audio is continuous, whether video remains stable, and whether screen sharing behaves normally. Review Clash’s connection log during the call to see which rules and groups are actually used. A successful page load or sign-in is not proof that the live media connection has a good route.
  6. Change one variable at a time. If the test fails, switch only the selected group or one relevant rule, then repeat the same test. Compare latency and packet loss where your client provides meaningful measurements, but do not assume that a fast HTTP probe predicts call quality. A route can respond quickly to a short check and still perform poorly under sustained real-time traffic.
  7. Restore and document. If the change makes the call worse or disrupts other work services, revert to the saved profile and return the system proxy or TUN state to its previous value. Once a configuration works, record what changed and which client version and operating system you tested. This is especially useful when a profile refresh or application update later changes the result.

On a desktop browser, remember that a browser-level route may apply to much more than the meeting. Google Meet runs inside the browser, so a browser-wide proxy can also affect mail, documents, search, and unrelated tabs. Conversely, a system proxy may be ignored by a separately configured browser or by a native application. Use the Clash connection log to confirm the observed path, and avoid inferring behavior from the application icon or from a single browser setting.

When testing audio or video problems, keep the call conditions consistent. Use the same network connection, meeting, device, and approximate test duration when comparing two routes. Temporarily disable bandwidth-heavy downloads or cloud backups, but do not disable required security software. If the problem only occurs on office Wi-Fi, compare the result with a permitted alternate network and ask IT whether firewall policy, a required corporate VPN, or managed DNS is involved. These comparisons can narrow the cause without turning every failure into a proxy-rule problem.

Keep calls stable and troubleshoot common symptoms

A useful work profile should be predictable, not merely capable of reaching a meeting service. Prefer a stable, authorized proxy group over a group that changes exits frequently during a call. Changing the exit route between a sign-in request and a long-running session can create confusing behavior, and rapid node switching makes a controlled diagnosis difficult. If you use automatic selection, understand how often it tests and changes the active member; avoid changing group strategy while a call is in progress.

If Zoom or Meet opens but the call shows “connecting,” freezes, or loses media, first determine whether the service is using UDP or falling back to another transport. Some proxy paths support TCP but not UDP, and a web page loading successfully says nothing about UDP forwarding. Do not assume that adding more domains will solve a transport limitation. Check the client’s documentation for supported UDP behavior, inspect the connection log, and use a route that your provider and organization explicitly support. If the application requires a corporate network path, follow the organization’s instructions instead of trying to imitate that path with unrelated rules.

If authentication loops or the desktop app cannot complete sign-in, inspect the browser and application as separate clients. The browser may open an identity page using one route while the installed app waits for a local callback or contacts a different service. Check whether the callback returns to the expected application, whether the local listener is available, and whether another proxy or VPN is intercepting loopback traffic. Keep localhost and loopback addresses on their intended local path; sending local callbacks through a remote proxy can break authentication rather than improve it.

If Slack reconnects repeatedly while meetings remain healthy, investigate Slack’s own route and WebSocket behavior instead of broadening the video rules indiscriminately. Long-lived connections can be affected by idle timeouts, unstable exits, or a network that closes sessions aggressively. Likewise, if only screen sharing fails, check the application permissions and the organization’s sharing policy before changing routing. macOS and Windows can deny screen capture or microphone access independently of Clash, and a routing change cannot grant a missing operating-system permission.

DNS deserves particular attention when rules appear inconsistent. Depending on the profile and DNS mode, Clash may receive a hostname directly, use a synthetic address, or make a decision based on information available at a different point in the connection. A stale DNS cache can also make a test appear unchanged after a rule edit. Use the client’s supported DNS controls and logs, avoid mixing multiple DNS overrides without a reason, and restart only the relevant application or resolver after a change. Do not publish screenshots or logs containing subscription URLs, authentication tokens, meeting links, or private internal hostnames.

Finally, keep the configuration maintainable. Name policy groups clearly, comment on unusual exceptions, and remove temporary test rules once they are no longer needed. Remote rule providers can change their contents, so a profile that worked last month may behave differently after an update. After refreshing a profile, repeat a brief call test before an important meeting if the route is business-critical. For recurring problems, collect timestamps, affected applications, relevant non-sensitive log entries, and the exact test conditions; this gives your network administrator or provider something more useful than “the internet is slow.”

A basic system-proxy toggle in another desktop client may be quicker for one browser, but it can leave native meeting apps, UDP media, and local-network exceptions difficult to inspect. Clash is more useful when you need visible policy groups, ordered rules, and connection logs to see which route a call actually takes—provided your organization permits it and the chosen core supports the behavior you need. Once the route is tested against real calls rather than guessed from a status light, you can keep Zoom, Google Meet, and Slack on an intentional path while leaving local browsing direct. If that level of rule visibility fits your workflow, visit the Clash V.CORE download page and choose the supported client that matches your desktop setup.