OpenClash 设置方案
本项目创建于 2024 年 4 月，本文提供一套详尽的 OpenClash 图文设置方案。
本文提供一套从零开始、覆盖准备工作到结果检验的完整 OpenClash 设置教程，帮助用户使 OpenClash 适应当前网络环境并长期稳定运行。文中同时介绍相关选项的作用原理，便于理解各项功能。
Note
本文内容看似冗长。
图片占据了较多篇幅；「添加订阅和分流配置」环节还详细介绍了三种并列方法，实际操作时三选一即可。
实际操作环节仅占用几分钟。
Caution
本文提供中立的配置技术说明。请搭配有权使用的订阅、节点和网络服务，并遵守适用法律、服务条款与第三方权利要求。不要把真实订阅地址、Token、节点凭据或未经脱敏的配置公开到 Issue、聊天记录或截图中。
Note
本文不是适用于所有环境的唯一方案。网络结构、固件版本和使用需求不同，配置完成后仍需按本文的检查步骤验证，并根据实际结果调整。
OpenClash 是 OpenWrt 下功能完整的分流与规则路由插件，其功能并不局限于本文提及的范围。
Caution
重要前置说明：
- 本方案遵循「完成 LuCI 页面设置，并从三种订阅路径中选择一种」的原则完成 OpenClash 设置。
- 不推荐所谓的「一键导入」配置： 部分视频教程宣称「下载一个 YAML 导入即可使用」，这种说法并不正确。YAML 配置文件无法预知不同用户的需求差异，也会限制用户根据实际环境进行个性化配置，例如此类配置通常会关闭 IPv6。本项目反对为了展示效果而使用通用配置，每位用户都应根据实际环境和需求调整相关参数。
- 不推荐从零手动编写配置： 新手从零编写的配置通常不够完整，其功能和规则合理性甚至不如订阅转换并覆写后生成的 YAML。建议先使用本项目的订阅转换模板或 YAML，在理解现有配置后，再根据需求学习手动编写配置文件。
- 关于「旁路由」： 本项目只以主路由环境作为文档和验证基准，不提供旁路由配置支持。旁路由环境的流量路径、DNS 和故障边界可能不同，需要按照实际网络结构另行配置和验证。
-
本方案使用
Fake-IP模式。 - 本方案依赖 OpenClash 的「绕过中国大陆」功能。
- 非营利声明： 本项目未运营任何付费教学或视频频道。
- (Wiki 页面右边有目录)
严格按照本方案配置 OpenClash，无需叠加其他工具（如 MosDNS）即可实现以下功能：
-
🚀 优化 DNS 与直连路径 常见直连域名使用本地解析；同时命中 GeoSite 的
cn分类和中国大陆 IP 地址段的流量不进入内核，从而降低性能损耗。 -
🛡️ 降低解析异常与泄漏风险 对需要经内核 Proxy 处理的域名，解析请求交由远端处理，以获得更一致的解析结果。
-
🧩 减少多插件叠加 尽量使用 OpenClash 完成分流与解析逻辑，避免多插件叠加带来的不确定性。
-
🖱️ 可复刻的设置流程 按图操作即可完成一套可长期使用的完整设置，无需从零手动编写配置。
-
🔀 覆盖常见场景的策略组 包含常见应用和平台的策略组，并提供轻量版供按需选择。
-
⚡ 支持策略组自动优选（可选） 可以根据延迟和可用性自动选择更合适的出站项，减少手动切换。
-
🎮 Steam 访问优化 单独列出 Steam 规则并强制 Steam 下载 CDN 走直连，避免下载流量进入内核。
-
🤖 自动更新，长期无人值守 设置完成后可定时更新上游规则、GeoIP、GeoSite 与直连白名单等数据。
-
📥 大流量下载优化（尝试） 尽量避免下载流量进入内核，降低不必要的消耗。
-
🕸️ 补充若干小众域名规则 可通过 PR 提交域名参与完善规则。
Warning
本项目的设置、截图和故障排查均以 OpenWrt 作为主路由的环境为准，不覆盖旁路由部署。
在单一主路由可以满足需求时，采用主路由方案通常可以减少额外的流量路径和故障点。
个人观点：关于「旁路由」的一些吐槽
因此，下文以主路由环境为基础，同时说明涉及旁路由的设置差异。旁路由用户需要根据实际环境调整对应设置；未特别说明的部分无需修改。
项目维护者部署的所有设备均采用主路由，以尽量简化网络环境。因此，旁路由设置问题通常不予解答；如根据经验提供建议，也无法保证结果。
如果本地网络具备 IPv6，且出站配置支持 IPv6 出站，可以配合本项目的另一套方案实现 OpenClash 与 IPv6 兼容：
如果不确定出站配置是否支持 IPv6 出站，可以先按方案开启并测试；如测试不通过，再关闭 OpenClash 的 IPv6 相关选项即可。
Important
强烈建议使用运营商通告的 DNS 进行直连域名的解析，不论是解析速度还是结果的科学性，都不是第三方 DNS 可以比拟的。
鉴于 2025 年以来部分网络环境的变化，运营商 DNS 在某些情况下不一定是最稳定的选择。如遇异常，推荐使用 AliDNS 等加密 DNS，并按需启用 DoH3。
请结合所在地的网络环境判断以下内容。如遇 DNS 解析问题，建议选择可用的加密 DNS。
多数情况下，运营商 DNS 对直连类域名的延迟和 CDN 命中更接近实际链路；一般不需要额外用第三方 DNS 做「优选」。
不同递归 DNS 在不同网络环境下，可能出现解析结果不一致或可用性不稳定的情况；如果选择第三方 DNS，优先使用加密协议（DoH 或 DoT）并观察实际效果。
以上结论仅来自项目维护者的实际使用经验。MosDNS 和 SmartDNS 本身都是优秀的 DNS 工具。
根据维护者过去在当地网络环境中的长期测试，三大运营商 DNS 通常能为直连域名返回较近的 CDN，和 DNS 插件优选的解析结果基本一致。该经验不代表所有地区与所有时间段；如遇异常，请按上文建议改用可用的加密 DNS。
以维护者所在城市为例，电信和联通线路的 DNS 延迟都很低：高峰时段约为 1～2 毫秒，白天可稳定在 1 毫秒左右。此时使用 DNS 插件很可能产生负优化。
维护者与运营商 DNS 位于同一城市，因此延迟表现较好。如果用户与运营商 DNS 不在同一城市，延迟可能更高，但通常仍优于第三方 DNS。
以下数据来自某三线城市用户长期部署的 SmartDNS，可以对比运营商 DNS 与第三方 DNS 的延迟：
按照本方案设置后，运营商 DNS 主要用于解析直连类域名，一般不需要担心解析一致性问题。非直连域名的解析请求交由远端处理，可获得更一致的解析结果，并降低 DNS 泄漏风险。
Note
如需使用第三方 DNS，建议优先使用 DoH、DoT、DoH3 或 DoQ 等加密协议。请勿随意使用明文 UDP 公共 DNS，以免出现劫持或解析结果不一致。
2025 年 7 月 22 日更新：部分地区用户反馈运营商服务器偶发异常；如遇直连访问不畅，建议切换为加密 DNS，以排除运营商侧影响。
MosDNS、SmartDNS 和 AdGuard Home 本身都是优秀的 DNS 工具，但多个插件叠加并不一定能改善效果，错误的组合反而可能产生负面影响。
先说结论：在本方案的 Fake-IP 使用场景中，nameserver 使用运营商 DNS 或可用的 DoH 服务器，同时不设置 fallback 服务器，是维护者推荐的默认设置。 这种设置兼顾性能开销与解析结果，一般不需要额外调整；如实际网络环境存在异常，再按需修改。
对于非直连域名，通常更适合将解析请求交给远端处理，这样更容易获得与出站链路一致的 CDN 命中。
从延迟和性能开销来看，以维护者所在的网络环境为例：部署本方案后，使用脚本对常见域名进行 30,000 次解析测试，dnsmasq 的解析延迟稳定在 1 ms 左右。加入 AdGuard Home 并启用缓存后，解析时间与 dnsmasq 几乎没有差异，却需要处理缓存与 Fake-IP 并存产生的问题，同时还会影响 Clash 向客户端传递的 TTL 值。
加载大量广告过滤规则后，AdGuard Home 的解析开销甚至略高于 dnsmasq。该结果与维护者及许多用户原先认为 AdGuard Home 在大量规则环境下更具性能优势的预期不同。
部分教程建议新手叠加 AdGuard Home 等插件，并添加多个没有必要的第三方 DNS，最终可能使内网解析延迟达到 5 ms、10 ms 或更高，却将其称为「优化」。相比之下，部分入门级硬路由通过 DHCP 直接分配运营商 DNS，网页访问反而可能更快。
此外，请勿过度依赖乐观缓存。Fake-IP 模式下叠加其他前置缓存插件可能引入更多问题；路由器上的缓存效果也未必优于浏览器和操作系统自带的 DNS 缓存。
Warning
如果认为 1 ms 的解析时间差异会明显影响使用体验，需要同时评估多插件叠加带来的其他副作用。
Warning
什么情况下有套娃的意义
- 网络支持双栈，并且对中国大陆网站同一域名的 IPv4 和 IPv6 地址的访问性能存在巨大差距。此时可在「NameServer」上游设置 SmartDNS 进行双栈优选。
- 确实需要监控和控制局域网设备的 DNS 请求，例如限制未成年人访问特定网站。此时适合在下游部署 AdGuard Home。 除上述两种情况外，其他场景一概没有必要叠加 DNS 插件。
除非使用存在流量穿透的宽带线路，例如长城宽带，或某些地区的移动大内网宽带，导致 DNS 延迟很高或无法解析到距离较近的 CDN；否则没有必要使用 DNS 优化插件。
本项目不再提供或维护广告过滤部署方案。旧版 dnsmasq 与 hosts 实现已经归档，并移除了可执行内容；不要将其视为当前 OpenClash 配置的一部分。
需要广告过滤时，请选择仍在维护、适合当前固件和 DNS 路径的方案，并以对应项目的最新文档为准。历史背景参见无插件广告拦截方案（已归档）。
无论使用订阅转换、手动上传 YAML，还是使用覆写模块调用远程托管的 YAML，本项目都强烈建议先根据实际环境在 LuCI 界面中完成插件设置，再从上述三种方式中选择一种加载配置文件。
OpenClash 会根据已完成的设置覆写配置文件，生成最终交由内核加载的配置。
Note
本项目为使用「第三方远端服务」的用户提供 8 套 INI 订阅转换模板，以及 8 套与模板完全对应的 YAML 文件。
本项目为同时使用「自建服务」与「第三方远端服务」的用户提供两套 YAML 配置文件。
8 套常规 YAML 和自建节点 Provider YAML 提供对应的覆写模块；手动维护静态节点的 YAML 没有通用覆写模块。Custom_Clash_8in1.conf 则是 8 套常规 YAML 的统一选择器，不对应同名 YAML。完整关系见本章「10 个 YAML 与 10 个覆写模块的对应关系」。
本项目不推荐新手从零手动编写 YAML。建议先按照本文完成插件的关键设置，再以生成的 YAML 为基础进行增量修改。
另外，建议参考 mihomo 官方的完整配置示例： https://github.com/MetaCubeX/mihomo/blob/Meta/docs/config.yaml
以及 mihomo 官方文档： https://wiki.metacubex.one/config/
说明：配置文件首先需要便于阅读，同时也需要能够被内核运行。因此，本项目的 YAML 格式与 mihomo 官方完整示例保持一致。
如需使用其他配置文件，本项目仅推荐 666OS/YYDS。
请严格按照文字和图片说明进行设置。对于本文未提及或暂时不了解的选项，请保持与示例一致。
Important
请完整阅读本文。 不要跳过文字说明或只照抄图片，否则可能遗漏关键设置。
整个教程内容冗长，但大多是讲解原理和功能，实际需要修改的设置并不复杂。
OpenWrt 作为主路由和旁路由时的设置差异，会在相关步骤中说明，请根据实际环境选择。
如果不了解选项作用，请勿随意修改。建议优先使用本项目模板；自行修改后，需要自行验证运行效果。
对于需要根据实际环境选择的步骤，本文会说明其原理，请仔细阅读后再操作。
Warning
请先按照本方案完成配置并确认运行正常。在理解相关设置后，再根据需要修改；不要在不了解选项作用时随意调整。
如有个性化需求，请先通过本方案理解相关设置，再 Fork 本项目并自行修改模板。
Note
如果你不打算使用运营商 DNS，则跳过此步骤。
首先确保 WAN 接口设置中已启用「自动获取 DNS 服务器」，这样才能获取运营商下发的 IPv4 DNS。
然后在 OpenWrt 首页检查是否已取得运营商下发的 DNS。如果计划使用其他第三方 DNS，可以跳过此步骤。
该功能位于「网络」→「DHCP/DNS」页面中，务必关闭。
Caution
若不关闭，有可能会引起 DNS 解析问题，并会导致本方案的广告拦截设置无法拦截部分非直连域名。
某些固件中可能没有这个选项，忽略该步骤即可。
OpenClash 的数据库、插件和内核更新均需要访问 GitHub 或 jsDelivr CDN。
无论当前网络能否稳定访问 GitHub，都建议提前在 OpenClash 中启用 GitHub 地址修改功能。
- 进入「OpenClash」→「覆写设置」→「常规设置」。
- 在「GitHub 地址修改」下拉菜单中选择一条 CDN 线路。
- 推荐选择 testingcf。该 CDN 是 jsDelivr 的 Cloudflare 线路，也可以根据实际网络情况尝试其他选项。
- 点击页面下方的「应用配置」，使设置生效。
准备工作完成，开始设置 OpenClash。
以下列出 OpenClash 的设置内容。每个需要调整的页面均有图文说明，请按照顺序逐页设置。
所有未提及的页面，均不需要设置。
Warning
注意：本方案适用于 Fake-IP 模式。如果不使用 Fake-IP 模式，本方案不适用。
首先在页面下方切换到 Fake-IP 模式，然后在上方的运行模式中选择「Fake-IP（增强）」。
如果页面中没有「使用 Meta 内核」选项，属于正常现象，因为目前 OpenClash 仅提供 Meta 内核。
Tip
「Fake-IP（增强）」模式通常具有较低的性能开销。如果出现 NAT 问题，可以尝试切换到「Fake-IP（混合）」模式，并启用 UDP 转发。 如果固件包含 Docker 功能，可以直接选择「Fake-IP（TUN）」模式。 如果非直连游戏网络存在特殊需求，请分别测试各模式下的 NAT 状态。
Caution
不推荐使用带有 Docker 的固件，会出现很多问题。
如果页面中仍有「使用 Meta 内核」切换选项，说明 OpenClash 版本过旧，请先将插件更新到最新版本。
按照图示设置。建议启用「实验性：绕过指定区域 IP」，并选择「绕过中国大陆」，以减少直连流量进入内核造成的性能损耗。
启用后，GeoSite 数据库中分类为 cn 的域名，且解析 IP 位于「中国大陆 IP 段」范围内的流量，将不进入内核。
如果个别站点或应用需要例外处理，可以在本页的相关黑名单中按域名添加规则。修改后，请保存设置并重启 OpenClash。
添加黑名单的域名和 IP 将不受「绕过策略」的影响，进入内核遵循规则的控制。
设置为使用 Dnsmasq 转发，然后点击「Fake-IP 持久化缓存清理」。无论是否显示错误提示，都继续点击页面下方的「保存配置」。
务必启用下方的「禁止 Dnsmasq 缓存 DNS」选项。新版 OpenClash 已移除此选项；如果页面中没有显示，可以忽略。
启用第二 DNS 服务器 功能，可以指定域名强制使用你指定的 DNS 进行解析，并直接返回真实 IP 而非 Fake-IP。
返回真实 IP 后，再根据 IP 绕过内核或进入内核。
请根据实际需要填写，例如 DDNS 域名；通常无需使用该功能。
Note
截图可能滞后于当前 OpenClash 界面，请以选项名称和本文文字说明为准。
此页用于「流媒体可用性探测」。当策略组包含多个出站项时，可以根据可用性和延迟自动选择更合适的出站项。
如果你更习惯在控制面板里手动选择出站项，可以跳过本节。
常用做法：
- 只启用需要探测的流媒体服务。
- 在「策略组筛选」中填写与控制面板一致的策略组名称关键词，例如
Netflix|奈飞。 - 在「解锁区域筛选」中填写所需的解锁区域，例如
SG。 - 可选：在「解锁节点」筛选中填写可用于解锁的节点关键词，进一步缩小范围。
- 其余选项保持图示默认值。设置完成后，点击页面下方的「保存配置」。
OpenClash 启动后，可在「运行日志」中查看探测结果与最终选用的出站路径。
如果计划启用 IPv6 功能，并且所用远端服务支持 IPv6 出站，请先按照本项目的 IPv6 设置方案完成 OpenWrt 的 IPv6 设置，再设置此页面。
按照维护者当前验证结果，完成对应设置后，OpenClash 可以与本文的 IPv6 方案配合使用；如插件界面或内核行为发生变化，请以实际测试结果为准。
Caution
旁路由环境建议停用 IPv6，或根据实际网络结构自行调整。
如果使用的第三方远端服务不支持 IPv6 出站，或 OpenWrt 未启用 IPv6，请禁用「IPv6 流量代理」和「允许 IPv6 类型 DNS 解析」。
如果个别站点或应用在 IPv6 环境下需要例外处理，可以在本页的相关黑名单或白名单中按域名添加规则。修改后，请保存设置并重启 OpenClash。
分流数据库必须保持更新，否则可能影响直连分流和规则匹配。请按照图示设置；各数据库的具体用途不在此展开。
截图可能滞后于当前界面。此页面中的所有数据库均需启用更新，包括截图中未显示的选项。
Note
每次数据库更新成功后，OpenClash 会自动重启，届时将会短暂影响进入内核的连接；直连连接不会受到影响。
建议将更新时间安排在每日网络空闲时段，例如凌晨；各项更新时间可以重叠。
实际上各个数据库源并非每日更新，只有在检测到更新并成功更新后 OpenClash 才会重启。
设置完成后，点击页面下方的「保存设置」，再依次点击四个「检查并更新」按钮。可以在 OpenClash 的「运行日志」页面查看结果，并确认 OpenWrt 能否正常访问 GitHub 或此前设置的 CDN，例如 testingcf.jsdelivr.net。
用于直连分流的 IP 白名单必须保持更新，按照图中设置即可。
Note
每次数据库更新成功后，OpenClash 会自动重启，届时将会短暂影响进入内核的连接；直连连接不会受到影响。
建议将更新时间安排在每日网络空闲时段，例如凌晨。
实际上各个数据库源并非每日更新，只有在检测到更新并成功更新后 OpenClash 才会重启。
设置完成后，点击页面下方的「保存设置」，再点击「检查并更新」。可以在 OpenClash 的「运行日志」页面查看结果，并确认 OpenWrt 能否正常访问 GitHub 或此前设置的 CDN，例如 testingcf。
此页面用于更新 OpenClash 的内核以及 OpenClash 自身。
优先考虑稳定性时，建议选择 master 版本。然后点击下方的一键更新，将内核和主程序更新到最新版本。可以在 OpenClash 的「运行日志」页面查看结果，并确认 OpenWrt 能否正常访问 GitHub 或此前设置的 CDN，例如 testingcf。
如需使用新功能，可以选择更新频率较高的 dev 版本；使用前应接受频繁升级和偶发 Bug，并保留可回退版本。
至此，OpenClash 中的常规设置已完成。
无论当前网络能否正常访问 GitHub，此处都建议选择一个 CDN 以改善访问速度。
建议选择 https://testingcf.jsdelivr.net/，其他选项保持默认值。
首先启用「自定义上游 DNS 服务器」，然后根据实际环境选择以下一种设置：
- 启用「追加上游 DNS」。
- 禁用下方「NameServer」组中的所有服务器。
- 禁用下方「Fallback」组中的所有服务器。
「追加上游 DNS」会将 WAN 接口取得的 IPv4 DNS、IPv6 DNS 和 PPPoE 网关追加为上游 DNS 服务器，无需手动配置。
这是维护者在相应前提下的推荐设置，但部分地区运营商 DNS 可能偶发异常；如遇直连访问不顺畅，可尝试切换到下面的设置，改用加密 DoH 服务器替代运营商 DNS。
2025 年 7 月 22 日更新：部分地区用户反馈运营商服务器偶发异常；可以切换到加密 DoH 服务器，以排除运营商侧影响。
- 禁用「追加上游 DNS」。
-
使用第三方服务器： 在「NameServer」中启用阿里和 DNSPod 的 DoH 服务器（地址中包含
https），并确保「Default-Nameserver」中至少启用一个服务器。 -
使用 SmartDNS： 启用「NameServer」组中的第一个服务器，并将地址修改为 SmartDNS 的地址和端口，例如
127.0.0.1:6053。 - 禁用「Fallback」组下的所有服务器。
在 SmartDNS 设置中，务必关闭 DNS 劫持，只保留第一服务器组，并仅添加所在国家或地区的 DNS，用于解析直连域名。
在多入口或复杂网络环境中，如果启用了 SmartDNS，建议在「NameServer」中额外启用一个 DoH 服务器，并在该服务器的设置中启用「节点域名解析」、禁用「直连域名解析」，以避免 OpenClash 使用 SmartDNS 解析节点域名。
Important
「追加上游 DNS」和下方的「NameServer」通常二选一即可；存在明确需求时也可以叠加使用。OpenWrt 作为主路由时，建议按照图示设置。
「追加上游 DNS」的作用是将 WAN 接口取得的运营商 IPv4 DNS、IPv6 DNS 和 PPPoE 网关自动设置为上游 DNS 服务器。
其余选项可以参考图示设置。
旁路由用户请参考上述第二种设置，并根据实际需要选择 DNS 服务器。
在本方案中，「NameServer」仅负责以下域名的 DNS 解析：
- 直连类域名（不经内核）。
- 经内核处理但最终直连的域名。
因此，没有必要在「NameServer」中填写多个服务器，也不要填写其他国家或地区的公共 DNS 服务器。 如果不使用运营商 DNS，可以选择 AliDNS、DNSPod 等第三方 DoH 或 DoT 服务器。部分 DoH 服务器支持 HTTP/3 和 QUIC，启用后可以显著降低解析请求的时间开销。
Important
为什么要取消「Fallback」服务器？
在 Fake-IP 模式下，如果取消了「Fallback」服务器，OpenClash 会把解析请求交由远端完成。 让解析与实际出站链路保持一致，通常更容易获得可用且一致的解析结果。
如果出站侧解析不可用（较少见），可以启用「Fallback」服务器作为备用，并选择任意可用的 DoH 服务器；同时建议在本页启用「遵循规则」。
如果使用域名形式的 DoH 服务器，例如 https://dns.alidns.com/dns-query，则需要启用「Default-Nameserver」服务器。
设置完成后，点击页面下方的「保存配置」。
### 3.3 Meta 设置
按照图示设置红框中的选项。 务必启用「启用 GeoIP Dat 版数据库」。
如果需要使用 Smart 内核，可以在此处设置 Smart 内核相关的一些选项。
Important
启用本页设置前，请先启用 Smart 内核，否则 OpenClash 将报错退出。 进入「插件设置」→「版本更新」，将「Smart 内核」设为「启用」，然后点击内核版本号下方的「检查并更新」。更新完成后，即可切换到 Smart 内核。
启用此处设置，OpenClash 会在启动时将配置文件中的所有 url-test 和 load-balance 节点组替换为 Smart 策略组。
如无特殊需求，请按照图示使用插件作者提供的模型。如需自行收集训练数据，可以启用对应选项；本文不再展开。
如无特殊需求，按照图中所示进行设置。
启用下方的「自定义规则」后会显示文本框，可以在其中添加附加规则。具体格式请参考文本框内的注释。
如果下载设备是 NAS 等独立设备，建议在此处通过自定义规则，使该设备的全部流量直连。
具体参考：BT 和 PT 等下载流量分流问题
也可以通过此功能补充自定义规则，指定部分域名或局域网设备直连或使用代理。
此处无需修改。
完成前文的 OpenClash 插件设置后，接下来需要为 OpenClash 提供节点来源、策略组和分流规则。
本项目为同一套分流逻辑提供了三种实现路径：
-
订阅转换与
.ini模板。 - 覆写模块远程调用 YAML 配置。
- 下载 YAML，手动填写订阅后上传。
三种路径解决的是同一个问题，只是配置生成、更新和维护方式不同。无论选择哪一种，OpenClash 最终都会在启动前，根据前文完成的 LuCI 页面设置，对配置文件进行覆写并生成实际交给 Mihomo 内核运行的配置。
Important
以下三种方式只需要三选一。
不要同时使用订阅转换、远程 YAML 覆写模块和手动 YAML 来维护同一套配置。多种路径叠加后，可能出现配置文件被反复切换、同名文件被覆盖、订阅来源不明确、故障时无法判断配置究竟来自哪里等问题。
Note
本项目提供的模板与 YAML，均由维护者依据常见使用场景和实际经验设计，不可能预知每位用户的节点命名、地区、业务和网络环境。需要完全贴合个人需求时，应在理解现有配置后自行修改或编写 YAML。
三种方式使用的规则顺序、策略组结构和分流目标尽量保持对齐。例如，选择 Custom_Clash 标准版时，无论通过 .ini 订阅转换、远程 YAML 覆写模块，还是手动上传 Custom_Clash.yaml，得到的核心分流逻辑均应当一致。
它们的主要差异不在「分流效果」，而在于配置由谁生成、订阅由谁读取和解析、后续参数是否便于调整、能否自动跟随仓库更新，以及用户对最终 YAML 的控制程度。
| 使用方式 | 实现方式 | 主要优点 | 代价与限制 | 推荐人群 |
|---|---|---|---|---|
| ① 订阅转换与模板 | OpenClash 保存订阅与转换参数，并向订阅转换后端发起转换请求；由后端套用 .ini 转换模板组合订阅链接并生成完整 YAML |
日常使用最方便；可直接在既有订阅编辑界面切换模板、开关 UDP 或跳过证书验证、设置节点包含或排除关键词等，无需编辑 YAML；适合大多数用户 | 订阅链接会提交给所选后端；依赖后端可用性及其与模板的兼容性；公共后端存在隐私和稳定性边界 | 希望通过 OpenClash 页面管理订阅，并经常调整转换参数的用户 |
| ② 覆写模块远程调用 YAML | OpenClash 下载本项目 .conf 模块；模块再下载对应 YAML，并把环境变量中的订阅写入 YAML |
不经过订阅转换；无需手动编辑 YAML；可自动跟随仓库配置更新 | 规则版本和可调参数主要由远程 YAML 与模块决定；切换版本需要更换模块或修改 EN_KEY2，不如订阅转换灵活 |
不希望使用转换后端，又不想手动维护 YAML 的用户 |
| ③ 下载 YAML，手动修改并上传 | 用户下载本项目 YAML，在本地填写订阅或自建节点，再上传到 OpenClash | 控制力最高；配置内容可审计、可固定、可深度修改；不依赖转换后端和远程模块 | 每次调整都需要编辑或重新上传 YAML；仓库后续更新不会自动合并；需要具备基本 YAML 和 Mihomo 配置知识 | 需要固定版本、深度个性化或维护静态自建节点的进阶用户 |
OpenClash 在订阅转换路径中承担的是参数管理、请求发起、结果下载和配置调度，并不自行读取或解析订阅内容。节点协议识别、节点合并、关键词过滤和模板生成等工作均由后端完成。
| 使用需求 | 建议选择 |
|---|---|
| 第一次使用，不想研究配置文件 | 订阅转换与 Custom_Clash |
| 希望节点故障后自动切换，不想手动选择节点 |
订阅转换与 Custom_Clash_Fallback，或对应 YAML 路径 |
| 经常切换标准、Lite、GFW、Full 或对应的故障转移模板 | 订阅转换，直接编辑既有订阅并切换模板 |
| 经常调整 UDP、跳过证书验证或节点关键词筛选 | 订阅转换 |
| 不希望把订阅提交给 SubConverter-Extended 后端 | 远程 YAML 覆写模块 |
| 希望配置自动跟随本项目更新，但不想编辑 YAML | 远程 YAML 覆写模块 |
| 已确定采用覆写模块，并需要在 8 个常规版本间切换 | Custom_Clash_8in1.conf 覆写模块 |
| 希望配置长期固定，不受远程文件变化影响 | 下载 YAML，手动修改并上传 |
| 自建节点以可通过 HTTP 获取的 Provider 或订阅形式提供，并以订阅节点作为后备 | 自建节点 Provider 覆写模块 |
| 自建节点需要直接填写 VLESS、Hysteria2、TUIC 等协议参数 | 手动修改 Custom_Clash_Selfhosted_Manual_Fallback.yaml |
| 需要完全自定义配置文件参数 | 下载 YAML，手动修改并上传 |
本项目正式配置文件遵循统一命名规则：
Custom_Clash[_Lite|_GFW|_Full][_Fallback].扩展名
命名中的 Custom_Clash 表示标准版，_Lite、_GFW、_Full 分别表示轻量版、极简 GFW 版和重度分流版；追加 _Fallback 表示主要代理型策略组采用故障转移逻辑。扩展名 .ini、.yaml、.conf 分别对应订阅转换模板、OpenClash 或 Mihomo 可加载的最小 YAML，以及 OpenClash 覆写模块。
例如：
Custom_Clash_Lite_Fallback.ini
表示「轻量故障转移版」订阅转换模板。
Custom_Clash_Lite_Fallback.yaml
表示与之对应、可以直接加载的 YAML 配置。
Custom_Clash_Lite_Fallback.conf
表示用于远程下载并写入该 YAML 的 OpenClash 覆写模块。
本项目提供 4 种规则规模，每种又分为普通版与故障转移版，共计 8 套常规逻辑。
| 分流逻辑 | 文件名（不含扩展名） | 主要特点 | 建议 |
|---|---|---|---|
| 标准版 | Custom_Clash |
常用业务分流、地区组和性能开销之间较为均衡 | 大多数用户优先选择 |
| 标准版 故障转移 | Custom_Clash_Fallback |
标准版规则不变，主要代理组改为按候选顺序自动故障转移 | 希望减少手动切换的用户 |
| 轻量版 | Custom_Clash_Lite |
减少独立业务策略组，保留基础代理、直连和常用服务分流 | 低性能设备或偏好简洁的用户 |
| 轻量版 故障转移 | Custom_Clash_Lite_Fallback |
轻量规则结构与自动故障转移 | 希望轻量且无人值守的用户 |
| 极简版 | Custom_Clash_GFW |
主要匹配 GFW 域名及 Telegram、Facebook、Twitter 等相关 IP，其余流量默认直连 | 只需要最基础代理逻辑的用户 |
| 极简版 故障转移 | Custom_Clash_GFW_Fallback |
极简规则与自动故障转移 | 极简需求且不想手动切换的用户 |
| 重度分流版 | Custom_Clash_Full |
在标准版基础上增加更多业务、国家、地区和节点用途分类 | 节点丰富、需要精确选路的进阶用户 |
| 重度分流版 故障转移 | Custom_Clash_Full_Fallback |
重度分流结构与自动故障转移 | 需要复杂分流又希望自动切换的用户 |
Tip
看不懂上表时，优先选择：
-
希望手动切换出口：
Custom_Clash。 -
希望自动故障转移：
Custom_Clash_Fallback。
四种规则规模可以概括为：标准版覆盖常用业务和六个主要地区组；Lite 版删减细分流媒体与业务组，只保留基础分流；GFW 版只处理 GFW 及相关 IP，未命中流量默认直连；Full 版则在标准版上继续增加 Talkatone、OneDrive、Copilot、PT、PayPal，以及更多国家、地区、家宽和低倍率节点分类。
普通版的主要业务策略组使用 select，用户可以在控制面板中手动选择地区组、自动选择组或具体节点，适合需要明确控制流媒体地区、AI 服务地区或特定出口的场景。故障转移版的主要代理型策略组使用 fallback，会按候选顺序进行健康检查，并在当前候选不可用时自动切换，更适合无人值守。
Warning
fallback 只根据健康检查地址判断候选是否可连接，不能判断节点是否具备 Netflix、ChatGPT、Disney+ 等服务的地区解锁能力。
本节所说的故障转移版使用 fallback 策略组类型，与 DNS 设置中的「Fallback」服务器没有关系。
除上述 8 套常规逻辑外，cfg/yaml 目录还提供 2 套「自建节点优先、订阅节点后备」的配置。
| YAML 文件 | 自建节点来源 | 分流逻辑 | 适用场景 |
|---|---|---|---|
Custom_Clash_Selfhosted_Manual_Fallback.yaml |
在 YAML 顶层 proxies 中直接填写静态节点参数 |
基于标准故障转移版扩展；自建节点组优先，订阅节点地区组后备 | 需要直接维护 VLESS、Hysteria2、TUIC 等协议参数的用户 |
Custom_Clash_Selfhosted_Provider_Fallback.yaml |
通过独立的 selfhost HTTP Proxy Provider 加载 |
基于标准故障转移版扩展；selfhost 优先，provider1 节点订阅后备 |
已有自建节点订阅、Provider YAML 或可通过 HTTP 获取的节点列表 |
两者都以自建节点作为首选出口、订阅节点作为后备。区别在于 Manual 版把节点参数直接写进 YAML，Provider 版只保存一个可通过 HTTP 获取的自建节点订阅地址。
Caution
Custom_Clash_Selfhosted_Manual_Fallback.yaml 中自带的节点仅为格式示例，服务器地址、端口、UUID、SNI、Reality 公钥、Short ID 等均为占位内容。未替换时节点不可用。
cfg/yaml 目录中有 10 个正式 YAML：
8 个常规 YAML
+ 1 个手动维护的自建节点 YAML
+ 1 个自建节点 Provider YAML
= 10 个 YAML
overwrite/yaml 目录中也有 10 个覆写模块：
8 个常规 YAML 的单独模块
+ 1 个 8 合 1模块
+ 1 个自建节点 Provider 模块
= 10 个模块
两者数量相同，但存在一个关键差异：
| 项目 | 是否有对应关系 | 原因 |
|---|---|---|
| 8 个常规 YAML | 各有 1 个同名单独模块 | 可以用统一的 EN_KEY1 写入 provider1.url
|
Custom_Clash_Selfhosted_Provider_Fallback.yaml |
有对应模块 | 可以分别用 EN_KEY1 和 EN_KEY2 写入节点订阅与自建 Provider URL |
Custom_Clash_Selfhosted_Manual_Fallback.yaml |
没有通用模块 | 静态节点协议和字段差异太大，不能用少量通用环境变量安全映射 |
Custom_Clash_8in1.conf |
没有同名 YAML | 它是 8 个常规 YAML 的统一选择器，通过 EN_KEY2 决定下载哪一个 YAML |
Important
因此，不要根据「文件数量都是 10 个」误以为它们完全一一对应。
cfg/yaml/Complete_YAML_Configuration_Template.yaml 用于展示 Mihomo 完整配置结构，包括端口、DNS、TUN、嗅探、GeoData 等参数。
该文件是学习和对照用模板，不计入上述 10 个正式 YAML，也不建议直接作为本方案配置导入。本项目正式 YAML 只保留节点来源、策略组、Rule Provider 和规则，其他运行参数交由 OpenClash LuCI 管理。
本项目的 8 个 .ini 模板均使用 订阅转换 后端完成订阅转换。OpenClash 本身不读取、不解析订阅链接，也不负责识别其中的节点协议；它只保存用户填写的订阅与转换参数，组合转换请求，并下载后端返回的 YAML。
完整流程如下（以本项目配套的 SubConverter-Extended 后端为例）：
用户在 OpenClash 中保存订阅与转换参数
↓
OpenClash 向后端发起转换请求
↓
后端读取所选 .ini 模板
↓
生成包含订阅、策略组和规则的 YAML
↓
OpenClash 下载生成结果
↓
OpenClash 根据 LuCI 设置再次覆写
↓
生成实际交给 Mihomo 内核的运行配置
.ini 文件本身不是 Mihomo 可以直接运行的配置。它描述的是后端应当生成哪些规则、策略组和节点分类，必须经过后端转换为 YAML。
订阅转换的主要优势不仅是首次添加简单，更在于后续维护方便。配置建立后，可以直接在 OpenClash 现有的订阅编辑界面修改模板、UDP、跳过证书验证、节点包含或排除关键词、自定义参数及更新时间，保存后重新更新即可生效。与覆写模块相比，它提供更多面向单个订阅的可调参数；与手动上传 YAML 相比，它不需要反复下载、编辑和上传文件。
模板套用、分流规则生成均由后端处理，因此订阅链接会提交给所选后端，最终结果也依赖后端的可用性。
Warning
订阅链接通常包含访问凭据。使用公共后端时，必须理解订阅地址会被提交给该后端。
对隐私和可靠性要求较高的用户，应自行部署后端，或改用本章 4.4、4.5 的 YAML 路径。
| 模板 | 分流规模 | 主要策略组类型 | 适用场景 |
|---|---|---|---|
Custom_Clash.ini |
标准 | select |
默认推荐；常见业务覆盖完整，仍可手动选择出口 |
Custom_Clash_Fallback.ini |
标准 | fallback |
默认推荐的自动切换版本；适合无人值守 |
Custom_Clash_Lite.ini |
轻量 | select |
不需要复杂流媒体和业务分组，重视简洁 |
Custom_Clash_Lite_Fallback.ini |
轻量 | fallback |
轻量配置并希望自动切换 |
Custom_Clash_GFW.ini |
极简 | select |
只代理 GFW 相关流量，其余默认直连 |
Custom_Clash_GFW_Fallback.ini |
极简 | fallback |
极简分流并希望自动切换 |
Custom_Clash_Full.ini |
重度 | select |
节点丰富，需要更多业务、地区和节点用途分类 |
Custom_Clash_Full_Fallback.ini |
重度 | fallback |
重度分流并希望所有主要业务组自动故障转移 |
Tip
不确定如何选择时：
-
需要自己在面板中决定出口：选择
Custom_Clash.ini； -
希望节点不可用时自动切换：选择
Custom_Clash_Fallback.ini。
Note
截至本文核对的 OpenClash 上游 dev 版本，内置模板列表已收录本项目 8 个订阅转换模板远程地址，直接从列表选择即可。
如果你使用的 OpenClash 旧版，需要选择「自定义模板」并填写远程地址。
以下步骤以当前 OpenClash 界面为准。不同固件、主题或 OpenClash 版本的按钮位置可能略有差异，但字段名称和流程基本一致。
- 进入 OpenClash 首页。
- 在「配置文件」卡片中点击「添加配置文件」。
- 在弹出的「添加配置文件」窗口中选择「订阅链接」。
Note
部分旧版 OpenClash 仍可从「配置订阅」页面点击「添加」，进入订阅编辑页。两种入口最终写入同类订阅配置，请以当前界面实际显示为准。
在「订阅 URL」中填写节点订阅地址。单个订阅直接填写一行；多个订阅可每行一个，或按界面提示使用 | 分隔。仅在服务商明确要求时修改 User-Agent 或添加 HTTP Header，否则保持 OpenClash 默认值即可。
- 启用「高级选项」。
- 启用「在线订阅转换」。
- 在「订阅转换服务地址」中选择
api.asailor.org。
该地址是本项目提供的 SubConverter-Extended 公共实例。区别于传统 subconverter 后端，该实例不解析或拉取订阅，因此不会被订阅服务商屏蔽。
Note
api.asailor.org 是订阅转换后端地址，不是节点服务，也不提供任何节点。使用其他地址时，也应确认后端为 SubConverter-Extended，并支持本项目模板所需功能。
直接在内置模板列表中选择对应条目：
| 目标模板 | OpenClash 内置名称 |
|---|---|
Custom_Clash.ini |
「Aethersailor 规则 标准版 Custom_Clash」 |
Custom_Clash_Fallback.ini |
「Aethersailor 规则 标准版 故障转移」 |
Custom_Clash_Lite.ini |
「Aethersailor 规则 轻量版 Custom_Clash_Lite」 |
Custom_Clash_Lite_Fallback.ini |
「Aethersailor 规则 轻量版 故障转移」 |
Custom_Clash_GFW.ini |
「Aethersailor 规则 极简版(GFW) Custom_Clash_GFW」 |
Custom_Clash_GFW_Fallback.ini |
「Aethersailor 规则 极简版(GFW) 故障转移」 |
Custom_Clash_Full.ini |
「Aethersailor 规则 重度分流版 Custom_Clash_Full」 |
Custom_Clash_Full_Fallback.ini |
「Aethersailor 规则 重度分流版 故障转移」 |
本项目模板已经定义策略组和规则，通常只需要调整与节点处理有关的参数。「UDP」可按节点和使用需求启用；skip-cert-verify 仅应在明确需要时开启。节点包含关键词可用于只保留指定地区、倍率或线路的节点，节点排除关键词可用于屏蔽过期、流量、官网、剩余、套餐等无效条目，多个关键词的写法以当前界面提示为准。「使用 Rule Provider」和其他自定义参数没有明确需求时保持模板默认设置。
这些参数并非只能在首次添加时设置。配置保存后，仍可在「配置订阅」页面打开原有订阅的编辑界面，随时切换模板、开关 UDP 或跳过证书验证、修改节点关键词和其他转换参数，然后保存并重新更新配置。一般不需要删除后重新添加订阅。
- 输入「配置名称」。
- 点击窗口下方的「添加配置」，等待进度条完成。
- 切换到 OpenClash 运行日志。
- 确认订阅转换后端访问成功。
- 确认转换后配置下载成功。
- 确认转换后配置测试成功。
- 确认转换后配置更新成功。
- 进入 OpenClash 的「配置订阅」页面，检查刚添加的配置是否已启用。
- 按需启用自动更新。
- 选择定时模式或循环模式，并设置更新时间。
- 建议将更新时间安排在网络空闲时段，例如凌晨。
- 点击「保存配置」。
- 在顶部导航栏选择并切换刚才更新的配置，观察运行日志，确认配置启动成功。
Caution
如果生成结果中的策略组与本项目模板明显不同，通常是模板没有正确下载、后端缓存异常、选错模板，或转换后端不兼容。不要在错误结果上继续修改，应先检查转换请求和运行日志。
本项目的 YAML 覆写模块不是「在现有配置末尾追加几条规则」，而是一套下载、写入并切换完整最小 YAML 的自动化流程。
执行过程如下：
查看覆写模块生成配置流程
远程覆写模块被下载并保存到
/etc/openclash/overwrite/<模块名>
↓
OpenClash 启动时读取已启用且匹配当前配置的覆写模块
↓
读取模块参数，并将 EN_KEY 导出为环境变量
↓
DOWNLOAD_FILE 下载对应 YAML 至
/etc/openclash/config/<配置名>.yaml
↓
CONFIG_FILE 临时指定本次启动使用的配置路径
↓
SUB_INFO_URL 关联订阅信息查询地址
↓
OpenClash 复制原始 YAML 至临时目录
/tmp/<配置名>.yaml
↓
yml_change.sh 根据 LuCI 设置修改配置
↓
yml_rules_change.sh 处理规则、策略组等内容
↓
执行覆写模块的 [Overwrite] / [YAML] 阶段
↓
ruby_map_edit 写入 proxy-providers.*.url
↓
规范化 provider 本地缓存路径
↓
生成最终运行配置
/etc/openclash/<配置名>.yaml
↓
Mihomo 加载运行配置
与订阅转换方式相比，覆写模块不会把节点订阅提交给第三方后端。YAML 中的 proxy-providers 会由 Mihomo 或 OpenClash 直接拉取节点来源，但规则版本和节点处理方式主要由远程 YAML 决定，不能像订阅转换那样在既有订阅编辑界面中随时调整模板、UDP、跳过证书验证或节点关键词筛选。
Warning
模块每次执行时会强制下载并覆盖 /etc/openclash/config/ 下的同名 YAML。不要在该同名文件中长期保存手动修改，否则下次执行模块时会被覆盖。
所有模块位于：
展开查看 10 个模块的完整 testingcf 地址
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_Fallback.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_Lite.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_Lite_Fallback.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_GFW.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_GFW_Fallback.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_Full.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_Full_Fallback.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_8in1.conf
https://testingcf.jsdelivr.net/gh/Aethersailor/Custom_OpenClash_Rules@refs/heads/main/overwrite/yaml/Custom_Clash_Selfhosted_Provider_Fallback.conf
GitHub Raw 备用地址使用相同文件名，前缀替换为：
https://raw.githubusercontent.com/Aethersailor/Custom_OpenClash_Rules/refs/heads/main/overwrite/yaml/
| 模块文件 | 下载的 YAML | 环境变量 | 用途与建议 |
|---|---|---|---|
Custom_Clash.conf |
Custom_Clash.yaml |
EN_KEY1：节点订阅 |
标准版；多数用户优先选择 |
Custom_Clash_Fallback.conf |
Custom_Clash_Fallback.yaml |
EN_KEY1：节点订阅 |
标准自动故障转移版 |
Custom_Clash_Lite.conf |
Custom_Clash_Lite.yaml |
EN_KEY1：节点订阅 |
轻量版 |
Custom_Clash_Lite_Fallback.conf |
Custom_Clash_Lite_Fallback.yaml |
EN_KEY1：节点订阅 |
轻量自动故障转移版 |
Custom_Clash_GFW.conf |
Custom_Clash_GFW.yaml |
EN_KEY1：节点订阅 |
极简 GFW 版 |
Custom_Clash_GFW_Fallback.conf |
Custom_Clash_GFW_Fallback.yaml |
EN_KEY1：节点订阅 |
极简 GFW 自动故障转移版 |
Custom_Clash_Full.conf |
Custom_Clash_Full.yaml |
EN_KEY1：节点订阅 |
重度分流版 |
Custom_Clash_Full_Fallback.conf |
Custom_Clash_Full_Fallback.yaml |
EN_KEY1：节点订阅 |
重度分流自动故障转移版 |
Custom_Clash_8in1.conf |
由 EN_KEY2 在 8 个常规 YAML 中选择 |
EN_KEY1：节点订阅；EN_KEY2：配置名称 |
适合经常切换版本；不确定时仍建议直接使用单独的标准模块 |
Custom_Clash_Selfhosted_Provider_Fallback.conf
|
Custom_Clash_Selfhosted_Provider_Fallback.yaml
|
EN_KEY1：节点订阅；EN_KEY2：自建节点订阅 |
自建 Provider 优先、订阅节点故障后备 |
8 个同名单独模块只需要填写一个变量：
EN_KEY1=https://example.com/subscription
优点是目标 YAML 固定、参数最少、不容易选错。已经确定长期使用某个版本时，优先选择单独模块。
Custom_Clash_8in1.conf 的使用方式如下。该模块适合已经决定采用覆写模块路径、但仍需要在 8 个常规 YAML 之间切换的用户；如果主要需求是频繁试用不同模板并调整节点过滤参数，订阅转换通常更方便。
EN_KEY1=https://example.com/subscription
EN_KEY2=Custom_Clash_Lite_Fallback
EN_KEY2 只允许填写下列值之一，且不要带 .yaml 扩展名：
Custom_Clash
Custom_Clash_Fallback
Custom_Clash_Lite
Custom_Clash_Lite_Fallback
Custom_Clash_GFW
Custom_Clash_GFW_Fallback
Custom_Clash_Full
Custom_Clash_Full_Fallback
EN_KEY2 留空时，默认使用：
Custom_Clash
Custom_Clash_Selfhosted_Provider_Fallback.conf 使用：
EN_KEY1=https://example.com/airport-subscription
EN_KEY2=https://example.com/selfhost-provider
其中，EN_KEY1 写入 proxy-providers.provider1.url 作为节点订阅，EN_KEY2 写入 proxy-providers.selfhost.url 作为自建节点来源。EN_KEY2 必须指向可通过 HTTP 或 HTTPS 获取且 Mihomo 能识别的内容，例如以 proxies: 开头的 Provider YAML、逐行节点 URI 订阅，或这类 URI 订阅的 Base64 编码内容。
Caution
单独一条 vless://、hysteria2:// 或 tuic:// 链接不是 HTTP Provider 地址，不能直接填入该模块的 EN_KEY2。
- 打开 OpenClash 首页。
- 在「运行状态」卡片中点击「覆写模块」。
- 进入覆写模块管理窗口。
- 点击模块卡片列表中的「+」。
- 在「添加覆写模块」窗口中选择「订阅链接」。
- 「文件名」可以填写模块原始文件名，例如
Custom_Clash.conf。 - 「配置文件」作用范围建议保持为「用于所有配置文件」。在当前界面中，不选择具体配置即表示用于所有配置。
- 「类型」选择「http」。
- 在「订阅 URL」中填写对应
.conf的 testingcf 远程地址。 - 按需设置模块更新时间。
Note
希望自动跟随本项目更新时，可设置每日或每周在不用网时更新；希望长期固定当前逻辑时，应关闭自动更新，或自行托管固定版本的模块和 YAML。远程 YAML 更新不会合并本地修改，而是直接覆盖同名文件。
「用于所有配置文件」适合本章这类会自行下载并切换 CONFIG_FILE 的完整配置模块。只有在明确理解模块作用范围，并希望模块仅对部分已有配置生效时，才选择具体配置文件。
当前新版 OpenClash 使用「添加参数」按钮，分别填写「Key」和「Value」。
| Key | Value |
|---|---|
EN_KEY1 |
节点订阅链接 |
| Key | Value |
|---|---|
EN_KEY1 |
节点订阅链接 |
EN_KEY2 |
8 个允许值之一，例如 Custom_Clash_Fallback
|
| Key | Value |
|---|---|
EN_KEY1 |
节点订阅链接 |
EN_KEY2 |
自建节点 HTTP Provider 或订阅链接 |
旧版 OpenClash 如果只提供单行参数输入框，则使用分号连接：
EN_KEY1=https://example.com/subscription;EN_KEY2=Custom_Clash_Fallback
Warning
截图、导出配置、提交 Issue 或分享日志前，必须遮挡 EN_KEY1、EN_KEY2 中的真实订阅地址和认证信息。
- 在模块卡片上启用该模块。
- 点击模块卡片上的刷新按钮，立即拉取一次远程模块。
- 关闭覆写模块窗口，点击首页「运行状态」中的开关启动 OpenClash。
- 打开运行日志检查执行结果。
- 确认模块已下载 YAML、写入订阅并触发 OpenClash 重启。
首次执行后，应确认 .conf 下载成功、目标 YAML 已写入 /etc/openclash/config/、环境变量进入正确的 Provider、当前配置已切换到目标 YAML，并且 Provider 更新、配置校验和 OpenClash 启动均无错误。
需要更换规则版本时：
- 打开
Custom_Clash_8in1.conf模块设置。 - 修改
EN_KEY2。 - 保存设置。
- 手动刷新模块。
- 检查当前配置文件名是否已切换。
- 检查策略组与规则是否符合新版本。
不要通过修改已下载 YAML 的文件名来切换版本，8 合 1 模块以 EN_KEY2 为唯一选择依据。
本目录模块会设置 CONFIG_FILE 并触发重启。同时启用多个完整配置覆写模块时，后执行的覆写模块可能覆盖前一个覆写模块，当前配置也可能在不同 YAML 之间反复切换，自动更新时间重叠后尤其难以排查。
Important
在本章「三选一」的原则下，通常只启用一个本目录覆写模块。需要切换版本时，停用旧模块后再启用新模块，或使用 8 合 1 覆写模块。
手动 YAML 路径的流程如下：
从 GitHub 下载本项目 YAML
↓
上传到 OpenClash 配置管理
↓
编辑 proxy-providers 或 proxies 并保存
↓
OpenClash 根据 LuCI 设置覆写
↓
Mihomo 直接拉取 Provider 并运行
本项目的正式 YAML 是 OpenClash 专用的最小配置，主要保留 proxy-providers、proxy-groups、rule-providers 和 rules；只有自建 Manual 版额外使用顶层 proxies 保存静态节点。
端口、运行模式、DNS、IPv6、TUN、嗅探、GeoData、日志和控制器等参数由 OpenClash LuCI 根据前文章节的设置写入，不需要在本项目最小 YAML 中重复维护。
该方式不经过订阅转换，也不需要远程覆写模块。Mihomo 或 OpenClash 会直接从 YAML 中的 proxy-providers 地址拉取节点。与订阅转换相比，YAML 的控制范围更完整，但切换分流版本、修改节点过滤方式或调整 Provider 时都需要重新编辑并上传文件，日常维护不如直接编辑订阅参数方便。
Note
手动上传的 YAML 不会自动合并本项目后续更新。需要升级时，应备份当前可用配置，再对比新旧文件迁移 Provider、策略组和规则变化。
| YAML 文件 | 类型 | 节点来源 | 建议 |
|---|---|---|---|
Custom_Clash.yaml |
标准普通版 |
provider1 节点订阅 |
多数用户优先选择 |
Custom_Clash_Fallback.yaml |
标准故障转移版 |
provider1 节点订阅 |
希望自动故障转移时优先选择 |
Custom_Clash_Lite.yaml |
轻量普通版 |
provider1 节点订阅 |
结构简洁、业务分组较少 |
Custom_Clash_Lite_Fallback.yaml |
轻量故障转移版 |
provider1 节点订阅 |
轻量且自动切换 |
Custom_Clash_GFW.yaml |
极简 GFW 普通版 |
provider1 节点订阅 |
只需要基础代理逻辑 |
Custom_Clash_GFW_Fallback.yaml |
极简 GFW 故障转移版 |
provider1 节点订阅 |
极简且自动切换 |
Custom_Clash_Full.yaml |
重度普通版 |
provider1 节点订阅 |
需要更多业务、地区和节点用途分类 |
Custom_Clash_Full_Fallback.yaml |
重度故障转移版 |
provider1 节点订阅 |
复杂分流且自动切换 |
Custom_Clash_Selfhosted_Manual_Fallback.yaml |
自建节点手动维护版 | 顶层 proxies 静态节点与 provider1 节点订阅 |
需要直接填写自建节点协议参数 |
Custom_Clash_Selfhosted_Provider_Fallback.yaml |
自建节点 Provider 版 |
selfhost 自建订阅与 provider1 节点订阅 |
已有可通过 HTTP 获取的自建节点来源 |
普通节点订阅用户优先使用 Custom_Clash.yaml；希望自动切换时使用 Custom_Clash_Fallback.yaml。自建节点需要直接填写协议参数时选择 Manual 版，已有 HTTP Provider 或订阅时选择 Provider 版。
-
打开仓库中的
cfg/yaml目录：https://github.com/Aethersailor/Custom_OpenClash_Rules/tree/main/cfg/yaml -
点击需要的 YAML 文件；
-
点击 GitHub 文件页面右上角的下载原始文件按钮，或进入「Raw」页面后保存；
-
保持原始
.yaml扩展名。
Warning
不要把 GitHub 网页本身另存为 .yaml。必须下载原始文件，否则保存的可能是 HTML 页面，OpenClash 无法解析。
- 返回 OpenClash 首页；
- 在「配置管理」卡片中点击添加配置文件区域的「选择文件」。
- 选择刚才下载的 YAML 文件，然后点击「上传」。
- 配置文件上传后，点击对应条目中的「编辑」。
- 将
url替换为订阅链接，保存并返回。 - 返回首页，点击开关启动 OpenClash。
- 查看运行日志，确认 OpenClash 启动正常。
在 YAML 中找到：
proxy-providers:
provider1:
type: http
url: "url" # 填入订阅链接将：
url: "url"替换为实际使用的第三方服务订阅链接：
url: "https://example.com/your-subscription"保留双引号，其他内容不需要修改。
Caution
只替换 provider1 下的占位订阅地址，不要使用全文替换把规则下载地址、健康检查地址等其他 URL 一并改掉。
需要多个 Provider 时，可以复制 provider1，依次命名为 provider2、provider3：
proxy-providers:
provider1:
type: http
url: "https://example.com/sub1"
interval: 3600
path: ./proxy_provider/provider1.yaml
proxy: DIRECT
provider2:
type: http
url: "https://example.com/sub2"
interval: 3600
path: ./proxy_provider/provider2.yaml
proxy: DIRECT同时还必须：
- 为每个 Provider 设置不同的名称；
- 为每个 Provider 设置不同的
path； - 将新增 Provider 加入需要使用它的策略组
use列表。
例如：
use:
- provider1
- provider2只复制 Provider 而不加入策略组 use，新 Provider 的节点不会出现在相关策略组中。
Custom_Clash_Selfhosted_Manual_Fallback.yaml 中需要同时处理两部分：
- 在
provider1.url填写节点订阅。 - 在顶层
proxies中替换自建节点示例。
示例中的以下字段必须按服务端实际配置修改：
server
port
uuid
servername
public-key
short-id
使用其他协议时，可以删除整个 VLESS 示例节点，再按照 Mihomo 官方格式填写 Hysteria2、TUIC、SS、Trojan 等节点。
Custom_Clash_Selfhosted_Provider_Fallback.yaml 中需要填写：
proxy-providers:
provider1:
url: "节点订阅地址"
selfhost:
url: "自建节点 HTTP Provider 或订阅地址"selfhost.url 不能直接填写单条节点 URI，必须是可通过 HTTP 或 HTTPS 获取的订阅或 Provider 文件。
Important
手动 YAML 方式的最大优点是配置完全由用户控制，代价是也需要由用户自行维护。本项目更新 YAML 后，本地文件不会自动获得新规则、策略组或修复，需要自行对比并迁移变更。
进入第 5 章前，应确认只启用了一种配置路径，当前配置与预期版本一致，节点 Provider 和 Rule Provider 均可更新，策略组结构与所选版本相符，配置校验通过，日志中没有明显的 YAML、Provider 或模块错误，并保留一份已验证配置用于回退。
订阅转换用户继续按第 5.1 节更新配置；覆写模块用户在首次刷新并成功重启后可从第 5.2 节继续；手动 YAML 用户选择刚上传的配置并启动后，同样从第 5.2 节继续。三种路径最终都必须检查运行日志和控制面板。
完成订阅和分流配置后，点击首页「运行状态」中的开关启动插件。
在上一步操作中点击「启动开关」后，切换到运行日志页面观察 OpenClash 的启动情况。
日志中出现「OpenClash 启动成功，请等待服务器上线！」后，表示 OpenClash 已成功启动。
在 OpenClash 的「运行状态」页面中，点击「控制面板」按钮启动控制面板。
OpenClash 内置多款控制面板，可以根据使用习惯选择；新手可以先使用 Zashboard。
在控制面板中可以根据个人喜好与实际出站配置，调整各策略组的默认出站项。
本项目模板中预置的策略组结构通常足以应对大部分分流需求。
Tip
如果某些策略组默认指向当前配置中不存在的分组或出站项，请在控制面板中手动切换到可用项。
使用故障转移规则时，不要手动切换策略组。
请观察 Zashboard 中的策略组是否与截图所示的本项目模板大体一致。由于截图可能滞后，实际内容可能略有不同。
如果差异较大，通常表示模板或规则未正确拉取，或缓存尚未更新。请先排除网络问题，确保后端能够访问远程模板。
至此，OpenClash 的完整设置已经完成。日常使用中通常不需要频繁维护，并会按照设置定期更新上游规则；插件、规则源或网络环境发生变化后，仍建议检查运行日志与更新结果。
请按照以下步骤检查本方案的设置效果。
Caution
Clash 面板中的「漏网之鱼」策略组不要选择直连，否则将无法通过 DNS 泄漏检测网站的测试。
访问 IPLEAK.NET 检查是否存在 DNS 泄漏。
正常情况下，页面上方应显示当前出站的 IPv4 和 IPv6 地址（或仅 IPv4）；页面下方不应显示本地网络或运营商 DNS 服务器条目。
DNS 泄漏检测请以 IPLEAK.NET 和 BrowserLeaks DNS 的结果为准。
某些 DNS 泄漏检测网站，例如 BrowserScan DNS Leak Test，其检测服务器使用部分 DDNS 服务商的域名。为避免影响 DDNS 服务，本项目规则会强制直连 DDNS 类域名，并使用本地解析器处理。因此，这类检测网站可能显示「泄漏」，属于正常现象，可以忽略。
仅限第三方远端服务支持 IPv6 出站的情况。
Important
建议优先使用 Edge、Chrome 或其他 Chromium 内核浏览器进行 IPv6 测试，并提前关闭浏览器的安全 DNS 功能。
Firefox 默认支持 IPv6，也可以用于测试。如果此前在 about:config 中手动禁用了 IPv6，请先恢复默认设置。
访问 IPv6 测试网站：https://ipv6-test.com/
网页中的「Address」项目应显示当前第三方远端服务出站的 IPv4 和 IPv6 地址。两个地址均显示时，表明 IPv4 和 IPv6 出站都在正常工作。
分别访问 test-ipv6 测试网站的镜像站点和原站点：
镜像站点：https://testipv6.cn/
访问镜像站点时，检测页面应显示宽带的 IPv4 和 IPv6 地址，以及本地运营商名称（如 CHINA UNICOM），并以 10/10 的评分通过测试。
启用 OpenClash 后，访问远端站点时，检测页面应显示当前第三方远端服务出站的 IPv4 和 IPv6 地址，以及对应的网络运营商信息，并以 10/10 的评分通过测试。
如果以上两个网站测试均通过，说明 IPv6 分流已达到本方案的预期结果。
至此，OpenWrt 已完成本方案的 OpenClash 设置；各项细节均已尽力兼顾性能、安全与效率，后续可根据实际网络环境继续微调。
请查看：故障排除
如仍异常，可在 GitHub Issues 中描述问题并附上运行日志与复现步骤。