Fix Netflix Not Working With Clash: Proxy, DNS, and Rules

Diagnose Netflix problems through Clash in the right order

When Netflix will not load with Clash, the first useful question is not “Which Netflix setting should I change?” It is “Where does the request stop?” A blank page, an endless loading spinner, a playback error, and video that starts but repeatedly buffers can point to different parts of the connection. Clash may be running while Netflix traffic uses the wrong policy group, a selected proxy node may be unable to reach the service reliably, or DNS may return an address that does not match the route your rules expect.

Work from the least disruptive check to the most specific one. Confirm that the Netflix app or browser works without a profile change, verify the active proxy mode, test the selected node, inspect the rule that matches Netflix traffic, and only then investigate DNS. Changing several settings at once makes a temporary improvement difficult to explain and can hide the actual fault. Keep a note of the original mode, group selection, and DNS settings so you can restore them if a test makes other traffic worse.

Before testing, check that your device has ordinary internet access and that Netflix is available for your account and location under the service’s current terms. A captive Wi-Fi sign-in page, expired subscription, outdated app, or a temporary Netflix service incident can resemble a proxy failure. If Netflix also fails with Clash fully disabled, troubleshoot the device, account, app, and network first; editing Clash rules will not repair those problems.

Check proxy mode, the active group, and node health

Start with the client’s current operating mode. In Rule mode, Clash evaluates matching rules and sends each connection to the group or action specified by the first applicable rule. In Global mode, traffic is directed through the selected global proxy group rather than following the usual per-domain rule path. In Direct mode, connections bypass the proxy. Names and controls vary between Clash Verge, Clash Verge Rev, Mihomo-based clients, and older clients, but the distinction is the same: the visible “connected” state does not prove that Netflix used the route you intended.

For a short diagnostic, note the current mode and selected proxy group, then select a known-working node using the client’s normal interface. Do not switch repeatedly between unrelated nodes while a stream is still opening: each new connection may create a different outcome, and some apps retain existing sessions until you close and reopen them. After changing the selection, quit or fully close the Netflix app or browser tab, reopen it, and try one title again. This gives the next test a cleaner connection path.

Use the client’s connection log or traffic view while loading the Netflix home page and starting playback. If Netflix-related connections appear, inspect the matched rule, the policy group, and the chosen node. If no relevant connections appear, the app might be using a path outside the proxy mode you assumed, a system proxy may not be enabled, or the client may not capture that application’s traffic. A connection log is more useful than the proxy-group label alone because it shows what happened to an actual request.

Next, compare a small set of ordinary sites with Netflix using the same selected node. If all sites are slow or fail, suspect the node, local internet connection, or a competing VPN before editing Netflix-specific rules. If ordinary sites work but Netflix does not, continue to the routing and DNS checks. A node’s latency probe only confirms that a probe endpoint responded; it does not guarantee that every streaming connection will have enough sustained throughput, stable routing, or a compatible path.

If the client offers a test URL or latency test, treat it as one clue rather than a streaming benchmark. A quick successful test can coexist with packet loss or congestion during a longer video session. Conversely, a slow probe can be caused by the probe endpoint itself. Try a brief playback test, then observe whether the log shows repeated connection attempts, resets, or a change of selected group. Record what you see before moving to the next step.

Inspect Netflix rules and rule ordering

In Rule mode, a specific Netflix rule can be ineffective if an earlier, broader rule already matches the request. For example, a general domain rule, a catch-all rule, or a rule-provider entry may route traffic before the Netflix-specific entry is reached. The important detail is not only whether a Netflix rule exists, but whether the traffic actually matches it and which group receives the connection. This is why checking the live connection details is safer than adding more rules based on guesses.

Review the rule shown for Netflix traffic in the log. If it matches a broad rule instead of the rule you expected, inspect the order of the relevant entries in the active configuration and any rule providers merged into it. In a ruleset, more specific entries generally need to be considered before broad fallbacks. Avoid duplicating a domain list simply because a profile already contains one: duplicated or conflicting entries make future updates harder to reason about and can leave you unsure which definition won.

Also verify that the matched policy group has a usable selection. A rule can correctly point to a group whose selected node is unavailable, whose members are all failing, or whose fallback behavior is not what you expected. If you change a group for testing, make a single deliberate change, reconnect Netflix, and check the log again. Afterward, return to the intended policy rather than leaving a temporary Global mode or test node active for unrelated traffic.

