Netflix 用 Clash 播放卡顿，先判断是哪一种问题

用 Clash 看 Netflix 卡顿时，表面现象可能都是转圈，但背后的原因并不一样。有人是视频开始后每隔几十秒缓冲一次，有人是能播放却长期停留在 480p 或 720p，无法提升到高清；还有人打开 Netflix 首页正常，点击影片后却提示「无法播放此内容」或直接显示地区错误。把这些情况统称为「节点不行」并不准确，因为节点线路、代理模式、DNS 解析、Netflix 分流规则、客户端内核中的任何一环异常，都可能造成相似结果。

排查前建议先记录三个信息：使用的 Clash 客户端与内核版本、发生问题的设备，以及具体播放表现。例如，Windows 上的 Clash Verge Rev 与 Android 上的 Clash Meta for Android，菜单名称和 TUN 实现不同；浏览器能播放而电视端不能播放，也说明问题未必在同一层。与此同时，不要只用首页加载速度判断线路质量。Netflix 真正播放时还会访问影片所在的媒体服务器，首页能打开并不代表视频 CDN、DRM 授权和测速接口都稳定。

• 持续转圈或频繁缓冲：通常与节点到 Netflix 媒体服务器的带宽、丢包、延迟和晚高峰拥堵有关。
• 画质很低但不停止：可能是线路带宽不足，也可能是播放器的自适应码率刚开始被限制，需要连续播放几分钟观察。
• 首页能开、影片不能播：重点检查 Netflix 相关域名是否被不同规则分到直连、拒绝或多个不一致的策略组。
• 浏览器能看、App 或电视不能看：优先确认系统代理是否被目标应用遵守，必要时使用 TUN 接管未读取系统代理的流量。

先检查节点线路：速度快不等于适合 Netflix

节点延迟低只是连接建立得快，不代表长时间播放稳定。Clash 的延迟测试通常发送一个很小的 HTTP 请求，而 Netflix 播放需要持续下载较大的视频分片。如果节点的峰值速度不错，却存在明显抖动、丢包或共享带宽拥塞，播放器就会在缓冲区耗尽后反复停顿。尤其是自动选择组使用 url-test 或类似测速策略时，测试结果可能只反映某个检测 URL 的表现，不能完全代表 Netflix 的实际体验。

打开客户端的「代理」「连接」或「日志」页面，播放一部影片并观察连接目标。不同版本的 Netflix 可能使用不同的媒体域名，常见的连接目标包括 netflix.com、nflxvideo.net、nflximg.net 和 netflixdnstest.nflxvideo.net。这些域名只作为排查线索，不建议在没有日志依据时盲目添加大量规则。更重要的是确认它们是否都进入了同一个稳定策略组，以及播放过程中节点有没有突然切换。

如果策略组当前设置为自动测速，建议临时手动选择两到三个候选节点，每个节点连续播放五到十分钟，再比较缓冲次数、清晰度和连接日志。不要只看测速页面显示的毫秒数；对于视频流，稳定的中等延迟通常比忽高忽低的低延迟更重要。某些线路在白天正常、晚间拥堵，可以分别在不同时间测试，避免把临时高峰误判为配置错误。

检查代理模式：系统代理不一定覆盖 Netflix

在 Clash Verge、Clash for Windows 或 ClashX 中打开「系统代理」，主要是把系统的 HTTP 或 SOCKS 代理设置交给应用使用。浏览器通常能够读取这项设置，但部分桌面播放器、电视应用、游戏内嵌浏览器和移动 App 可能完全忽略系统代理。因此会出现电脑浏览器可以播放，Netflix 客户端却一直转圈的情况。此时反复更换订阅没有意义，应该先确认目标应用的流量是否出现在 Clash 的连接列表中。

如果连接列表里完全看不到目标应用发出的 Netflix 请求，可以考虑启用 TUN 模式。TUN 会创建虚拟网络接口，在更底层接管 TCP，部分情况下还会接管 UDP，从而覆盖不读取系统代理的程序。Windows 上可能需要管理员权限或安装服务模式；macOS 可能需要允许网络扩展；Android 则需要授予 VPN 权限。首次启用时不要同时修改太多 DNS 参数，先确认网页、普通 App 和 Netflix 是否都能正常访问。

检查分流与 DNS：避免 Netflix 请求走错出口

在规则模式下，Netflix 相关请求必须命中适合的代理策略。常见错误是只给 netflix.com 写了代理规则，却遗漏了视频、图片或测速所使用的其他域名；也有用户把 Netflix 规则放在宽泛的直连规则后面，结果规则永远不会被执行。打开 Clash 的连接详情，查看每个请求的匹配规则、最终策略和出口节点，比直接编辑配置文件更可靠。

