Clash Streaming Setup: Netflix And Disney+ Split Rules

The Goal: Streaming Through Proxy, Local Sites Direct

A streaming-focused Clash configuration has two separate jobs. Netflix and Disney+ traffic should use a proxy group whose exit region is compatible with the catalog and account you intend to use, while local websites, banking services, software mirrors, and nearby services should continue through DIRECT. This is a selective routing setup, not the same as sending every connection through one proxy.

Clash makes the decision by checking each connection against an ordered rule list. A matching rule sends the connection to an outbound such as DIRECT, a single proxy, or a named proxy group. The rule itself does not make a streaming service available, change an account region, or guarantee that a particular node will work. It only determines which network path the request takes.

There are several reasons streaming services need more careful handling than an ordinary website. A video service may use separate domains for login, playback, subtitles, images, telemetry, advertisements, device registration, and content delivery. The application may also open connections over HTTP/2, HTTP/3, or QUIC. If only one visible domain is routed through Clash while the rest use a different path, the result can be a login loop, an incorrect catalog, a playback error, or a video that starts but never buffers properly.

• Streaming domains: route the service's known domains to a dedicated streaming group.
• Local destinations: keep local websites and private network ranges on DIRECT where appropriate.
• Unmatched traffic: choose a deliberate final MATCH policy instead of relying on an accidental default.
• DNS resolution: make sure the domain used for matching is visible to Clash and resolved through a path consistent with the selected outbound.

Choose Nodes for Playback, Not Just Speed Tests

The fastest node in a generic latency test is not always the best streaming node. A node can have excellent ping to its server while suffering from congestion on the path to a content delivery network. Conversely, a node with slightly higher latency may maintain a steadier connection and produce fewer bitrate drops during a long session.

Start by identifying the region you actually need. If the account, subscription, or title availability is tied to a particular market, select a node in that compatible region rather than switching randomly between countries. Frequent region changes can also create account-security prompts or inconsistent results between devices.

A Practical Node Selection Checklist

1. Choose three to five candidate nodes in the target region. Avoid testing a large list at once because it makes the results difficult to compare.
2. Check latency and packet loss, but do not treat the latency number as a playback guarantee. A stable connection is more important than a tiny difference in ping.
3. Open the service through the streaming policy group and verify sign-in, catalog loading, subtitle selection, and playback separately.
4. Run a ten- to fifteen-minute playback test at the quality you normally use. Watch for repeated buffering, sudden resolution changes, and audio-video desynchronization.
5. Record the nodes that work consistently and remove unstable or frequently rejected endpoints from the dedicated group.

For a manual configuration, a select group is the easiest place to begin because it lets you switch nodes explicitly. Once you have several reliable candidates, a url-test group can measure a health URL and choose a responsive node automatically. However, a health check only measures the URL used by the test. It may not represent the streaming provider's login service or CDN, so automatic selection should be validated with real playback.

A fallback group is useful when you want the first healthy node in a defined order. A load-balance group may distribute connections across nodes, but that behavior can be less predictable for services that expect a consistent source address during a session. For streaming, predictable selection is often easier to troubleshoot than aggressive balancing.

Organize Dedicated Proxy Groups

Do not point Netflix and Disney+ rules directly at one arbitrary node unless you have a very small setup. A named group gives you a single control point: the rule stays unchanged while you replace, reorder, or test nodes inside the group. It also prevents unrelated traffic from silently following a streaming-specific choice.

A simple structure can contain a general proxy group, a Netflix group, and a Disney+ group. The two streaming groups may use the same candidate nodes at first, but keeping them separate makes it possible to test service-specific behavior later. Some nodes may work for one service and fail for another because IP reputation, CDN routing, or regional licensing checks differ.

proxy-groups:
  - name: STREAMING
    type: select
    proxies:
      - STREAM-US
      - STREAM-JP
      - STREAM-UK
      - DIRECT

  - name: NETFLIX
    type: select
    proxies:
      - STREAM-US
      - STREAM-JP
      - STREAM-UK

  - name: DISNEY+
    type: select
    proxies:
      - STREAM-US
      - STREAM-JP
      - STREAM-UK

  - name: LOCAL
    type: select
    proxies:
      - DIRECT
      - PROXY

The names in this example are ordinary policy labels, not built-in keywords. Every name referenced by a rule must match a group or proxy defined elsewhere in the complete configuration. A label containing special characters can be accepted by some clients but displayed inconsistently by others, so use short, clear names such as NETFLIX, DISNEY, or STREAMING if your client has trouble displaying a plus sign.

