Fix YouTube Buffering in Clash: Troubleshoot Slow Streaming

Start with the Symptom: What YouTube Buffering Actually Tells You

YouTube buffering through Clash is not automatically proof that your subscription is dead. A video can pause because the selected node has poor sustained throughput, because YouTube traffic is being routed through an unsuitable policy group, because DNS returned an unreachable edge address, or because your browser is not using the proxy mode you believe is active. The first useful step is therefore to describe the failure precisely instead of changing five settings at once.

Notice whether the problem affects every video or only high-resolution playback. A 360p clip that starts quickly but stalls at 1080p usually points toward limited bandwidth, congestion, or a weak node rather than a complete routing failure. If YouTube loads its homepage but the player remains black, inspect browser extensions, DNS behavior, and blocked media domains. If the page itself never opens, begin with proxy mode, system proxy state, and connectivity to the selected server. A video that plays for several minutes and then pauses repeatedly often indicates unstable throughput, an overloaded exit, or a connection that is being reset during longer streaming sessions.

Run a clean comparison before editing YAML. Disable Clash temporarily and test the same video over the ordinary connection, then enable Clash again and repeat it with one different node. Keep the browser, video quality, and test time consistent. This simple A/B test separates a local browser problem from a proxy-path problem. Also check whether only one browser is affected. Chrome, Edge, Firefox, and Chromium-based clients can use different proxy extensions, encrypted DNS settings, or operating-system integration, so “YouTube is slow” may actually mean “one browser is bypassing the route I intended.”

Check Proxy Mode, Browser Coverage, and Local Ports

The most common mistake is testing YouTube while Clash is running in a mode that does not cover the browser. In system proxy mode, the client typically writes HTTP and HTTPS proxy settings to the operating system. Desktop browsers may honor those settings, but a browser extension, a manually configured profile, or an application-specific bypass can override them. In rule mode, YouTube requests are evaluated against your rules and then sent to the selected policy group. In global mode, nearly everything follows the chosen proxy group, which is useful for diagnosis but not always desirable for normal use. In direct mode, the browser bypasses the proxy entirely.

Open the Clash dashboard and confirm that the running profile is the one you edited. It is easy to change a downloaded YAML file while the client is still using an older profile generated by a subscription. Confirm the active mode, the selected proxy group, and the local mixed port. If your client displays connection logs, open YouTube in a new private window and watch for requests while the video starts. You should see browser traffic appear in the log. If there are no relevant entries, the browser is probably bypassing Clash, the system proxy is disabled, or the application is using a different port.

A browser extension configured for a SOCKS port can also create confusing results. For example, Clash may listen on a mixed port while the extension points to an old SOCKS port, or the extension may send only ordinary page requests through the proxy while media connections use a separate path. During troubleshooting, avoid stacking a proxy extension on top of system proxy mode unless you understand exactly which layer owns the request. Use one method at a time, restart the browser after changing it, and remove stale PAC settings that may direct selected domains to DIRECT.

TUN mode changes the diagnostic picture because it captures traffic below the browser’s normal proxy settings. If TUN is enabled, verify that the virtual interface is actually running and that another VPN or network filter is not taking priority. A TUN interface can appear enabled while its service lacks permission, its DNS component is unhealthy, or an excluded application is still bypassing it. For a clean baseline, test system proxy mode first. Once YouTube works reliably there, enable TUN and compare the result instead of debugging both capture layers simultaneously.

Test Node Quality Instead of Trusting Ping Latency

A node that reports a low latency score is not necessarily a good YouTube node. Many Clash clients measure a short HTTP request or TCP handshake. Video playback is a sustained transfer that may use different hostnames, connection lifetimes, and edge locations. A server can answer a latency probe in 120 milliseconds while delivering video at an unusable rate because its egress is congested, its provider applies traffic shaping, or too many subscribers are sharing the same capacity.

Select a small set of candidate nodes from the same subscription and test them manually. Keep the video resolution fixed, wait long enough for the player to build a buffer, and observe the actual playback behavior. Useful signals include the time required to begin playback, whether the buffer grows while the video plays, and whether throughput collapses after a few minutes. Do not judge a node solely by the first ten seconds. Some routes start quickly because the initial manifest is small and then slow down when larger media segments arrive.

If your client provides connection details, inspect the hostnames requested during playback. YouTube does not rely on one universal endpoint for every function. The page, thumbnails, player configuration, manifests, and video segments may involve different Google or YouTube-related domains. The exact hostnames vary by region, account state, client version, and delivery network. A rule that matches only one familiar domain can therefore produce a split route: the page goes through the selected proxy while media traffic follows a slower or unreachable path.

Avoid aggressive automatic switching while diagnosing the issue. A url-test group may select a node with the fastest probe but poor streaming capacity, while a fallback group may move between exits after a brief probe failure and interrupt long-lived sessions. Start with a manual selector and one known candidate. After finding a stable route, you can compare it with url-test behavior. If automatic selection repeatedly chooses a node that looks fast in the dashboard but buffers in YouTube, change the probe target or use a curated streaming group rather than assuming the core is broken.

Repair YouTube Routing and DNS Without Guessing

Once you confirm that the browser reaches Clash, inspect the rule decision for the failing requests. In rule mode, look for a broad MATCH rule, an unexpected DIRECT decision, or a rule-provider entry that changed after a profile update. A common configuration mistake is placing a generic regional rule above a narrower media rule, causing YouTube-related traffic to leave through a path that is technically reachable but too slow. Another is assigning page domains to one group and media domains to another group with very different performance.