你可以先建立一个名为「Netflix」的策略组，临时将相关域名统一指向同一个手动选择的节点。确认播放稳定后，再考虑拆分为自动测速或地区策略。规则写法应以当前内核支持的语法为准，Mihomo 与旧版 Clash 在规则集、脚本和覆写功能上并不完全相同。若订阅每次更新都会覆盖本地修改，应使用客户端提供的覆写、Merge 或 Patch 功能，而不是直接改远端配置。

DNS 问题常被误认为节点速度问题。使用污染的解析结果、错误的 IPv6 地址，或让 DNS 请求走直连而视频连接走代理，都可能导致 Netflix 返回不合适的 CDN。可以在 Clash 的 DNS 设置中确认是否启用了可用的远程解析方式，并检查 ipv6 是否与当前网络匹配。若开启 IPv6 后频繁卡顿，可暂时关闭 IPv6 做对照；如果关闭后明显改善，再单独处理 IPv6 路由，而不是永久堆叠更多规则。

动手操作：按顺序完成一次可控修复

下面的步骤适用于 Clash Verge Rev、Mihomo Party、Clash for Android 等常见客户端。不同客户端的按钮名称可能略有差异，但判断逻辑一致：先验证节点，再验证规则，最后才扩大接管范围。

1. 记录当前状态：记下客户端名称、内核版本、当前策略组、代理模式、DNS 模式和出现卡顿的时间段，避免修改后无法回溯。
2. 固定一个节点：在 Netflix 专用策略组中手动选择线路，暂时关闭自动测速和故障转移，连续播放同一部影片至少五分钟。
3. 查看连接日志：确认 netflix.com、nflxvideo.net 等实际目标出现在连接列表中，并核对它们都命中了预期策略，而不是直连或拒绝。
4. 验证出口地区：在浏览器打开 Netflix 帐号页面或内容库检查页面，确认当前节点所在地区符合你的订阅和使用需求；地区错误时先换节点，不要急着改播放器设置。
5. 检查系统代理覆盖范围：如果浏览器正常而 App 不通，关闭其他代理软件，确认系统没有残留 PAC、VPN 或安全软件拦截，再按需启用 TUN。
6. 单独测试 DNS：先保留已经验证过的节点，只切换 DNS 或 IPv6 设置。每次切换后清理应用缓存并重新打开影片，记录结果。
7. 最后恢复自动策略：只有手动节点和规则都稳定后，才重新启用 url-test、负载均衡或故障转移，并设置合理的测速间隔，避免播放过程中频繁换出口。

如果步骤完成后仍然卡顿，可以在 Clash 日志里观察是否存在大量连接重试、TLS 握手失败、连接被远端关闭或 DNS 超时。若只有某一部影片异常，可能是该片源 CDN 或地区授权问题；若所有影片、所有节点都异常，则要回到订阅有效期、帐号状态和当前网络环境检查。不要把 Netflix 的「标题不可用」提示一律归结为代理速度不足。

不同客户端的细节差异与稳定播放建议

Clash Verge Rev 和 Mihomo Party通常适合在电脑上查看连接日志、调整规则和启用 TUN。建议先使用系统代理验证浏览器播放，再决定是否需要 TUN，尤其要留意 Windows 的管理员权限、虚拟网卡和其他 VPN 软件之间的冲突。macOS 用户应检查网络扩展是否获得授权，并确认系统的私人中继、代理和 VPN 配置没有重复接管。

Clash for Android使用 VPN 服务接管流量时，Android 系统可能限制后台活动或省电策略，导致长时间播放时连接被暂停。可以将 Clash 加入电池优化白名单，并确认当前应用使用的是正确的 VPN 模式。若只想让 Netflix 走代理，可使用应用分流；但首次排障时建议暂时减少复杂的应用规则，先确认全局或明确的 Netflix 策略能够稳定工作。

ClashX 或其他 macOS 客户端的系统代理覆盖范围取决于应用本身是否读取 macOS 代理设置。Safari、Chrome 与命令行工具的行为可能不同，终端里的 curl 还可能需要显式指定 HTTP 代理端口。无论使用哪种客户端，都应以连接日志为最终依据：请求确实进入 Clash、命中正确策略、节点没有中途切换，才算完成了有效验证。

相比之下，市面上一些同类代理工具在 Netflix 场景中要么只提供简单的全局开关，要么把 DNS、TUN、规则命中和连接日志分散在复杂菜单里，遇到「首页能开但视频卡顿」时很难知道究竟是哪一层出了问题。Clash 官网 的优势在于把节点选择、分流规则、代理模式与实际连接验证放在同一套排查思路中，既能照顾只想快速播放的新手，也方便进阶用户根据日志逐项定位；如果你正准备重新整理 Netflix 的代理环境，不妨免费下载 Clash 官网，按本文顺序先固定节点和规则，再逐步恢复自动策略，通常比反复盲目换软件更容易找到稳定方案。