Fix YouTube Buffering on Clash: Troubleshoot Slow or Stuck Videos

If YouTube keeps buffering on Clash, the cause is not always a slow proxy node. Playback depends on several separate steps: the browser must reach YouTube’s page and API endpoints, the video player must fetch media segments from Google’s delivery network, and Clash must send each connection through the route you intended. A working home page does not prove that video traffic is using the right proxy, while a low ping does not prove that a node can sustain video throughput. This guide helps you isolate proxy mode, routing rules, DNS, node performance, and client-side issues one change at a time.

Start With the Symptoms

Before changing configuration, note what the failure looks like. A video that never starts, a player that begins and then pauses, and a video that plays at low resolution can point to different problems. Also check whether the issue affects every video, only higher resolutions, only one browser, or only one network. These details help distinguish a routing error from congestion or a local playback problem.

Use a short, repeatable test: choose one video, keep the resolution fixed, and observe playback for a few minutes. Record the selected node, proxy mode, and whether the problem appears immediately or after playback begins. If several settings are changed together, it becomes difficult to tell which change helped—and a temporary improvement may be mistaken for a real fix.

Check Proxy Mode and Routing Rules

Clash clients commonly offer rule-based, global, and direct modes, although labels and menus differ between Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, and other Mihomo-based clients. In Rule mode, each connection follows the first matching rule. In Global mode, connections are generally sent through the selected proxy group. In Direct mode, traffic bypasses the proxy. A quick comparison between Rule and Global mode can help identify whether a routing rule—not the node itself—is responsible.

1. Open YouTube and begin playback so the client creates active connections.
2. Open the client’s Connections, Logs, or equivalent view. Find the video-related connection and inspect its destination and matched rule.
3. Look for connections to domains such as youtube.com, googlevideo.com, and ytimg.com. The exact set varies by page, account state, and playback request.
4. Confirm that the media connection uses the intended proxy group or node. If the main site is proxied but the media connection is direct, the two paths may behave very differently.

For a short diagnostic test, switch from Rule mode to Global mode and use the same node. If playback becomes reliable, inspect the rules that matched the affected connections. This is a test, not necessarily the best permanent configuration: Global mode may proxy traffic that you normally want to send directly, and it can increase bandwidth use.

When a rule change is appropriate, place a narrow YouTube-related rule before broader rules that might capture the same traffic. The following is a simplified example for a configuration where a proxy group named YouTube already exists:

rules:
  - DOMAIN-SUFFIX,youtube.com,YouTube
  - DOMAIN-SUFFIX,googlevideo.com,YouTube
  - DOMAIN-SUFFIX,ytimg.com,YouTube
  - MATCH,Your-Final-Group

Rule names are case-sensitive in practice because they must refer to an existing proxy group in your profile. Replace YouTube and Your-Final-Group with the names actually used by your configuration. If your profile is subscription-managed, avoid editing a generated file that will be overwritten at the next update. Use the client’s supported override, merge, or rule-editing feature instead. Do not add broad rules for all Google domains unless you have confirmed that this is what you want; they may change the route for unrelated services.

Verify DNS and Connection Capture

DNS problems can make YouTube appear partly reachable. The page may load from one set of addresses while the player requests media from another hostname or content-delivery endpoint. A local DNS resolver, a stale cache, or a mismatch between the browser’s DNS path and Clash’s DNS handling can result in inconsistent connections. DNS is worth investigating when the site loads but video requests fail, when the problem changes after reconnecting, or when different devices on the same profile behave differently.

Start with the least disruptive checks. Confirm that Clash’s DNS feature is enabled if your profile relies on it, and verify that the client is actually using the profile you edited. Restart the browser after changing DNS-related settings so existing connections and cached answers do not obscure the result. If your browser has Secure DNS or DNS-over-HTTPS enabled, temporarily test with its default setting or a known compatible resolver. Do not leave multiple DNS overrides in place unless you understand which component is answering each request.

If your client uses TUN mode, confirm that TUN is enabled and has permission to capture traffic. On desktop systems, a system proxy may handle browsers that respect operating-system proxy settings, while TUN mode can capture a wider range of applications. These are different traffic paths. A browser that bypasses the system proxy, or an application excluded from TUN capture, may not follow the same rules as other traffic. On mobile devices, check the VPN permission and whether battery or background restrictions are interrupting the proxy connection.

After any DNS or capture change, reconnect Clash and start a new video session. Existing browser connections may continue using an old route, so simply refreshing the visible page is not always enough. If the change does not alter the matched connection or playback behavior, restore the prior setting and continue testing another cause rather than accumulating speculative DNS servers or filters.

Test Node Speed and Network Stability

A node’s displayed delay or ping is only a limited measurement. It usually estimates how quickly a small test request completes; it does not show whether the node can continuously transfer a large video stream. YouTube playback needs both adequate throughput and a stable connection. A node may have excellent latency but still buffer under load, especially during busy periods or when its route to Google’s video delivery network is poor.

Use the same video, resolution, device, and network while comparing nodes. Give each node enough time to test sustained playback; switching repeatedly every few seconds can leave old connections alive and make results misleading. If one node consistently works while another does not, the issue is likely related to the node or its route rather than a general YouTube setting. If all nodes fail on one Wi-Fi network but work over mobile data, investigate the local network, router, or ISP path as well.

