Why YouTube buffering is not always a bandwidth problem
If you searched for Clash YouTube buffering, YouTube slow playback through proxy, or “Clash makes YouTube videos keep loading,” you probably already performed the obvious checks: the Wi-Fi icon looks normal, a speed test reports acceptable download bandwidth, and other websites open without drama. Yet YouTube may still pause every few seconds, fall back to a low resolution, or take a long time to start a video. That pattern does not automatically mean your internet connection is slow.
Video playback depends on more than a single download-speed number. YouTube may use different hostnames for page data, video manifests, thumbnails, captions, advertisements, and media segments. A Clash rule can send one part of that session through a proxy while another part goes DIRECT. The selected node may also have enough capacity for a short web request but become unstable when it must maintain a high-volume HTTPS stream for several minutes. DNS resolution, fake-IP behavior, TUN capture, MTU, and QUIC support can add another layer of symptoms.
This guide gives you a controlled troubleshooting process for Clash clients based on Mihomo, including Clash Verge Rev, Clash Verge, and compatible desktop clients. The goal is not to force every connection through a proxy immediately. Instead, you will establish a baseline, compare Clash modes, inspect actual connections, verify routing rules, test DNS and TUN settings, and decide whether the fault belongs to your configuration, your node, or your provider.
Use the process in order. Changing five settings at once can make a buffering problem appear to disappear while leaving the actual cause unknown. A useful diagnosis should be repeatable: the same video, the same time window, the same node, and the same observable result.
Create a reliable baseline before changing Clash
Start with a video that reproduces the problem consistently. A short, popular clip is useful for a quick test, but a longer 1080p or 4K video reveals sustained throughput and stability problems more clearly. Note the initial resolution, the time required before playback starts, whether the buffer indicator drains during playback, and whether the issue appears only after several minutes. Avoid judging performance from an advertisement because ad delivery and video delivery may use different paths.
Next, test the same browser and video with Clash completely disabled. Do not merely change from Rule mode to DIRECT if the client still owns a TUN interface or system proxy setting. Confirm the operating system proxy state, close and reopen the browser if necessary, and then replay the video. This produces a useful comparison:
- Buffering both with and without Clash: investigate the local connection, Wi-Fi interference, router load, browser extensions, ISP congestion, or the YouTube service region before editing proxy rules.
- Buffering only when Clash is active: focus on the selected node, routing policy, DNS behavior, TUN capture, and transport compatibility.
- Buffering only with one browser: compare extensions, secure DNS settings, hardware acceleration, and browser-specific proxy handling.
- Buffering only at certain hours: suspect congestion on the node, the provider’s upstream route, or peak-time traffic shaping rather than a permanent local configuration error.
Use the browser’s statistics for nerds panel when available. In YouTube, right-click the video and open Stats for nerds. Watch the current and optimal resolution, connection speed, buffer health, and dropped frames. A low connection speed with normal buffer health may simply reflect YouTube’s adaptive algorithm. A rapidly falling buffer health value while the player repeatedly changes quality points more strongly toward throughput instability or packet loss.
Do not compare a raw speed-test result with YouTube as if they were the same workload. Speed-test servers are selected for proximity and may use multiple parallel connections. A proxy node can perform well against that server while having a poor route to YouTube’s media CDN. Conversely, a node can be excellent for video while looking average in a generic test. The useful measurement is the application behavior through the exact path you intend to use.
Compare Rule, Global, and DIRECT modes
Clash mode changes are diagnostic tools, not permanent recommendations. First use Rule mode with your normal profile. Start the video, wait for the buffering symptom, and open the client’s Connections or Logs panel. Search for YouTube-related hostnames and record the process, domain, destination, rule matched, and proxy group. Names can vary by client and profile, but you are looking for evidence rather than guessing from a domain list copied from an old tutorial.
Then perform a controlled Global mode test. Select a proxy group or a specific node that you know is usable, clear the browser tab, and replay the same video. If Global mode immediately improves playback while Rule mode remains poor, the node may be fine and the rule set may be sending part of the YouTube session DIRECT. Global mode can also hide a DNS or split-routing issue because it forces more traffic through one path, so treat the result as a clue.
- Rule works and Global works: your current policy is probably adequate. Avoid unnecessary changes and test another video before concluding that everything is perfect.
- Global works but Rule fails: inspect matched rules, rule order, domain suffix handling, and whether media hostnames are classified differently from the main YouTube site.
- Both proxy modes fail but DIRECT works: test another node, check node bandwidth and latency, and inspect whether the provider restricts streaming traffic.
- DIRECT fails while Global works: the local or ISP route may be congested, filtered, or geographically inefficient. A proxy can help, but choose rules that do not unintentionally proxy unrelated local services.
When reading Connections, remember that the visible page hostname may not be the hostname carrying the video segments. You may see entries related to youtube.com, www.youtube.com, googlevideo.com, ytimg.com, or other Google-owned delivery domains. The exact set changes with region, browser, account state, and player behavior. Do not add broad Google rules just because one request appeared in the log; identify which connection remains active while the buffer drains.
Rule order matters. A broad GEOIP,CN,DIRECT, a process rule, a private-network rule, or an earlier catch-all can run before your intended YouTube policy. Put specific domain rules above broad fallbacks when your profile supports local overrides. Keep the change narrow and testable. A useful override should answer one question: does routing the relevant YouTube delivery traffic through the selected group improve sustained playback?
Determine whether the node or provider is the bottleneck
Once you confirm that Clash is routing the intended connection, test at least three nodes from different regions or groups. Use the same video, resolution target, and approximate test duration. Do not rely only on the latency number shown in the proxy list. A node with a low ping can still have poor international transit, limited throughput, aggressive concurrency limits, or a crowded egress address that performs badly with video services.
For each node, record startup time, stable resolution, buffer health, and whether playback deteriorates after five to ten minutes. A useful comparison table in your notes might include:
- Node identity and region: record the group and the actual selected server, not only a nickname such as “auto.”
- Time of test: peak-hour performance often exposes capacity problems that a morning test misses.
- Startup delay: a slow first load can indicate DNS, TLS, or initial route problems.
- Sustained playback: note whether the player can maintain the desired resolution rather than only starting quickly.
- Disconnect or retry behavior: repeated connection resets suggest instability, transport incompatibility, or provider-side limits.
If one node performs well and another buffers under identical conditions, the profile and browser are less likely to be the main problem. Remove the poor node from the active group or use a health-check strategy that measures more than latency. If every node from one provider shows the same behavior while nodes from another provider work, contact the first provider with timestamps and node names. Ask about streaming capacity, congestion, and service restrictions rather than simply requesting “a faster server.”
A provider may advertise a high port speed that is shared among many customers. The number does not guarantee that a single user will receive stable YouTube throughput. Some services also apply traffic policies to video delivery, UDP, or long-lived connections. You should respect the provider’s terms and local law; do not attempt to bypass an explicit service restriction by repeatedly rotating nodes or adding increasingly broad rules.
When a node is stable for ordinary websites but unstable for video, check whether the proxy protocol and transport are appropriate. TCP-based paths are often easier to diagnose, while UDP or QUIC behavior may vary across networks. A browser can attempt HTTP/3 over QUIC, and the route may fail or degrade even though ordinary HTTPS requests succeed. A temporary browser test that disables HTTP/3, where the browser exposes that option, can help classify the issue. If playback becomes stable only after that test, investigate UDP handling and TUN support instead of permanently blaming DNS.
Check DNS, TUN, and connection capture settings
DNS problems often look like slow video because the player waits for a hostname to resolve or receives an unsuitable CDN address. In Clash, confirm that DNS is enabled in the way your client expects and that the selected resolver is reachable. If you use fake-IP mode, make sure the client, browser, and operating system are not simultaneously applying another secure DNS layer that bypasses or conflicts with Clash. Browser DNS-over-HTTPS can create a path that differs from the system resolver, making your logs harder to interpret.
Change one DNS variable at a time. For example, compare the current resolver with a trusted alternative, restart the affected browser session, and repeat the same playback test. If the first connection becomes faster but sustained playback remains poor, DNS was only part of the issue. If the selected CDN or address changes and the problem disappears consistently, keep the simpler resolver configuration and document the successful setting. Do not treat a public resolver as automatically faster or more private; availability, policy, and geographic placement all matter.
TUN mode is useful when an application does not honor the system proxy, but it also increases the number of components involved. Verify that:
- The TUN interface is actually running and has permission to start.
- No second VPN, firewall filter, or security product is competing for packet capture.
- IPv4 and IPv6 handling are intentional rather than accidentally split.
- The client’s auto-route and strict-route options match your operating system and network design.
- The browser is not using a separate proxy profile that bypasses the path you are testing.
If YouTube works with the system proxy but buffers with TUN enabled, disable TUN temporarily and compare again. That does not mean TUN is defective. It may indicate an MTU issue, a route conflict, an IPv6 leak, or a transport path that the TUN stack handles differently. If TUN is necessary for other applications, re-enable it after each focused test and adjust only the setting supported by your client’s documentation.
MTU problems usually affect more than one website, but video streaming can make them obvious because it transfers data continuously. Symptoms may include a video that starts normally and then stalls, repeated TLS retries, or connections that work only at a lower resolution. Avoid copying a random MTU number from a forum. Compare the same node with and without TUN, check whether other large downloads show similar behavior, and change the value conservatively if your client exposes a documented option.
Apply configuration changes without losing the evidence
Before editing a profile or adding an override, export or duplicate the working configuration. Keep a short change log: date, client version, mode, node, DNS setting, TUN state, and result. This is especially important when a subscription updates automatically and overwrites local edits. If your client supports a separate local override file, use it for narrow changes and keep the provider-managed base profile untouched.
Make one change per test cycle. A sensible order is to confirm the node, verify the matched rule, test Global mode, test DNS, and only then investigate TUN or transport behavior. After each change, restart the browser tab or player session so existing connections do not continue using an old route. Some clients also retain connection pools after a mode switch; clearing active connections or restarting Clash can make the comparison cleaner.
Do not paste a complete subscription URL, authentication token, or private server address into a public screenshot. When sharing diagnostic evidence, redact credentials and identify only the relevant rule result, error message, timing, and client version. A good report says “video segments through node group A fall from 8 Mbps to zero after four minutes in Rule mode; Global mode remains stable,” not merely “YouTube is slow.”
There is also a practical boundary to configuration troubleshooting. If playback is stable without Clash, stable through one provider, and consistently poor through another, more YAML editing is unlikely to create capacity that the node does not have. Choose the reliable route, request a provider-side investigation, or leave YouTube on DIRECT if that is the best path for your location and use case.
Frequently asked questions
Why does YouTube work in Global mode but buffer in Rule mode?
Global mode sends traffic through the selected proxy group, while Rule mode evaluates each connection against the profile’s rule order. YouTube’s page, thumbnails, API requests, and video segments may use different domains. If a specific media connection matches DIRECT or an unsuitable group, playback can buffer even though the main page loads. Inspect the active Connections entries during the failure and create a narrow, higher-priority rule only after confirming which hostname is responsible.
How can I tell whether my Clash node is too slow?
Compare several nodes using the same video and test duration. Look at sustained playback, buffer health, and resolution stability rather than only ping. If one node works for ten minutes while others stall after a few minutes, the node or its upstream route is the likely bottleneck. If all nodes from one provider behave the same way but another provider does not, the provider’s capacity or streaming policy deserves investigation.
Can changing DNS permanently fix YouTube buffering?
It can fix slow or unsuitable hostname resolution, but DNS does not add bandwidth to a congested proxy node. If changing DNS improves startup time but the buffer still drains during playback, continue investigating the node, routing path, transport, and TUN settings. Keep the DNS configuration that is reliable and compatible with your privacy and network requirements rather than choosing a resolver only because it appears in a popular configuration snippet.
Should I leave TUN mode enabled for YouTube?
Use TUN when you need transparent capture for applications that ignore the system proxy. For a browser that already follows the system proxy, TUN is not automatically necessary. If TUN introduces buffering, compare it with a system-proxy-only test and inspect route conflicts, IPv6 behavior, MTU, and competing VPN software. The best setting is the one that produces a stable, observable path for your device, not the one that appears most advanced.
Some one-click VPN tools hide rule matches, DNS decisions, node identity, and sustained connection behavior, so they make it difficult to distinguish a congested server from a misrouted request. Clash requires more deliberate setup, but its Rule and Global modes, searchable Connections view, group selection, DNS controls, and optional TUN capture give you evidence you can act on. If you want that visibility while testing YouTube playback across devices and nodes, a compatible Clash client is a practical next step.