Netflix 用 Clash 打不开或一直转圈？按步骤排查代理与 DNS

先判断 Netflix 故障发生在哪一层

Netflix 在 Clash 下打不开、登录页能进但视频一直转圈，或者播放时出现错误代码，原因可能分布在应用、规则、代理节点和 DNS 多个环节。先不要连续更换配置或重装客户端：如果故障发生在代理链路，重装 Netflix 通常不会改变结果；反过来，如果只有一台设备上的应用异常，也不应先把整个订阅判定为不可用。

先做一个简单对照：确认 Clash 核心正在运行，在客户端里手动选定一个状态正常的节点，再用同一台设备和同一个网络打开 Netflix 网页并尝试播放。若网页和应用都打不开，优先检查节点、代理模式与分流；若网页可以播放而应用失败，重点排查应用是否绕过系统代理、是否使用了旧 DNS 缓存，或是否受到设备网络权限影响；若网页能登录但视频卡顿，则还要观察视频资源请求是否与页面请求走了相同的出站策略。

也要区分「网页加载成功」与「视频播放链路正常」。Netflix 首页的文本和图片可能已加载，但播放需要进一步请求播放清单、授权信息和视频分片。它们可能命中不同域名或 CDN，因此首页可见并不能证明每个请求都按预期代理。排查时尽量记录具体症状、设备、客户端、节点和发生时间；这些信息比笼统描述「Netflix 被 Clash 影响」更有助于定位问题。

检查代理模式、节点与系统代理

首先确认 Clash 没有处于「直连」模式。规则模式通常适合日常使用，但它依赖配置中的规则决定每条连接走代理还是直连；全局模式则让大多数流量统一交给当前选定的代理策略。排障时可以短暂切换到全局模式做对照：如果全局模式下 Netflix 恢复，而规则模式仍失败，说明问题更可能在规则命中或策略组选择，而不是应用本身。测试完成后记得恢复日常模式，避免其他流量也被不必要地代理。

再打开客户端的代理或连接页面，确认实际使用的策略组没有选中「DIRECT」，也没有指向一个已失效的节点。测速结果只代表探测请求在某一时刻的响应情况，不保证 Netflix 播放资源可用；节点延迟低但连接频繁重置，仍可能导致视频缓冲。建议先用单个节点测试，不要一开始就使用自动选择、负载均衡或多层嵌套策略组，这些策略会增加判断实际出口的难度。

客户端的系统代理开关也值得核实。Clash Verge、Clash Verge Rev、Clash for Windows 和 ClashX 等桌面客户端，通常需要明确启用系统代理，浏览器才会按预期连接本地代理端口。Clash for Android 的流量接管方式则与系统 VPN 服务相关，需确认 VPN 状态未被系统省电策略暂停。若使用 TUN，应先确认虚拟网卡已启动且没有其他 VPN、终端防护或网络过滤器争用路由；测试阶段可先关闭 TUN、只用系统代理验证，再按需要恢复。

注意不同应用对系统代理的遵循程度并不相同。浏览器能打开 Netflix，不一定代表电视盒子、手机应用或其他设备也经过同一条代理链路。若只有一个应用失败，检查设备是否连接到运行 Clash 的设备、代理共享是否正确，及该应用是否支持当前代理接管方式。家庭路由器、电脑和手机分别运行代理时，也要确认实际流量进入的是哪一台设备，避免把客户端状态正常误认为 Netflix 流量已经被接管。

用连接日志核对分流规则与 DNS

在 Clash 的连接日志中，于开始播放或刷新页面时查看新增连接。重点不是机械地寻找一份固定域名清单，而是确认 Netflix 相关请求是否出现、命中了什么规则、最终交给哪个策略组，以及连接是否成功建立。Netflix 可能通过多个服务域和 CDN 提供页面、授权与视频内容；实际请求会随客户端、地区和服务更新而变化。像 netflix.com、nflxvideo.net、nflxso.net 等域名可作为观察线索，但不能代替对你自己日志的核对。

如果日志显示相关连接命中直连规则，而你希望该流量走代理，应检查规则顺序和策略组名称。Clash 通常按规则排列顺序匹配，较早的宽泛规则可能先于后来添加的 Netflix 专用规则生效。确认规则确实进入当前正在使用的配置，并检查策略组是否选中了可用节点。不要仅凭配置文件里「存在一条规则」就判断它已生效；当前配置、规则提供者更新时间和实际匹配结果都需要对得上。