Separate Groups or One Shared Group?

One shared STREAMING group is convenient when all services use the same region and node pool. Separate groups are better when you need to keep the choices independent. For example, Netflix playback may be stable through one region while Disney+ performs better through another. Separate groups also make log analysis clearer because you can see exactly which policy was selected for each service.

Keep DIRECT out of a streaming group if the purpose of that group is to enforce a proxy path. Adding DIRECT as a fallback can be useful for testing, but it can also produce a direct request after a node failure. That may cause a different catalog, an authentication mismatch, or a failed playback attempt that looks like a service outage.

Write Rules for Netflix and Disney+

Use DOMAIN-SUFFIX for service-owned domains when you know the domain belongs to the service. It matches the root domain and its subdomains, making it more useful than a single exact DOMAIN entry. Avoid broad DOMAIN-KEYWORD rules such as netflix whenever possible: a keyword can match unrelated hosts and route more traffic than intended.

The following is a pattern, not a universal vendor-maintained list. Service domains can change, and a particular client or rule provider may use a larger maintained set. Add only domains you have confirmed in the Clash connection log or in the service's documented network behavior.

rules:
  - DOMAIN-SUFFIX,netflix.com,NETFLIX
  - DOMAIN-SUFFIX,netflix.net,NETFLIX
  - DOMAIN-SUFFIX,nflxvideo.net,NETFLIX
  - DOMAIN-SUFFIX,nflximg.net,NETFLIX

  - DOMAIN-SUFFIX,disneyplus.com,DISNEY+
  - DOMAIN-SUFFIX,disney-plus.net,DISNEY+
  - DOMAIN-SUFFIX,bamgrid.com,DISNEY+
  - DOMAIN-SUFFIX,disney-plus.net,DISNEY+

  - GEOSITE,private,DIRECT
  - GEOIP,PRIVATE,DIRECT,no-resolve
  - MATCH,PROXY

Do not copy a domain list blindly. Some domains are shared by multiple products, some are used for regional infrastructure, and some lists become outdated. If a video thumbnail loads but playback fails, inspect the log while starting a title. The missing host may be a media CDN or authentication endpoint rather than the obvious brand domain.

Rule order matters. A more specific service rule must appear before a broad local, regional, or catch-all rule that could consume the same request. The final MATCH rule should normally be last. If it appears before the Netflix or Disney+ entries, every later service rule becomes unreachable.

Keep Local Websites and Devices Direct

Streaming rules should be narrow enough that local traffic remains unaffected. A typical configuration puts private network ranges and local domain categories before the streaming rules, then places the service-specific entries before the general proxy fallback. The exact order depends on your policy, but the principle is consistent: protect LAN access first, match the intended streaming domains next, and leave the broad catch-all at the end.

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  - DOMAIN-SUFFIX,netflix.com,NETFLIX
  - DOMAIN-SUFFIX,netflix.net,NETFLIX
  - DOMAIN-SUFFIX,nflxvideo.net,NETFLIX
  - DOMAIN-SUFFIX,disneyplus.com,DISNEY+
  - DOMAIN-SUFFIX,bamgrid.com,DISNEY+

  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Private IP rules are especially important when Clash is enabled on a home network. They preserve access to a router panel, NAS, printer, or local development server. The no-resolve option tells Clash not to resolve a domain before applying that IP rule, which avoids unnecessary DNS work when the destination is already an IP address.

On mihomo-based clients, GEOSITE and GEOIP depend on the available rule databases and their freshness. A GEOSITE,cn,DIRECT rule is convenient, but it is not a perfect definition of every local website. Some sites use overseas CDNs, and some local services depend on third-party hosts. If a site behaves unexpectedly, check the matched rule in the connection panel instead of assuming that its language or registration country determines the route.

LAN access may also require the client setting allow-lan: true when other devices need to connect to Clash through the host machine. This setting is separate from routing rules. A correct DIRECT rule does not make Clash listen on the LAN, and enabling LAN access does not automatically configure phones, televisions, or game consoles to use the proxy.

Rule Mode Versus Global Mode

Rule mode evaluates the configuration's rule list for every connection. It is the appropriate mode for split routing because Netflix and Disney+ can use their dedicated groups while local websites follow DIRECT. The result is selective: only traffic that matches a streaming rule is sent to the streaming policy.

