外观
读懂 Clash 配置文件：proxies、proxy-groups 与 rules
Clash 配置文件是一份 YAML 文本，主体由三段组成：proxies 列出可用的节点，proxy-groups 把节点组织成可以选择或自动切换的策略组，rules 则按顺序决定每一个连接该交给哪个策略组或直接放行。
读懂这三段的依赖关系，再加上端口、DNS、模式等全局字段，就能解释大多数“节点明明在却连不上”的现象。本文只讲通用结构与排查方法，不涉及具体版本与菜单。
核心结论与适用条件
- 如果你拿到的是机场提供的订阅配置，那么多数情况下不需要从头手写，但需要能看懂它：知道节点在哪一段、策略组引用了谁、规则最后落到哪里。能读懂比能写更重要。
- 如果节点在列表里却全部不可用，那么先查 proxies 段中的协议字段是否被当前内核支持。品牌资料标注 VLESS 的机场，需要使用支持该协议的内核，这一点在协议基础页和 mihomo 内核一文里有解释。
- 如果部分网站走了代理、部分没走，那么问题几乎总是出在 rules 的顺序或兜底规则，而不是节点本身。
- 如果你直接修改了订阅下发的配置文件，那么订阅更新时很可能被覆盖。需要长期保留的改动，应放到客户端提供的覆写或合并机制里，或者另存为独立配置。
- 如果你在 Linux 上只运行内核加配置文件，那么本文的结构知识是必备的，因为没有图形界面替你检查字段，可参考Linux 桌面方案。
以上结论的前提是：配置文件来自可信来源，内核来自官方发布渠道。YAML 对缩进极为敏感，同一份配置在不同内核上对未知字段的容忍度也不同，本文不给出任何具体默认值。
先建立整体画面：一份配置的五个区域
把配置文件想成一张“流量处理说明书”。一个连接进来，客户端要回答四个问题：从哪个端口收到的、域名怎么解析、命中了哪条规则、规则指向的出口是哪个节点。对应的配置区域大致如下：
- 全局基础字段：本地监听端口、是否允许局域网连接、运行模式、日志级别等。这些字段决定“入口”的形态。
- DNS 段：决定域名由谁解析、是否使用加密 DNS、是否使用假 IP 映射。
- proxies 段：节点的清单，每个节点是一个映射，含名称、类型、服务器地址、端口及协议特有字段。
- proxy-groups 段：策略组，把节点或其他策略组组合成“选择器”“自动测试组”“故障转移组”等。
- rules 段：自上而下匹配的规则列表，最后通常有一条兜底。
此外还可能有 proxy-providers、rule-providers 这类“外部清单”字段，让节点或规则从远程地址拉取，而不是写死在主文件里。机场订阅下发的完整配置通常把前几段直接内嵌，而自己维护的配置更常使用 providers 来拆分。
理解这个模型的好处是排错有了顺序：入口不通查端口与接管层，解析异常查 DNS，节点不可用查 proxies，选错出口查 proxy-groups，分流不对查 rules。
YAML 的几条基本规矩
- 缩进用空格，不要用制表符；同一层级的缩进必须一致。
- 列表项以短横线开头，映射以“键: 值”表示，冒号后要有一个空格。
- 含有特殊字符的字符串（例如以星号、井号、冒号开头，或包含冒号加空格）应当加引号，否则可能被解析成别的类型。
- 节点名称里常见的国旗符号、空格和括号本身是合法的，但在策略组和规则中引用时必须与 proxies 里的名称逐字相同。
- 注释以井号开头。排错时可以把可疑段落暂时注释掉，观察变化，但改动前先保存一份原文件副本。
很多“配置文件打不开”的问题只是缩进错了一格，内核会在日志里报出行号附近的解析错误，先读日志再动手是更省时间的做法。
proxies：节点清单到底写了什么
proxies 是一个列表，列表里每一项描述一个出口节点。无论协议是什么，每项都至少包含这几类信息：
- name：节点的唯一名称，后面策略组靠它引用。名称重复会导致引用歧义，是合并多份订阅时的常见问题。
- type：协议类型，例如 ss、vmess、trojan、vless、hysteria2 之类。type 决定后面还要有哪些字段。
- server 与 port：节点服务器的地址和端口。
- 认证字段：例如密码、UUID。不同协议名称不同，但本质都是“我是被授权的客户端”。
- 传输与安全字段：例如是否启用 TLS、传输层使用 WebSocket 还是 gRPC、是否设置 SNI、是否启用 REALITY 相关参数、是否指定 uTLS 指纹。这类字段是 VLESS 一类协议配置的重点。
- 可选的 udp 开关等能力字段。
这里有一个很容易忽略的事实：proxies 段只是“声明节点存在”，并不代表节点可用，更不代表会被使用。节点要被用到，必须被某个策略组引用，而该策略组又被某条规则引用。三层引用缺一层，节点就是摆设。
协议字段与内核能力
不同内核对协议的支持范围不同。原版 Clash 内核不支持 VLESS，因此带有 VLESS 节点的配置在这类内核上会忽略这些节点或直接报错；mihomo 内核等后续分支支持更多协议和传输方式。具体到哪个内核支持哪些字段，请以该内核自己的文档为准，本文不列举。
读配置时可以用一个小办法判断兼容性：先统计 proxies 里出现了哪些 type，再看你使用的内核文档是否都列出了这些类型。如果机场品牌资料标注 VLESS，而你的内核不认，那就不是配置写错，而是内核选错。brands.json 中 17 个品牌有 12 个标注 VLESS，另有 5 个协议字段待核实，因此“确认协议再选内核”不是可选动作。
proxy-groups：把节点变成可操作的出口
策略组是配置里最灵活也最容易写乱的部分。它回答的问题是：规则指向“某个出口名”之后，真正走哪个节点？
常见的策略组类型
- select（手动选择）：由使用者在界面里点选当前出口。适合需要人工确定出口的场景，例如某个服务只能用特定地区节点。
- url-test（延迟测试自动选择）：定期对组内节点做探测，自动选延迟最小者。适合通用上网，但探测目标本身不代表你真正访问的目标，延迟最小不等于访问体验更顺畅。
- fallback（故障转移）：按顺序使用第一个可用的节点，当前面的探测失败再往后切换。适合作为备用链路，参见故障转移策略组一文。
- load-balance（负载均衡）：把连接分散到多个节点。它会让同一用户在短时间内出现多个出口地址，对某些要求出口稳定的服务并不友好，使用前要想清楚。
- relay 或链式代理：把多个节点串联。链式会叠加延迟与故障点，除非有明确需求，一般不必使用。
具体字段名称与取值请以所用内核的文档为准。这里强调的是思路：策略组可以嵌套，一个组的成员可以是另一个组。
一个常见的组织方式
很多订阅配置采用“总入口组加若干功能组”的结构：
- 一个顶层选择组，成员包括自动测试组、若干地区组和直连选项。
- 若干地区组，成员是按名称筛选出来的节点。
- 若干功能组，例如“AI 服务”“流媒体”“国内直连”，分别可以指向顶层组、某个地区组或直连。
这样做的好处是：规则只需要写“这个域名走 AI 服务组”，用户想换出口时，只改一个组的选择，而不必改规则。坏处是层级多了之后排错路径变长：你需要沿着“规则 → 功能组 → 地区组 → 节点”逐层向下看。
rules：从上到下的匹配逻辑
rules 是一个自上而下的有序列表，每一条形如“规则类型, 匹配内容, 目标”。内核对每个连接依次比对，命中第一条就停止。这个“首个命中”的原则是理解分流行为的核心。
常用的规则类型
- DOMAIN：精确匹配某个域名。
- DOMAIN-SUFFIX：匹配域名后缀，例如某个主域名及其所有子域。
- DOMAIN-KEYWORD：域名包含某个关键词即命中，容易误伤，使用要克制。
- IP-CIDR：按目标 IP 段匹配，常用于局域网和已知地址段。
- GEOIP：按目标 IP 的地理归属库匹配，依赖本地地理库，库过期会影响判断。
- PROCESS-NAME：按发起连接的进程名匹配，在支持的平台上可对某个应用单独分流。
- RULE-SET：引用一个外部规则集，内含大量域名或 IP 规则。
- MATCH：兜底，匹配所有未命中的流量。
规则类型的完整列表和写法随内核而异，需要查阅所用内核的文档。
顺序决定一切
先看一个示例口径（假设化）：规则列表里先有一条“把某类服务的域名后缀交给 AI 服务组”，后面有一条“所有境外地理归属的 IP 交给顶层组”。某个域名同时满足两条时，只有前一条生效。如果你把顺序颠倒，较宽的规则会吞掉较窄的规则，较窄的规则就永远不会被触发。
经验上的排列思路是：更具体的放前面，更宽泛的放后面，兜底放最后。具体到你的配置，应该是：
- 先放拒绝类和必须直连的局域网、本机地址。
- 再放对特定服务的精确规则，例如需要固定出口的服务。
- 接着放大范围规则集，例如国内直连集合、境外代理集合。
- 最后放 GEOIP 之类的粗粒度规则和 MATCH 兜底。
兜底规则的取舍
MATCH 指向什么，决定了“没被任何规则覆盖的流量”怎么走：
- 兜底走代理：未知流量默认出境，规则集漏掉的境内网站也会被代理，表现为部分国内网站变慢或异常。
- 兜底走直连：未知流量默认直连，规则集漏掉的境外服务会连不上，表现为“新出现的某个服务打不开”。
没有哪一种绝对正确，取决于你的主要流量是哪一类。关键是你清楚自己的配置选了哪一种，这样症状出现时能立刻对应。三种出站模式（规则、全局、直连）的使用时机，另见出站模式文章。
规则集与域名解析的交互
一条域名规则能否命中，取决于内核是否拿到了域名。如果客户端通过系统代理收到的是带域名的请求，规则可以直接匹配域名；如果流量是由 TUN 在网络层接管的，客户端首先看到的是 IP，需要借助假 IP 映射或嗅探把域名还原出来。因此 TUN 模式下，DNS 段的配置直接影响规则能不能按域名命中，详见TUN 模式文章。
IP 类规则还有一个细节：内核可能需要先解析域名才能比对 IP 规则。很多配置提供了“跳过解析”的选项，让这类规则只在已经拿到 IP 时才参与匹配，避免为了判断规则而提前发起解析。是否使用，要根据你对 DNS 泄露与延迟的权衡决定。
DNS 段：被低估的一环
DNS 段决定域名解析的来源与方式，它和规则分流是耦合的。常见的概念有：
- 上游解析服务器：可以是系统解析器，也可以是加密 DNS（DoH、DoT）端点。
- 国内外分流解析：对国内域名使用一类上游，对其他域名使用另一类上游，以降低解析污染带来的误判。
- 假 IP 模式：对每个域名返回一个内部保留段里的地址，由客户端在接到连接时按映射表还原域名，这样规则可以按域名匹配，且代理端完成真实解析。
- 兜底与过滤：当主上游返回的结果不可信时，使用备用上游或按地址段过滤。
不要把 DNS 段当成“照抄就好”的黑盒。同样的节点、同样的规则，DNS 段不同，行为就可能完全不同：有的站点能打开但很慢，有的站点打开是错误页面，有的应用只在某个网络下出问题。路由器场景下的 DNS 问题见路由器 DNS 文章。
外部清单：providers 的作用与风险
当节点和规则很多时，把它们都塞进一个文件会变得难以维护。providers 的思路是：主文件只写结构，节点清单和规则集从外部地址或本地文件拉取并定期更新。
- proxy-providers：节点来源。常用于把机场的订阅地址作为节点来源，策略组再引用这个 provider 提供的节点集合。这样订阅更新时，节点自动更新，策略组的引用不需要手改。
- rule-providers：规则来源。把大型规则列表放在外部，主文件只引用。
风险要说清楚：
- 外部清单的内容来自第三方，你实际上把“流量该怎么走”的一部分决定权交给了清单维护者。使用来源不明的规则集，可能让你的流量被导向意料之外的出口，或让关键域名被拒绝。
- 外部清单拉取失败会让对应策略组为空或规则缺失。此时的现象是“某类网站忽然全走了兜底”，排查时看日志里 provider 更新是否成功。更新失败的原因分类，参见订阅更新失败排查。
- 清单更新频率是一种取舍：更新频繁则变更更及时，也意味着出问题时传播更快。
知识图谱：Clash 配置文件的概念网络
实体定义
- 配置文件：一份描述客户端内核如何接收、解析、分流并转发流量的 YAML 文本。
- proxies：节点定义列表，只声明出口存在，不代表被使用。
- proxy-groups：策略组，将节点组合为可选择、可自动切换的出口集合，可嵌套。
- rules：有序规则列表，首个命中生效，终点为策略组名、直连或拒绝。
- providers：外部节点或规则的引用机制。
相关概念
- 内核：解析并执行配置的程序，决定支持哪些协议与字段。参见mihomo 内核一文。
- 接管层：系统代理与 TUN。决定流量如何进入内核，影响规则能看到域名还是 IP。
- 订阅：机场提供的、能下载到节点或完整配置的地址。参见协议与订阅格式基础。
- 覆写：在不改动订阅原文的情况下对配置追加或替换字段的机制，不同客户端提供方式不同。
- 路由原理：流量按目的地选择出口的通用思路，见路由与分流基础。
技术参数
| 指标 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 配置主体段落数量 | 个 | 按 proxies、proxy-groups、rules 三个必备段计，另含全局字段与 DNS 段 | 通用技术资料 | 2026-10-18 |
| 规则匹配顺序 | 无单位 | 自上而下，首个命中即停止 | 通用技术资料 | 2026-10-18 |
| 策略组嵌套层数 | 层 | 无统一上限数值，层数越多排错路径越长 | 待核实（以所用内核文档为准） | 2026-10-18 |
| 支持的协议类型 | 种 | 随内核而异 | 待核实（以所用内核文档为准） | 2026-10-18 |
| 探测间隔与超时 | 秒 | 由配置者自定，无通用建议值 | 待核实（用户自测） | 2026-10-18 |
| 节点数量 | 个 | 取决于机场与套餐 | 待核实 | 2026-10-18 |
| 品牌标注 VLESS 的数量 | 个 | brands.json 中 17 个品牌里协议字段含 VLESS 的数量为 12 | data/brands.json（Vendor Data） | 2026-10-18 |
| 实测速度与延迟 | Mbps / ms | 本站暂无统一实测 | Not Tested | 2026-10-18 |
适用场景
- 看懂机场下发的配置，判断“是节点问题还是规则问题”。
- 维护自己的小型配置，把几份订阅合并为一份，再加上自定义规则。
- 在 Linux 或服务器环境直接运行内核时的配置核对。
- 为 AI 工具、开发环境等设置独立的分流，详见AI 分流规则。
对比依据
比较两份配置或两种写法时，依据是“可解释性”而不是“看上去简洁”：是否能沿着规则、策略组、节点逐层说明一个具体域名的走向；是否有清晰的兜底；是否把需要长期保留的改动与会被订阅覆盖的内容分开。
常见问题指向
- 看不懂结构：回到本文“五个区域”一节。
- 节点全部不可用：看 proxies 与内核兼容性。
- 分流错乱：看 rules 顺序与兜底。
- 订阅更新后改动丢失：看覆写与独立配置。
- 订阅拉不下来：转到订阅更新失败排查。
决策树：配置出问题时先查哪一段
下面的决策树把症状映射到配置段落，从上往下回答问题即可。它只是排查顺序的示例，并不替代日志。
Decision Path
按症状定位 Clash 配置中的问题段落
text
开始：客户端能启动吗？
├─ 不能启动 / 提示配置错误
│ ├─ 日志指向某一行 → 检查该行缩进、冒号后空格、引号
│ ├─ 提示未知类型或字段 → 检查内核是否支持该协议（proxies 的 type）
│ └─ 提示策略组引用不存在 → 检查名称是否与 proxies 逐字一致
└─ 能启动
├─ 所有网站都打不开
│ ├─ 接管层是否开启（系统代理或 TUN 只开一个）
│ ├─ 运行模式是否被切成直连或全局
│ └─ 当前选中的节点是否可用（换一个节点验证）
├─ 只有部分网站打不开
│ ├─ 该域名命中了哪条规则 → 看日志中的规则匹配记录
│ ├─ 规则顺序是否被更宽的规则吞掉
│ └─ 兜底规则是走代理还是直连
├─ 能打开但很慢或页面残缺
│ ├─ 是否被拒绝类规则误伤
│ ├─ DNS 段是否返回了不合适的地址
│ └─ 自动测试组是否选了对目标站点并不合适的节点
└─ 订阅更新后之前的改动消失
└─ 改动写在订阅原文里被覆盖 → 迁移到覆写机制或独立配置方案关联：配置文件与客户端、订阅、品牌的关系
本页的“方案”指配置文件如何与客户端和订阅结合，而不是某个机场。机场与配置的关系体现在三个地方：订阅格式是否直接是 Clash 格式、节点协议是否为内核所支持、客户端是自研还是第三方。brands.json 中的客户端字段给出了这类信息，例如光速云标注为自研客户端加第三方订阅导入，协议标注 VLESS；星岛梦标注为支持第三方客户端订阅导入，协议待核实。这些均为 Vendor Data，不代表实测，也不构成推荐。
| 品牌 | 协议（Vendor Data） | 客户端方式（Vendor Data） | 对读配置的含义 |
|---|---|---|---|
| 光速云 | VLESS | 自研客户端+第三方订阅导入 | 使用第三方 Clash 系客户端时内核需支持 VLESS |
| 星岛梦 | 待核实 | 支持第三方客户端订阅导入 | 协议类型需导入后在 proxies 中核对 |
| 唯兔云 | VLESS | 根据官方订阅格式使用对应客户端 | 先确认官方订阅格式，再选择客户端 |
如果想在品牌库里按客户端支持和协议筛选，可以直接进入品牌库，也可以回到选型清单核对客户端兼容这一项。想知道几类桌面客户端之间怎么比较，可以看桌面客户端对比。
动手核对：拿到一份陌生配置后的七步
- 保存原文件副本，再在副本上操作。
- 通读全局字段：本地端口是什么，是否允许局域网连接，运行模式是什么。允许局域网连接意味着同一网络的其他设备可能使用你的代理端口，风险见下文。
- 统计 proxies 中的 type，对照内核文档确认兼容。
- 抽查几个节点：名称是否唯一，服务器与端口是否完整，认证字段是否齐全。不要把这些字段复制到公开场合，它们等同于你的使用凭证。
- 列出所有策略组及其成员，画出引用关系，确认没有引用不存在的名称，没有形成循环引用。
- 逐条阅读 rules，标出兜底，并判断是否有较宽规则排在较窄规则之前。
- 对一个具体域名做走向推演：先看有没有 DNS 相关处理，再看它命中哪条规则，规则指向哪个组，组当前选中哪个节点。然后在客户端日志里验证推演是否一致。
第七步是理解配置的有效练习。如果推演与日志不一致，差异本身就是线索：多半是顺序、嗅探或 DNS 的问题。
常见的配置错误清单
- 缩进混用空格与制表符。
- 节点名称含特殊字符未加引号。
- 策略组引用了一个已经不存在的节点名称，通常发生在订阅更新之后。
- 规则的目标写成了不存在的策略组名，名称大小写或符号不同也算不存在。
- 把 MATCH 写在中间，使其后的规则全部失效。
- 把大量关键词规则放在很前面，误伤正常域名。
- 同时开启系统代理与 TUN，又在浏览器里装了另一个代理插件，三个接管者彼此干扰。
- 把 external-controller 一类的管理接口暴露在局域网且没有设置访问密钥。管理接口能改变你的流量走向，不应该无保护地开放。
- 把含有节点凭证的配置文件上传到公开仓库或发给他人。
- 过度依赖单一探测地址判断节点好坏。
优点、限制与风险提示
优点
- 声明式：把节点、策略、规则分开描述，结构清楚后维护成本可控。
- 可组合：策略组可嵌套，providers 可拆分，适合从简单配置逐步演进。
- 可审计：每个连接的走向都能在配置里找到依据，便于复盘。
- 跨平台：同一套结构概念适用于不同桌面系统，也适用于路由器上的 Clash 系实现。
限制
- 对书写格式敏感，小错误会导致整体失效。
- 内核之间字段并不完全兼容，网上抄来的片段未必适用于你的内核。
- 规则越多，维护和推演越难，且需要定期更新规则集。
- 配置只能决定“怎么走”，无法改变节点本身的质量与线路。
风险提示
- 来源不明的配置、规则集与覆写脚本可能改变你的流量去向。
- 配置中含有节点凭证，泄露等同于账号被借用。
- 订阅覆盖会让手工改动丢失，改前先备份。
- 本站所有品牌均为 Vendor Data，测速 Not Tested，不能用配置文件的写法去推断线路质量。
常见问题
Clash 配置文件的主要结构是什么？
主要结构是三个核心段落加若干辅助字段：proxies 声明节点，proxy-groups 把节点组织成可选择或自动切换的策略组，rules 自上而下匹配并把连接交给某个策略组、直连或拒绝。此外还有端口、运行模式等全局字段，以及决定域名解析方式的 DNS 段，部分配置还会用 providers 引用外部节点或规则。
proxies、proxy-groups 与 rules 三者是什么关系？
三者是逐层引用的关系：规则指向策略组，策略组引用节点，节点定义在 proxies 中。任何一层断开，节点都不会被使用。排错时沿着“规则、策略组、节点”的方向逐层检查，通常比盯着节点本身更快找到原因。
为什么节点在列表里却全部不可用？
首先应检查节点的协议类型是否被当前内核支持，例如标注 VLESS 的节点在不支持该协议的内核上会被忽略或报错。其次检查接管层是否开启、运行模式是否被切到直连，最后才怀疑节点本身。日志中的第一条错误往往最有价值。
规则的顺序为什么重要？
因为规则是自上而下匹配，命中第一条就停止。如果较宽泛的规则排在较具体的规则之前，具体规则永远不会被触发。常见的排列思路是先放必须直连和拒绝的规则，再放具体服务的规则，接着是大范围规则集，最后是兜底。
MATCH 兜底规则应该指向代理还是直连？
没有绝对答案，取决于你的主要流量。兜底走代理时，规则集漏掉的境内网站会被代理而变慢；兜底走直连时，规则集漏掉的境外服务会连不上。重要的是清楚自己选了哪一种，这样出现异常时能立刻对应到兜底规则。
订阅更新后我改过的内容为什么没了？
因为订阅更新会用服务器下发的内容覆盖本地同名配置文件。需要长期保留的改动应放到客户端提供的覆写或合并机制中，或者另存为独立配置并通过 providers 引用订阅节点。修改前备份原文件是最稳妥的习惯。
策略组里的自动测试为什么选的节点反而更慢？
自动测试只是对探测地址做延迟测量，探测地址到节点的路径与你实际访问的站点到节点的路径并不相同。延迟最小的节点未必是访问目标最顺畅的节点。遇到这种情况，可以改用手动选择组，或为特定服务建立独立的策略组。
在 Linux 上只运行内核时，需要自己写配置吗？
不一定从零写，可以使用机场提供的配置或客户端导出的配置，但需要能读懂结构，因为没有图形界面替你检查字段。建议先保存副本，核对内核对协议和字段的支持，再用日志验证一个具体域名的走向。
配置文件里的敏感信息有哪些？
节点的服务器地址、端口、密码或 UUID、订阅链接以及管理接口的访问密钥都属于敏感信息，泄露等同于账号或本地代理被他人借用。分享配置截图或文本前应先删除这些字段，也不要把配置上传到公开仓库。
开启允许局域网连接有什么风险？
开启后，同一局域网内的其他设备可以连接你的本地代理端口，借用你的出口。在家庭网络中风险相对有限，在公共网络中则可能被陌生人使用。除非有明确的共享需求，否则应保持关闭，并为管理接口设置密钥。
下一步
如果你已经读懂结构，下一步通常是确认接管层是否合适，或者处理订阅拉取问题。可以继续阅读 TUN 模式与系统代理的区别，也可以直接排查订阅更新失败的原因。如果你想先回看桌面客户端的整体选择，请回到桌面客户端专题，或者在选型清单里核对客户端兼容这一项。想查看更多同类文章，可参考品牌对比入口。
Cluster · clash
Clash 系客户端
- Clash Verge Rev 安装与订阅导入完整步骤如何安装 Clash Verge Rev 并导入订阅？
- mihomo（Clash Meta）内核：与原版 Clash 的差异mihomo 内核和原版 Clash 有什么区别？
- 规则模式、全局模式与直连模式：何时用哪一种Clash 的三种出站模式分别适合什么情况？
- TUN 模式与系统代理：区别、开启方法与常见问题TUN 模式和系统代理有什么区别，什么时候需要开 TUN？
- 读懂 Clash 配置文件：proxies、proxy-groups 与 rulesClash 配置文件的主要结构是什么？
- 订阅更新失败排查：网络、格式与证书问题订阅更新失败时应该怎么排查？
- macOS 上使用 Clash 类客户端：权限与系统设置在 macOS 上使用 Clash 类客户端需要授予哪些权限？
下方卡片指向品牌库，品牌详情页中的注册链接为各品牌官方注册或推广链接；本页资料部分只整理公开资料，不构成推荐；星岛梦第一、光速云第二为本站推荐排名，非测试结果。