• Test more than one node, including a nearby option and a node in another region if available.
• Check whether the problem is worse at a particular time of day, which can indicate congestion.
• Pause large downloads, cloud backups, game updates, and other streams during the comparison.
• Try Ethernet or move closer to the Wi-Fi access point to rule out weak wireless signal and interference.
• Compare a moderate resolution with the resolution that usually buffers. A lower setting is a diagnostic, not proof that the proxy is fixed.

Proxy groups can help identify a consistently poor node, but their health checks should not be treated as video-throughput tests. A url-test group measures a configured test URL and may select the node with the lowest test latency, not necessarily the node that performs best for YouTube. For diagnosis, manually select a node and observe actual playback. If you use automatic selection, check whether the selected node changes between tests and whether the buffering begins after a switch.

Also consider transport conditions on the client side. Packet loss, an unstable mobile connection, an overloaded router, or a VPN conflict can interrupt long-lived media connections even when a speed test briefly reports a high peak. Avoid changing MTU or advanced transport parameters as a first step. Such changes can create new failures, and they are best considered only when ordinary node, route, and network comparisons point to a packet-size or fragmentation problem.

Rule Out Browser and Client Issues

If only one browser is affected, test a private window and temporarily disable extensions that filter scripts, ads, or network requests. Clear site data for YouTube only if the simpler test suggests a browser-state problem. Then compare playback in a second browser on the same device with the same Clash mode and node. If both browsers fail in the same way, focus on Clash routing or network performance instead of repeatedly clearing browser data.

Check that the browser is not configured with a separate proxy that conflicts with Clash. Some browsers and privacy tools can use their own proxy or DNS settings, resulting in traffic that bypasses the system proxy or follows a different path. Conversely, browser extensions may intercept requests even though Clash routes them correctly. Temporarily disabling one extension at a time is more useful than disabling every privacy or security control permanently.

On desktop clients, verify that the active profile is the one you expect and that the system proxy or TUN mode matches your test. On Android, confirm that the Clash VPN service is active and that no other VPN app has taken its place. On macOS, Windows, or Linux, check for another VPN, firewall, or endpoint-security tool that may filter or redirect traffic. If a client update recently changed behavior, test with a clean restart and review its connection log before replacing the entire profile.

Finally, avoid relying on a single speed-test result. A speed test may use a different destination, connection type, and server than YouTube’s video delivery. Use it as supporting evidence only. The more relevant test is sustained playback through the exact node and route you intend to use.

A Practical Troubleshooting Sequence

Work through the checks in order and keep a record of each result. This limits unnecessary configuration changes and usually makes the source of the problem clearer:

1. Choose one video and note the current mode, node, resolution, browser, and network.
2. Check the client’s active connections while the video is buffering. Identify the rule and proxy group used by the media connection.
3. Compare Rule mode with Global mode using the same node. If only Global works, review rule order and profile overrides.
4. Manually test at least two nodes while keeping all other settings unchanged. Compare sustained playback, not just ping.
5. If the site loads but media connections fail, review DNS handling, browser Secure DNS, and whether TUN or the system proxy is capturing the browser’s traffic.
6. Test another browser or network. This helps separate a local browser or Wi-Fi issue from a profile or node issue.
7. Apply one targeted change, reconnect Clash, start a fresh video session, and repeat the same test.

When a test does not improve playback, undo the change before moving on. Keep configuration edits small and specific, especially in subscription profiles where local changes may be replaced during an update. Once playback is stable, restore your preferred routing mode and confirm that other services still use their intended routes.

Frequently Asked Questions

Why does YouTube load but the video keep buffering?

The page and the video stream can use different hostnames and connections. The main page may match a proxy rule while a media connection to a video-delivery domain is sent direct, routed through another group, or blocked by an inconsistent DNS result. Inspect the connection view during playback and check which rule matched the media request.

Will choosing the node with the lowest ping fix buffering?

Not necessarily. Ping measures response time for a small test request, while video playback depends on sustained throughput, packet loss, congestion, and the route to the media server. Compare actual playback on several manually selected nodes. The node with the lowest latency is not always the one with the most stable video stream.

Should I use Global mode permanently?

Global mode is useful as a diagnostic because it can show whether rule-based routing is involved. It may not suit everyday use if you want local, private, or specific regional traffic to go direct. If Global mode fixes playback, identify the unmatched or incorrectly routed YouTube-related connection and make a narrow rule change where your client and profile support it.

Should I change DNS or MTU first?

No. Begin by checking the matched route and comparing nodes, because these tests are easy to reverse and often reveal the cause. Investigate DNS when the page works but media requests fail or results vary across sessions. Consider advanced settings such as MTU only when other evidence points to a transport problem, and change one parameter at a time.

Most YouTube buffering issues on Clash can be narrowed down by following the connection itself: confirm which rule catches the video traffic, compare real playback across nodes, then investigate DNS and local capture only when the evidence supports it. Once you find the cause, make the smallest change that addresses it and repeat the same test. That approach is more reliable than adding broad rules or changing several network settings at once.