Global mode sends traffic through one selected proxy or group without evaluating the normal per-domain policy in the same way. It is useful as a diagnostic control. If a service fails under rule mode, temporarily selecting global mode can show whether the problem is caused by missing rules or by the node itself. It is not a replacement for a finished split configuration because local sites, LAN resources, update services, and other applications may all be sent through the same exit.

Use Mode Switching as a Diagnostic Test

First test the service in rule mode and inspect the connection entry. Confirm that the destination is assigned to NETFLIX or DISNEY+, then confirm the selected node and the transport status. If the request is assigned to DIRECT, the rule list or DNS behavior needs attention. If it reaches the correct group but playback still fails, switch briefly to global mode with a known compatible node.

If global mode works while rule mode fails, look for missing domains, an earlier broad rule, a stale rule provider, or a DNS policy that prevents Clash from seeing the original hostname. If both modes fail, changing rule order will not fix a rejected or congested node. Test another node, verify the region, and check whether the client application is actually covered by the system proxy or TUN mode.

DNS, TUN, and Multiple-Device Coverage

Domain rules require a domain name. Some applications first resolve a hostname locally, receive an address, and then connect only to that address. In that situation, a domain rule may not match unless Clash uses DNS interception, fake-ip, sniffing, or another supported mechanism to recover the original hostname. This is one reason a browser may follow the expected policy while a television or mobile application does not.

On a desktop, system proxy mode usually covers HTTP and HTTPS applications that respect the operating system proxy. It does not automatically capture every UDP flow or every application that maintains its own network stack. TUN mode is broader because it creates a virtual interface and routes more system traffic into the Clash kernel. When using TUN, confirm that automatic route takeover, the selected network stack, and DNS hijacking are supported by the client and operating system.

DNS settings should be tested together with routing. With fake-ip, Clash returns synthetic addresses such as the configured fake-IP range and later maps them back to the original domain. With redir-host, Clash returns resolved addresses more directly. Each mode has compatibility trade-offs. If a streaming app rejects fake-IP behavior, add a narrowly scoped fake-IP filter or test redir-host according to the client's supported configuration rather than disabling DNS handling globally.

• Windows and macOS: verify both system proxy status and TUN status; different applications may use different paths.
• Android: the VPN permission must be accepted, and battery optimization should not stop the client in the background during playback.
• iOS: the VPN profile must remain active; background restrictions can interrupt a tunnel or DNS service.
• Smart TVs and consoles: they may need a LAN proxy, router-side TUN service, or a shared network gateway because they cannot install a Clash client directly.

Test, Read Logs, and Maintain the Configuration

After importing the configuration, restart the client or reload the profile so the new groups and rules are active. Select rule mode, choose a known node in the relevant streaming group, and clear any existing application session if the service keeps old region information in memory. Then test login, catalog browsing, and playback as separate steps.

1. Open a local website and confirm its connection uses DIRECT. Test a LAN address as well if the device needs local resources.
2. Open Netflix and start a title, then inspect the active connections. Confirm the relevant domains use NETFLIX rather than the general proxy group.
3. Repeat the same process in Disney+ and confirm that its domains use DISNEY+.
4. Pause and resume playback, seek forward, and allow the stream to run for several minutes. This checks more than the initial page load.
5. Switch to another node inside the same group and repeat the test. Record whether the issue follows the node or remains with the configuration.

Use the Clash log and connection panel as evidence instead of guessing. Look for the hostname, matched rule, selected policy, destination address, and transport protocol. A request marked DIRECT indicates a routing problem if it should be proxied. A request assigned to the expected group but ending with timeout or reset errors points more toward node quality, upstream filtering, DNS, or application compatibility.

Keep the configuration maintainable. Store streaming rules in a clearly marked section, use stable group names, and avoid editing a generated subscription directly if the client will overwrite local changes on the next update. Prefer a local override or compatible profile merge feature. When a rule provider is used, check its update date and inspect changes before applying them to every device.

Finally, remember that successful playback is a moving target. Nodes can become congested, addresses can be reclassified, service domains can change, and a client update can alter TUN or DNS behavior. When a problem appears, isolate it in this order: confirm the active mode, confirm the matched rule, test the selected node, check DNS and TUN coverage, and only then revise the domain list. This sequence keeps a working local-direct policy intact while you troubleshoot the streaming path.