For troubleshooting, create a temporary, clearly named policy group for video testing. Route the relevant YouTube and Google media traffic consistently through that group, then compare it against DIRECT and a second proxy group. Keep the temporary rule narrow and documented. Do not blindly send every Google service through one exit, because that can create unnecessary login challenges, affect work applications, or make unrelated services slower. After the test, decide which domains genuinely need the same route and which should follow your normal policy.

DNS deserves separate attention because a successful page load does not prove that every media hostname resolved correctly. With fake-IP mode, Clash maps domain names to synthetic addresses and later associates those addresses with hostnames. If an application caches an address, uses its own encrypted DNS, or sends queries outside the resolver path, the mapping can become inconsistent. Reducing TTL values, flushing the browser’s DNS cache, or restarting the client may help after a profile change, but these actions do not repair a fundamentally incorrect DNS design.

Test resolution from the same device and under the same Clash mode. Compare the browser’s behavior with the Clash DNS log and, where available, connection metadata in the dashboard. If requests fail before a TCP connection is created, investigate resolver timeouts, fallback DNS, encrypted DNS inside the browser, and accidental DNS hijacking by another VPN. If DNS succeeds but the connection is reset after the video begins, shift attention to node stability and routing rather than repeatedly changing resolver addresses.

Browser-level secure DNS is especially easy to overlook. Chrome and Firefox may use DoH independently of the operating system, depending on policy and user settings. That can bypass the DNS strategy you configured in Mihomo or another Clash core. Temporarily disable browser-specific secure DNS for a controlled test, or configure it deliberately so that the browser and Clash do not compete. Record the original setting before changing it, and restore the preferred privacy configuration after diagnosis.

Measure Playback, Then Stabilize the Configuration

YouTube’s player statistics can provide more useful evidence than a generic speed-test website. In the player, open the detailed statistics panel and watch the current resolution, connection speed, buffer health, dropped frames, and viewport information while the video plays. The labels may vary slightly by browser and player version, but the pattern matters. A low connection speed with rising buffer loss points toward the node or route. A healthy connection speed with dropped frames suggests local decoding or hardware acceleration. A large buffer with frequent visual pauses may indicate a browser, extension, or renderer problem rather than network starvation.

Test one variable per run. Keep the same video and resolution while changing only the node. Then keep the node fixed while changing only the Clash mode. Next compare the browser’s secure DNS setting, and finally test the same route in another browser. Write down the time, node, mode, resolution, and observed behavior. This small record prevents circular troubleshooting, especially when automatic groups change selection in the background or when a provider experiences temporary congestion.

Once you identify a stable combination, simplify the configuration. Remove duplicate proxy extensions, delete obsolete system proxy entries, and ensure only one application controls the intended listener. Give the streaming group a descriptive name and avoid silently changing its members through unrelated rule-provider merges. If you use a remote profile, save local overrides in a separate file or documented patch mechanism so a subscription refresh does not erase the fix.

Also review local resource limits. Hardware acceleration problems can look like buffering when the network is actually delivering data normally. Check CPU usage, memory pressure, GPU activity, and browser extensions during playback. An old laptop may decode high-resolution AV1 or VP9 video poorly, while a browser tab with several content filters may consume enough CPU to produce stutter. Compare a lower resolution, another codec where the player permits it, and a clean private window before blaming the proxy route.

FAQ: Common YouTube and Clash Questions

Why does YouTube work in global mode but buffer in rule mode?

Global mode sends requests through one selected policy path, while rule mode can distribute them across different decisions. The difference usually indicates a rule-order problem, a domain that is not covered by your intended streaming rule, or a direct route with poor performance. Use the connection log to identify the decisions made for page, manifest, and media requests. Then create a narrow rule set that reproduces the working path without forcing unrelated traffic through it.

Why does changing nodes not help?

Node switching cannot fix a browser that bypasses Clash, a DNS resolver that returns unusable results, or a rule that sends every candidate through the same direct path. Confirm that requests appear in the Clash log and that the selected group actually changes the connection metadata. If several nodes behave identically, test the proxy mode and DNS layer before downloading another subscription.

Should I always use TUN mode for YouTube?

No. TUN mode is useful when an application ignores system proxy settings or when you need broader device coverage, but it adds another capture and DNS layer. Begin with the simplest mode that clearly covers your browser. Move to TUN only when you understand its permissions, exclusions, virtual interface, and interaction with other VPN software. A working system proxy setup is a better baseline than an unexplained TUN configuration.

Why does 720p work while 1080p buffers?

Higher resolution requires more sustained throughput and may use different media segments. The node can be reachable and responsive while still lacking enough capacity for the selected bitrate. Compare several nodes using the same resolution, inspect player statistics, and test at different times of day. If only high resolutions fail, prioritize a stable, higher-capacity route instead of repeatedly changing unrelated DNS settings.

Compared with browser-only proxy extensions, which often miss system applications, media subdomains, or long-lived connections, and generic VPN clients that provide little visibility into rule decisions, Clash gives you separate control over routing, DNS, groups, logs, and TUN capture. For YouTube troubleshooting that means you can prove whether the failure comes from the browser, resolver, policy, or node instead of guessing from a single connection button. If you want those controls in a maintained interface with clearer diagnostics and practical profile management, visit the Clash V.CORE download page and use the same measured troubleshooting process with a clean, documented configuration.