Start Here: Identify What Is Failing
When Discord stays on “Connecting”, messages do not load, or a voice call repeatedly reconnects, Clash may be involved—but the symptom alone does not identify the cause. Discord uses several kinds of traffic: HTTPS for its web API and much of its text and media activity, WebSockets for live updates, and UDP for voice. A rule can send one part of the connection through a proxy while another part takes a different route. A proxy node may also carry ordinary web traffic but fail to forward the UDP packets needed for a stable call.
The useful first step is to separate the failure into a few categories. Does Discord fail only when Clash is running, or does it also fail with Clash completely closed? Can you send and receive messages but not join voice? Does a voice call connect briefly and then drop? Do images and attachments fail while text works? Each pattern points to a different layer: routing, DNS, proxy-node health, UDP support, or an operating-system network mode such as TUN.
Before changing configuration, record the active profile, selected proxy group, Clash mode, and whether TUN mode is enabled. Change one setting at a time and repeat the same test. This makes it much easier to undo a change that does not help, and prevents several simultaneous edits from hiding the real cause.
Quick Isolation Test
Compare Discord with Clash off, with Clash in Rule mode, and with a known-good node selected. If the problem occurs only through one node or one mode, focus on that route before editing DNS or reinstalling the client.
1Check Discord Routing and DNS
In Rule mode, Clash applies rules in order. A broad rule near the top of a profile can capture Discord traffic before a more specific Discord rule is reached. For example, a rule that sends a large category of domains to DIRECT may take precedence over a later rule intended to use your proxy group. The last rule in a configuration is commonly a catch-all such as MATCH; Discord-specific rules need to be placed before that final catch-all to be considered.
First, open the connection or rule log in your client while loading Discord, sending a message, or joining a voice channel. In Clash Verge or Clash Verge Rev, inspect the active connections and identify the rule and policy group selected for Discord-related requests. Client labels differ between versions, but the important information is the matched rule, the selected policy, and whether the connection succeeds. If the request is being sent to an unexpected group, select the intended group in the rule or policy view, or correct the rule order in the profile.
If your profile permits custom rules, a small set of domain rules can help route Discord’s commonly used service and media domains consistently. Replace PROXY with the exact name of a proxy group in your configuration. If you intend Discord to connect directly, use DIRECT instead. Do not add both variants at once: choose one routing strategy and test it.
These rules are examples, not a guarantee that every connection uses only these domains. Discord can change service endpoints, and a profile may use rule providers or generated rules that override local edits. If your client manages a subscription profile, an update may replace manual changes. Use a supported override or custom-rules feature when available, and confirm in the connection log that the desired rule actually matches. Avoid adding guessed IP ranges: service IPs can change, and an overly broad IP rule can route unrelated traffic incorrectly.
Test DNS Without Rebuilding the Profile
DNS can produce a different symptom from an incorrect proxy rule. A stale cached answer, a failed resolver, or a DNS request handled outside the intended Clash path may prevent Discord from reaching the right endpoint. If only Discord has trouble, begin with the client’s connection log and DNS status rather than replacing the entire DNS configuration. Restart Clash after a DNS change, then fully quit and reopen Discord so that it requests fresh connections.
In Mihomo-based clients, DNS settings may include options such as enable, enhanced-mode, and upstream nameserver entries. The correct values depend on the profile, operating system, and network. Do not copy a generic DNS block over a working profile without understanding how its current settings are used. If DNS is disabled intentionally, or your profile has a provider-specific DNS configuration, changing it casually can break other services.
A Helpful DNS Check
If the connection log shows repeated resolution failures, test the same Discord action after restarting the core and refreshing the DNS cache. If name resolution succeeds but the connection times out, investigate the matched route, node, or UDP handling instead.
2Run a Controlled Test in Clash
Use the following sequence to narrow down the fault. Keep the Discord account, device, network, and test action the same where possible. For voice testing, join the same channel and speak briefly; for text testing, send a short message and load one image or attachment. A repeatable test is more useful than switching many settings and relying on whether Discord “feels faster.”
- Check Discord without Clash. Quit Clash completely, not just minimize it, and test whether Discord can connect on the ordinary network. If it still fails, the cause may be Discord itself, the local network, a firewall, or an account/client issue rather than a Clash rule.
- Start Clash and use Rule mode. Confirm that the intended profile is active and that Discord requests appear in the connection log. Note the matched rule and policy group instead of assuming the app is using the route you expect.
- Select a known-good node. Choose a node that successfully loads other sites, then retry the same Discord action. If messages begin working, but voice does not, continue with the UDP checks below; a working HTTPS connection does not prove that voice transport works.
- Compare another node or group. Use a second node from a different location or provider, if available. If the failure follows one node, suspect node reachability, congestion, filtering, or unsupported UDP rather than the Discord desktop client.
- Use Global mode briefly as a routing diagnostic. If Discord works in Global mode but not Rule mode, the problem is likely a rule match, rule order, or policy selection. Return to Rule mode after the test; Global mode is not necessary as a permanent fix.
- Test voice separately. Once text and media work, join a voice channel. Watch the client’s connection status and Clash log. A voice-only failure points toward UDP forwarding, network restrictions, or a route mismatch more strongly than a general DNS failure.
When testing a profile change, save a copy of the original configuration or note the value you changed. In Clash Verge Rev, profile editing and rule management can vary depending on whether the active profile is local or subscription-based. If editing the downloaded YAML is not preserved after an update, use the client’s supported override mechanism rather than repeatedly patching the generated file.
On Windows and Linux, TUN mode can capture traffic that does not follow the system proxy settings. On macOS, the system extension or network permission state may affect traffic capture. If Discord appears in the log only with TUN enabled, compare with TUN temporarily disabled and the system proxy enabled, where that setup is appropriate. If the behavior changes, check the client’s permissions, route handling, and other VPN or firewall software. Do not run two traffic-capturing tools at the same time while diagnosing; overlapping adapters can make results misleading.
Do Not Treat Global Mode as the Final Fix
Global mode can show whether rule matching is involved, but it sends more traffic through the selected proxy. After the comparison, identify the specific route that failed and return to your normal mode.
3Fix Voice Calls, UDP, and Unhealthy Nodes
Discord voice is more sensitive to packet loss and routing changes than ordinary text. Voice traffic commonly relies on UDP, and the client may negotiate media connections separately from the HTTPS and WebSocket connections used elsewhere in Discord. A node can therefore load messages successfully while voice remains stuck on “RTC Connecting,” fails to establish a route, or disconnects after a short period.
Check whether the selected proxy protocol and node support UDP forwarding, and verify that UDP is enabled where your client and profile expose that option. The exact setting depends on the proxy protocol and provider; a configuration switch cannot make a server support a transport it does not offer. Consult the node provider’s documentation if the client reports that UDP is unavailable. If your network blocks UDP, testing another node or network can help distinguish a local restriction from a node limitation.
Do not assume that adding a domain rule will fix every voice issue. Domain rules help choose a policy for traffic that Clash can associate with those domains, but successful voice transport also depends on the core, proxy protocol, node, and network path. Review live connections while joining voice and look for failed UDP activity, repeated retries, or traffic that is assigned to a different policy than the rest of Discord. If the client does not display UDP connections clearly, compare the same call with a node known to support UDP and check the core logs for transport errors.
Choose a Route Based on the Test
| Observed result | Likely area to check | Next action |
|---|---|---|
| Discord works with Clash off, but fails in Rule mode | Rule match, rule order, or policy group | Inspect the connection log and correct the matching rule or selected group |
| Discord works in Global mode, but not Rule mode | Rule-based routing | Use Global mode as a diagnostic only; fix the rule that captures Discord traffic |
| Messages work, but voice cannot connect | UDP support, node capability, or network filtering | Try a UDP-capable node and verify the protocol and client configuration |
| One node fails while another works | Node reachability, congestion, or filtering | Keep the working node selected and report the failing node to its provider |
| DNS errors appear before connections are created | Resolver, cache, or DNS routing | Restart the core, refresh the cache, and review the active DNS settings |
For a fair node comparison, test at a similar time and avoid changing the routing mode at the same time as the node. A slow node may make voice sound robotic or cause a fluctuating connection indicator even when the call technically joins. Try a nearby, stable node rather than choosing one solely by its advertised maximum speed. For voice, consistency and low packet loss are usually more important than peak download throughput.
If none of the routes work, temporarily test Discord on a different network, such as a mobile hotspot, where permitted. If voice works there, the original network or its firewall may be restricting UDP. If it fails across networks but works without Clash, focus on the proxy node, protocol, and UDP support. If it fails both with and without Clash, check Discord service status, update the Discord client, and review local firewall or security software settings before making more profile changes.
Frequently Asked Questions
Should I leave Clash in Global mode to make Discord work?
Usually, no. Global mode is useful as a short diagnostic comparison because it can reveal that a rule or policy group is responsible. It may also route unrelated apps through the proxy and can add latency. Once you know that Rule mode is the problem, inspect the matched Discord rule and correct its route. Keep your normal operating mode unless you have a specific reason to use Global mode.
Why do messages work while voice calls fail?
Text and much of Discord’s web activity can use HTTPS, while voice requires a suitable real-time media path and commonly depends on UDP. A proxy that handles web requests may not support UDP forwarding, or the current network may block it. Try a node that explicitly supports UDP, check the client and profile settings, and inspect connection or core logs while joining a call.
Will switching to fake-IP DNS fix Discord?
Not necessarily. Fake-IP is one DNS mode used by Mihomo-based configurations, but changing to it will not fix a node that cannot forward UDP, a rule that selects the wrong group, or a network firewall that blocks the connection. First check whether the logs show resolution failures. Change DNS only when the evidence points to DNS, and preserve the original settings so you can revert safely.
Should I reinstall Discord or replace my whole Clash profile?
Reinstalling is rarely the best first step when the problem appears only while Clash is active. Begin with the off-versus-on comparison, route logs, node selection, and voice UDP support. If Discord also fails without Clash, then updating or repairing the Discord client may be reasonable. Avoid replacing a complete profile to solve one routing problem; a targeted, reversible change is easier to verify and less likely to disrupt other apps.
Once the failing layer is identified, keep the fix narrow: correct one rule, choose a stable node that supports the required traffic, or adjust DNS only when resolution is demonstrably failing. Re-test messages and voice separately after any profile update, because a subscription refresh can change rules or node behavior.
Download Clash for your platform and get started with a client suited to your setup.