Clash 客户端界面导览:代理页、配置页与日志页各自负责什么

先区分配置、出站与流量入口

Clash 客户端的侧栏通常包含代理、配置、连接、日志和设置。它们不是同一项功能的不同入口：配置页决定加载哪些节点、代理组与规则；代理页决定代理组当前使用哪个出站；连接页显示正在处理的请求；日志页记录内核运行事件。系统代理和 TUN 模式则负责让流量进入内核。

不同客户端可能把 Proxies 译成「代理」或「代理组」，把 Profiles 译成「配置」或「订阅」。下面使用「代理 → 选择代理组」这类路径描述操作层级，不保证每款客户端的菜单文字相同。先按英文名称和功能识别页面，再对照实际按钮操作。

配置页：导入订阅与激活配置

导入成功不一定已经生效

订阅地址通常用于获取远程配置，也可能只提供节点列表。客户端能否直接导入，取决于返回内容的格式和客户端的导入能力。网页地址、订阅地址与节点分享链接不是同一种内容；把服务商登录页粘贴到订阅输入框，可能得到 HTML，而不是内核需要的 YAML。

1. 进入「配置 / Profiles」→「导入」或订阅地址输入框，粘贴服务商提供的适配订阅地址。
2. 等待下载与解析完成，检查是否出现配置卡片，以及是否报告语法错误。
3. 选择该配置，确认选中标记或当前配置名称已经改变。
4. 进入代理页，检查预期的代理组和节点是否出现。若仍显示旧内容，回到配置页确认激活状态。

同一客户端可以保存多份配置，但通常只有一份主配置处于激活状态。某些客户端还支持合并、覆写或脚本处理，因此磁盘上的订阅原文不一定等于内核最终加载的配置。排查字段时，优先查看客户端提供的运行配置或配置预览。

更新订阅与更新规则集不是同一个动作

配置卡片上的「更新」一般重新获取远程配置。使用 proxy-providers 的配置还可能单独更新节点提供者；使用 rule-providers 的配置则可能有独立的规则集下载周期。更新主订阅，并不意味着所有提供者资源都会在同一时刻刷新。

• 节点名称或数量不符合预期：检查订阅更新时间，以及对应节点提供者的更新结果。
• 规则行为没有变化：检查当前激活配置、规则顺序与规则集加载状态。
• 手动修改后又恢复原样：远程更新可能覆盖原文件，需要使用客户端支持的持久覆写方式。

订阅 URL 常包含身份令牌。分享配置截图时遮住完整 URL、二维码和认证信息；需要协助时，保留错误文本、内核名称和相关字段即可，不要公开整个订阅地址。

代理页：选择模式与代理组成员

规则、全局与直连决定选择路径

规则模式按配置中的规则顺序匹配请求，再交给指定出站或代理组。全局模式通常把请求交给全局选择组，但最终是否经代理，仍取决于该组选择的成员。直连模式让内核处理的流量直接连接目标。三种模式都不等于自动接管所有应用，流量是否进入内核仍由系统代理、TUN 或应用自身设置决定。

日常先使用规则模式。临时切到全局模式可以帮助比较分流结果，但测试结束后应切回原模式，否则原本需要直连的请求也可能改变路径。切换模式后，用新请求验证，不要只观察已经建立的长连接。

手动组与自动组的操作不同

select 组允许手动选择成员；url-test 组按配置的探测结果自动选择；fallback 组按可用性与成员顺序回退；load-balance 组根据配置策略分配连接。自动组即使被外层手动组选中，内部也不一定出现可长期固定节点的操作。

代理组可以引用另一个代理组。例如「网页访问」选择「自动选择」，而「自动选择」再指向某个节点。判断实际出站时，需要沿着这条链看到底，不能只读最外层组名。配置里的 DIRECT 表示直连，REJECT 表示拒绝，它们不是代理服务器。

延迟测试只用于初步筛选

点击「测速」通常触发到指定 URL 的连通性或延迟测试，不是完整的带宽测试。假设某次面板显示 80 ms，另一个节点显示 120 ms，这只能说明当次探测条件下前者耗时更短，不能据此推算视频速度或每秒下载多少 MB。这两个数值仅用于解释读法，不是本站实测结果。

遇到超时，先确认测试地址、网络环境与节点状态。不要连续高频点击所有节点测速；并发探测可能增加负载，也会干扰对日常体验的判断。