Profile updates deserve special attention. A subscription refresh or remote rule-provider update can change group names, ordering, or the rules that are merged into the active profile. Compare the active profile with the last known working version if the issue began soon after an update. Prefer the client’s profile history or a backed-up copy over hand-editing generated configuration that may be overwritten on the next refresh. For broader guidance on prioritizing specific rules and avoiding catch-all surprises, see Clash rule routing best practices.

Do not assume every Netflix hostname follows one identical route. A page load can involve sign-in, images, metadata, and playback requests, and a browser may reuse connections created before you changed the proxy group. The log can therefore show multiple domains and policies during one attempt. Focus on the connection that fails or repeats at the moment playback stalls. If necessary, close the app, wait briefly, and launch it again after confirming the active profile and group.

Check DNS behavior and distinguish buffering from routing failure

DNS problems can look like rule problems because domain resolution happens before or alongside the connection that the rule engine routes. A stale answer, an inconsistent resolver path, or a mismatch between the address returned and the route selected may cause one device to fail while another works. Start by checking whether the client is using its configured DNS behavior and whether the system or browser has a separate resolver setting. Do not change several resolver options simultaneously; preserve the original values and test one controlled change at a time.

If your client uses fake-IP mode, confirm that the profile’s DNS settings and routing rules are designed to work together. A domain may be represented internally by a synthetic address, while the client relies on its mapping to recover the original hostname for rule matching. If that mapping is unavailable or traffic bypasses the expected resolver, the resulting connection can take a different path from the one shown in a simplified mental model. With redir-host or other DNS modes, the resolution and matching details differ, so follow the behavior of the specific core and profile you use rather than copying a setting from an unrelated tutorial.

Flush the operating system or browser DNS cache only when there is a reason to suspect stale results, and restart the affected app afterward. A cache flush cannot repair an unreachable node or a rule that sends Netflix traffic to the wrong group. Likewise, changing public DNS providers is not a universal solution: it may alter resolution without improving the proxy route, and it can conflict with network policy or the DNS design in your profile. If the problem started after a DNS change, first restore the previous known-good configuration and compare the result.

Buffering after playback begins needs a slightly different test from a page that never loads. A successful home page means some requests completed, but it does not prove that the node can sustain a long video session. Watch whether the stream resumes after a brief pause, whether the connection log reports repeated resets, and whether other traffic through the same node also slows down. If the node is unstable across multiple services, a Netflix-specific DNS edit is unlikely to be the right fix. Try a stable, permitted route and compare one short playback session before changing profile rules.

Keep the device, app, and network conditions consistent during comparisons. Testing one node on Wi-Fi and another over mobile data, for example, changes more than the proxy path. Avoid running multiple proxy clients or VPNs during the test; competing system proxies, tunnel adapters, or DNS filters can make the displayed Clash state differ from the route the app actually uses. If you need to isolate the client, disable only the competing component you control, change one variable, and restore it afterward.

FAQ: Netflix and Clash troubleshooting

Netflix works in Direct mode but not Rule mode. What should I check?

Check the live connection log to see which rule matched, whether it was a broad rule that appeared earlier, and which group handled the connection. Then confirm that the selected group has an available node. Direct mode changing the result is useful evidence that the routing path differs; it does not by itself prove that DNS is wrong or that a new Netflix rule is needed.

Why does Netflix load, but playback keeps buffering?

The page and the video session may use different connections, and a node that responds to a short probe may still be congested or unstable under sustained traffic. Compare the connection log during playback, test a known-working node, and see whether other services through that node also stall. If only playback fails, check app updates and the network conditions as well as routing.

Should I change DNS whenever Netflix does not open?

No. First establish whether the issue is limited to Netflix and whether its traffic reaches the expected group. Change DNS only when the evidence points to resolution or DNS-to-rule matching, and test one setting at a time. Keep a copy of the prior configuration so you can revert promptly if the change affects other domains.

The same profile works on another device. Does that mean my node is fine?

It makes a profile-wide failure less likely, but the devices may differ in app version, DNS cache, system proxy state, competing VPNs, or network conditions. Compare the actual matched rule and connection behavior on both devices rather than relying only on the profile name or a “connected” indicator.

Some older proxy clients expose fewer connection details or make profile and DNS behavior harder to inspect, while generic VPN apps may offer little visibility into which Netflix request used which route. That makes it easier to guess at fixes without finding the failing layer. Clash V.CORE gives you a practical place to review proxy state, select a group, and troubleshoot routing with more context; if you want to apply the checks in this guide in a client with clearer controls, you can download Clash V.CORE.