Clash 界面功能导览

先区分配置、代理与流量入口

理解 Clash 界面的关键，是把“配置从哪里来”“请求交给谁处理”“应用流量有没有进入客户端”分开看。配置页负责载入节点、策略组和规则；代理页负责查看策略组并选择出口；系统代理或 TUN 则决定应用流量如何进入内核。日志页提供处理过程和异常线索，不负责替代前面这些设置。

Clash 是代理内核及其相关客户端的常见称呼，mihomo 是由 Clash Meta 演进而来的内核。不同图形客户端的导航名称、按钮位置和内核能力可能不同。下文用“主窗口 → 配置”“主窗口 → 代理”等路径表示功能位置；实际界面可能把它们写成“订阅”“Profiles”“Proxies”，应按功能对应，而不是寻找完全一致的按钮文字。

配置页：导入后确认已启用

首次使用建议先进入“主窗口 → 配置”，再执行“导入”或“新建”。远程订阅通常需要填写订阅地址，本地配置则选择 YAML 文件。订阅地址可能带有个人访问凭据，应保存在可信位置，不要直接贴进截图或公开反馈内容。

导入、启用、更新是三个动作

1. 导入：把远程配置或本地文件加入列表。列表里出现一张配置卡片，只说明客户端已经保存这个配置入口。
2. 启用：选中配置并让内核加载。查看选中标记、当前配置名称，以及是否出现加载失败提示。
3. 更新：重新获取远程内容。完成后检查更新时间与加载结果，必要时重新启用，具体取决于客户端的重载机制。

例如订阅更新后增加了节点，但代理页仍显示旧列表，先检查是否更新了另一张未启用的配置卡片。若启用时出现 YAML 解析错误，应查看提示中的行号、缩进和字段类型，不要仅靠反复点击更新解决。网络请求失败与配置解析失败是两类问题，前者检查订阅地址、网络和服务响应，后者检查实际返回内容是否为有效配置。

本地修改与订阅更新的边界

直接编辑远程配置缓存，下一次更新时可能被覆盖。若客户端提供“覆写”“合并”或“扩展脚本”，应先确认其执行顺序，再把需要长期保留的本地规则放到对应机制中。不同客户端的覆写格式并不通用，不能把某个客户端的脚本直接当作 mihomo 的 YAML 字段使用。

代理页：先看模式，再看策略组

进入“主窗口 → 代理”后，不要把每个方框都理解为一台服务器。页面通常先展示策略组，再展示组内可选节点或其他策略组。规则引用某个策略组时，最终出口取决于该组的类型和当前选择，因此“点击了节点”与“当前请求走了节点”之间还隔着规则匹配。

三种模式影响选择范围

• 规则模式：按配置中的规则依次匹配，请求可能直连、代理或被拒绝。某个策略组被选中，只有匹配到它的流量才会使用该组。
• 全局模式：进入内核的请求按全局策略处理。适合短时对照排查，但不会自动让未进入内核的应用流量也使用代理。
• 直连模式：进入内核的连接按直连方式处理。部分客户端不提供独立按钮，应以实际支持范围为准。

手动选择与自动策略的差别

select 类型允许手动选择；url-test 根据周期性测试结果选择出口；fallback 按顺序选择可用项；load-balance 按配置策略分配连接。自动策略是否允许临时手动覆盖、如何恢复自动选择，取决于内核和界面实现，不能只凭卡片外观判断。

例如规则把目标交给“网页代理”组，而你调整的是“媒体代理”组，网页访问结果通常不会改变。此时应去连接页看实际命中的组，而不是继续随机切换节点。策略组也可能引用另一组，检查时需要沿代理链看到最终节点。

延迟测试：区分超时与实际下载速度

代理页的“测速”通常是对指定测试地址执行请求，展示完成探测所需的时间，单位为毫秒。它不是持续下载带宽测试，也不等同于网络层的 ICMP ping。测试地址、超时阈值、节点连接状态与当前网络都会影响结果。

假设两次测试分别显示 85 ms 和 210 ms，只能说明在对应测试条件下，前者完成探测更快；这里是读数示例，并非本站实测结果。它不能证明大文件下载速度、视频稳定性或某个特定站点的可用性。若测试显示 timeout，还要区分是节点连接失败、测试地址不可达，还是设定的等待时间过短。

1. 先对当前准备使用的一个节点测试，确认有返回结果。
2. 用实际应用访问目标站点，记录发生问题的时间。
3. 在连接页核对目标是否经过刚才的节点，再查看相同时段的日志。

对大量节点连续执行全量测试会产生额外连接。排障时只测试少量候选项更便于对照，也能避免测试请求与实际应用请求混在一起。若界面支持修改测试地址，改变地址后应重新建立比较基准，不要把两套测试条件下的数字直接排序。