DNS 异常也会造成「网页偶尔能开，视频却一直等待」的表现。检查 Clash 的 DNS 设置是否启用、当前网络是否仍在使用旧缓存，以及系统是否同时接入了 VPN、自定义 DNS 或安全软件过滤。若使用 fake-ip 模式，确认应用没有因本地 DNS 行为或缓存而拿到过期映射；如果近期切换过 DNS 模式或代理节点，可以在不改变其他变量的前提下重启 Clash 核心，并重新打开应用测试。不要将公共 DNS 地址直接抄入配置作为万能修复：解析器可达性、规则分流和出口路径必须相互匹配。

可按下面顺序缩小范围：先在连接日志确认 Netflix 请求是否被捕获；再看命中规则与出站策略；最后再检查解析结果和连接状态。如果日志里根本没有相关请求，优先检查应用是否经过代理以及系统流量接管；如果请求出现但走了直连，修正规则；如果请求已走代理却反复超时或重置，再测试另一个节点。这样的顺序可以避免在 DNS、规则和节点之间来回盲目修改。

按症状验证修复效果与常见误区

每次调整后都用相同流程验证：关闭并重新打开 Netflix，选择同一部影片，从播放开始观察一至两分钟，再比较错误是否复现。不要只以首页加载速度作为结论，也不要短时间连续切换很多节点后凭一次成功就认定问题已解决。视频分片可能经过不同的缓存节点，初次播放、拖动进度条和连续播放的请求特征也不完全相同；连续测试能帮助区分偶发波动与稳定修复。

下表按现象给出排查优先级。它不是对 Netflix 错误代码的统一解释：相同提示可能由不同网络条件触发，仍应结合客户端日志和其他设备的对照结果判断。

如果规则模式失败、全局模式正常，先修正规则命中或策略组，而不是永久依赖全局模式；如果同一节点下多个设备都失败，再比较其他节点，观察是否为节点出口或线路质量问题；如果只有一台设备异常，则回到该设备的代理接管、DNS 缓存和应用权限排查。出现认证或账户提示时，也应先在官方应用中确认账户状态和服务可用性，网络代理故障与账户问题可能同时存在，但不能互相替代诊断。

Netflix 与 Clash 常见问题

Netflix 首页能打开，为什么视频还是一直转圈？

首页和视频播放可能触发不同的连接，且相关请求未必命中同一规则或策略组。请在点击播放时查看连接日志，确认新增请求是否被代理、是否走了预期节点，以及连接有没有超时或重置。仅看到首页加载完成，不能证明视频链路已经正常。

换节点后需要同时修改 DNS 吗？

不一定。先保持 DNS 和规则不变，只换一个节点进行对照；若播放恢复，问题更可能与原节点的连接质量或出口有关。只有在日志或解析测试指向 DNS 缓存、解析失败等问题时，才单独调整 DNS。一次改动一个变量，结果才有可解释性。

全局模式能播放，规则模式不能播放，应该怎么办？

这通常提示规则或策略组选择值得优先检查。确认 Netflix 请求实际命中了哪条规则，检查宽泛规则是否排在专用规则之前，并核对当前策略组是否选择了有效节点。找到原因后恢复规则模式，再重复播放测试，不建议把全局模式当作永久替代方案。

完成检查后仍然播放失败，下一步做什么？

记录客户端和核心版本、设备类型、所用模式、节点、故障时间以及日志中的错误状态；再用另一节点和另一设备分别对照。如果只有某个节点失败，向服务提供方反馈该节点的可复现现象；如果所有节点都失败，则检查订阅、规则更新和设备网络限制，并确认 Netflix 服务本身及账户状态正常。

与只提供简单系统代理开关的工具相比，Clash 类客户端能查看连接记录、区分规则命中并调整策略组，因而更适合定位 Netflix 页面与视频请求走向不同的问题；但客户端不会自动保证每个节点、DNS 解析器和规则集都适合当前网络。排查时按日志逐层验证，比反复重装应用或无差别改配置更可靠。如果你希望使用可视化方式管理节点与分流，并在出现卡顿时更方便核对连接，可以前往前往下载获取 Clash V.CORE，再按本文步骤进行实际播放验证。