设置页：检查系统代理、TUN 与混合端口

「设置 / Settings」或首页总览通常提供系统代理、TUN 模式和端口入口。系统代理适合遵循操作系统代理设置的应用；TUN 通过虚拟网卡和路由接管符合条件的流量，需要相应权限，也可能与其他 VPN 的路由产生冲突。初次配置先验证一种入口，避免同时改动多个开关。

混合端口用于在同一个监听端口接受 HTTP 代理与 SOCKS 代理连接。例如下面片段把本地混合端口设为 7890。它是讲解用配置，不代表所有客户端都默认使用该端口，也不是一份含节点与规则的完整配置。

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

如果当前客户端实际监听 7890，可在终端用以下命令显式指定 HTTP 代理，单独检查本地代理链路。先确认端口，再运行命令；不要直接把示例端口当作实际值。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

• 返回 HTTP 响应头：说明这次请求通过指定代理端口得到了响应，不代表其他应用也遵循系统代理。
• 提示无法连接 127.0.0.1:7890：先检查内核运行状态、实际端口和监听设置。
• 连接本地端口后仍超时：继续检查目标访问、规则、DNS 与上游节点，不要只反复切换系统代理。

连接页：确认请求命中了哪条规则

连接页适合回答三个问题：请求有没有进入内核、匹配了什么规则、最终走向哪个出站。常见字段包括目标域名或 IP、目标端口、网络类型、规则、代理链、上传和下载量。进程名称是否显示，取决于系统权限、内核能力和客户端实现，空白不一定代表异常。

1. 进入「连接 / Connections」，先按目标域名筛选，减少后台请求干扰。
2. 在浏览器打开目标页面，观察是否出现新的连接。HTTPS 请求常使用目标端口 443，但不能只靠端口判断应用类型。
3. 展开连接详情，记录命中的规则、规则载荷以及代理链。
4. 若结果是 DIRECT，先检查是否匹配了直连规则，而不是立即判断代理失效。

切换节点后，旧连接可能继续使用原出站。HTTP 长连接、WebSocket 与流媒体会话都可能持续一段时间。需要重新验证时，可关闭目标应用的连接或在连接页关闭对应条目，再发起请求；「关闭全部连接」会中断其他下载和会话，使用前先确认影响范围。

连接列表为空也不能直接归咎于节点。应用可能没有发起新请求、使用缓存、绕过了系统代理，或者请求已快速结束而未保留在当前视图。用一个明确的新请求配合日志观察，比反复刷新列表更有效。

日志页：按时间定位加载与拨号错误

日志页记录的是事件，不是完整抓包。不同内核和客户端的日志文字会变化，但排查顺序相同：先看配置是否加载成功，再看 DNS、规则资源和上游连接。日志级别通常包括 silent、error、warning、info、debug，具体可选项以当前内核为准。

一次只复现一个问题

1. 进入「日志 / Logs」，清空显示或记下当前时间。
2. 如果客户端支持调整日志级别，先使用 info；信息不足时短暂改为 debug。
3. 只访问一次目标网站，复制该时间段内相关错误及相邻上下文。
4. 排查结束后恢复日常日志级别，避免长期保留过多请求信息。

使用 mihomo，也就是原 Clash Meta 内核时，要留意配置是否依赖扩展字段。客户端外观相似，不代表内核能力完全相同。提交问题前记录「客户端版本 + 内核名称 + 内核版本」，这些通常可在「关于 / About」或内核信息区域查看；不要仅写“最新版”。

首次上手与故障排查的操作清单

把页面职责串起来，可以减少没有依据的开关尝试。以下顺序适合“已经导入订阅，但网页仍然打不开”的常见场景：

1. 配置页：确认目标配置已激活，加载没有报错，代理页能看到对应代理组。
2. 代理页：使用规则模式，检查目标业务对应的代理组，确认没有误选 DIRECT 或不可用成员。
3. 设置页：核对系统代理或 TUN 的入口状态；终端测试时显式指定实际混合端口。
4. 连接页：发起新请求，查看规则与代理链。无记录先查入口，有记录再查出站。
5. 日志页：对齐复现时间，区分配置解析、DNS 和拨号错误，一次只修改一个相关设置。

代理页负责选择，配置页负责来源，连接页负责观察实际路径，日志页负责解释运行事件。先确认请求停在哪一层，再去对应页面处理。这样即使更换客户端，仍可以沿用同一套检查方法。