连接页：核对规则与最终出口

“连接”页更适合回答“这个应用到底走了哪里”。在客户端已启用的情况下发起一次新的访问，再按域名、目标 IP 或进程名称筛选。进程信息是否可见取决于平台权限、流量接入方式和内核配置，空白不一定代表连接异常。

• 目标：观察域名或 IP、目标端口。HTTPS 常见目标端口是 443，它不是客户端本地监听端口。
• 规则：查看命中的规则类型和条件，例如域名后缀规则或末尾的 MATCH。
• 代理链：确认最终是 DIRECT，还是某个策略组及其选中的节点。
• 连接状态：结合持续时间与上传、下载计数观察请求是否仍在活动；不同客户端的列名可能不同。

切换策略后，已经建立的连接未必迁移到新出口。浏览器可能继续复用已有连接，因此需要重新建立连接再验证。客户端若提供“关闭连接”，可以只关闭相关条目，然后重新访问；关闭全部连接会中断下载、会议等任务，应先确认影响范围。

如果目标始终不出现在连接列表里，先检查应用是否遵循系统代理，以及是否使用了其他网络路径。应用自身缓存也可能使本次操作没有产生新请求。不要把列表空白直接归因于节点失效。

日志页：按级别查错误，不凭单行下结论

进入“主窗口 → 日志”，先清理界面筛选条件或记住当前时间，再复现一次问题。日志记录的是内核运行事件和连接处理信息，不一定保存每个请求的完整历史。部分客户端只在日志页面打开后接收实时记录；需要长期留存时，应检查客户端是否提供文件日志。

三个常见报错方向

• address already in use：通常是监听地址或端口被占用，应先定位对应端口与进程，不必立刻更换订阅。
• i/o timeout：表示某个网络操作超时，需结合目标地址、连接阶段和上下文判断，不等于订阅过期。
• connection refused：常见于目标端口未监听或连接被明确拒绝，应检查报错指向的是本地接口、上游节点还是目标服务。

配置里的 log-level 控制输出级别，日志页的下拉菜单也可能只是过滤已接收的信息。若内核只输出错误，把界面筛选切到“全部”并不能恢复未产生的普通日志。需要更多细节时，应确认修改的是内核日志设置，并在重新加载后再次复现。

设置页：端口、系统代理与 TUN 分开检查

设置页中的本地端口是应用连接客户端的入口，控制端口则供界面或管理工具调用内核接口。两者用途不同。例如 mixed-port: 7890 表示在同一端口接受 HTTP 与 SOCKS 代理请求；127.0.0.1:9090 常被用作本地控制接口地址示例，但不是所有客户端的固定默认值。

以下片段仅说明字段含义，不是可直接替换订阅的完整配置。图形客户端可能用设置页覆写这些字段，应先看实际生效值：

mixed-port: 7890
allow-lan: false
log-level: info

系统代理与 TUN 不是同一开关

系统代理通常修改操作系统的代理设置，只有遵循该设置的应用才会使用对应入口。TUN 通过虚拟网络接口和路由接入流量，往往需要更高权限，并涉及 DNS 与路由设置。开启 TUN 后仍需检查服务权限、虚拟接口是否创建成功以及规则是否符合预期，不能把它当作解决一切连接故障的开关。

在提供参数设置入口的客户端里，可按“设置 → 参数设置”查找端口；如果界面没有这个分组，就查找“端口”或“内核设置”。改动 7890 后，还要同步手动配置的浏览器代理、终端环境变量和其他应用设置。客户端自动管理的系统代理是否同步更新，也应在操作系统里核对一次。

一次完整检查：从配置到日志

遇到“节点能测延迟，但网页打不开”时，按下面顺序检查，可以把问题范围缩小到明确的环节，而不是同时改动多个设置。

1. 配置页：确认当前启用的是目标配置，加载没有报错；订阅更新时间只能作为线索，不能替代加载结果。
2. 代理页：确认使用规则模式，查看目标策略组与节点；需要对照时再短时切换全局模式，并记录原设置。
3. 设置页：确认应用通过系统代理或 TUN 接入，核对实际监听端口，避免应用仍指向旧的 7890。
4. 连接页：重新访问目标，查看是否出现新连接，记录命中规则与最终出口。
5. 日志页：按同一时间点查看异常，区分 DNS、连接上游、TLS 或本地监听阶段的问题。
6. 恢复设置：排查结束后恢复临时改动的模式与日志级别，保留必要的脱敏记录。

日常使用时，可把界面操作固定为“配置页确认来源 → 代理页确认策略 → 连接页验证结果 → 日志页分析异常”。更多字段含义可查阅配置大全；首次导入和接入应用的步骤可按快速上手逐项完成。