第一步：导入订阅并启用配置
开始前准备一条支持 Clash 或 mihomo 的订阅地址，或一份已有的 YAML 配置文件。客户端本身不附带可用代理节点；订阅中的节点、有效期和使用限制由提供方决定。服务页面上的账号入口、网页地址与订阅地址不是同一回事，应复制明确标注为 Clash 或 mihomo 格式的链接，而不是浏览器地址栏中的登录页面。
打开客户端，进入“配置”或“订阅”页面，寻找“新建”“添加”或“导入”入口。选择远程链接类型，把完整订阅地址粘贴到地址栏，再填写一个容易区分的名称，例如“日常配置”。粘贴后检查开头与结尾是否完整，尤其不要带上聊天消息中的换行、引号或句末标点。订阅地址经常包含访问凭据，不应发到公开评论区，也不要把完整地址放进求助截图。
点击“下载”“导入”或“保存”后，等待客户端完成获取。正常情况下，列表会出现新配置，并可看到更新时间或导入结果。此时还需要点击这份配置，将其设为当前使用项；部分客户端导入后不会自动切换。随后进入“代理”页面，确认能看到策略组及其中的出站选项。只有一张配置卡片而没有任何可选择项时，应先检查配置是否已启用，而不是立即开启 TUN。
如果手头是本地文件，选择“从文件导入”，定位到 YAML 文件后确认添加。文件扩展名可以是 .yaml 或 .yml，关键是内容必须符合当前内核支持的配置格式。不要把订阅下载失败后返回的网页另存为 YAML 使用。导入时若出现解析错误，先读错误提示中的行号，并核对来源格式；完整字段含义留到配置大全查阅，不必在首次上手时逐项手工重写。
订阅无法获取时先确认来源
遇到下载超时，可先确认设备本身能够联网，再回到提供方页面检查链接是否更新、订阅是否有效。出现权限拒绝或内容为空时，优先处理账号与地址问题；出现 YAML 解析错误时，优先确认是否复制了正确格式。反复点击导入不会修复无效地址。部分订阅获取需要已有网络通路，应按提供方说明处理，不要随意把私人订阅粘贴到陌生转换网站。
导入成功后，找到这份配置的“更新”入口，了解手动刷新位置即可。远程订阅更新可能替换节点或策略组，直接修改订阅正文的内容也可能被覆盖。首次配置先保持原有规则，后续需要长期自定义时，再阅读配置大全中的覆写与合并说明。确认当前配置已启用、策略组已出现后，就可以继续选择模式。
第二步：选择代理模式与出站
回到客户端主页或“代理”页面，找到“规则 / 全局 / 直连”模式选择器。首次使用建议选择“规则”。这三项决定内核收到请求后怎样选择出站，并不负责让所有程序自动进入客户端。因此，选中规则模式之后还需要完成下一步的系统代理或 VPN 接管；只切换模式而没有启用接管，浏览器可能仍沿用原来的网络路径。
规则模式会按配置中的规则顺序匹配请求，第一条命中的规则决定目标策略。配置可能让某些域名直连，让另一些域名走代理，也可能交给广告拦截或其他专用策略。这里的实际行为取决于当前配置，不是所有订阅都采用同一套分流方案。看到某个网站使用直连，不一定是连接失败，应结合它命中的规则判断是否符合预期。
全局模式把进入内核的请求统一交给全局策略，适合临时对照测试，但不代表能够接管整台设备的全部流量。直连模式则让进入内核的请求直接连接目标，不使用代理节点出站。需要区分的是，“规则 / 全局 / 直连”属于出站决策，而“系统代理 / TUN / VPN”属于流量接管方式，两组设置解决的是不同问题。
选好规则模式后，打开策略组列表，找到当前配置用作主要代理出口的组。它可能叫 PROXY、节点选择或其他名称，应以配置与连接记录为准。点击组内一个可用节点，确认选中标记已经变化；如果选择的是“自动选择”子组，再进入该子组查看它是否包含可用候选。不要只在一个未被规则引用的组里切换，否则实际请求可能仍走原来的出口。
节点测试结果只用于初步筛选
可以使用客户端自带的连接测试检查候选节点，但测试结果只反映到指定测试地址的当时连通情况。一个节点能完成测试，不代表每个网站、协议或应用都能正常访问；反过来，某个测试地址不可达，也不必然意味着所有请求都失败。先选一个可用候选完成后续验证，再根据实际访问表现调整，不需要在首次设置时遍历全部选项。
现在应当有两个明确状态：当前使用的配置已经选中，规则实际引用的策略组也已经选好出站。如果页面显示空组、找不到节点或配置错误，先回到第一步，不要用全局模式掩盖配置问题。模式与策略组的更多差异可在帮助中心继续查阅。接下来才是让应用请求进入客户端。
第三步：启用系统代理或 VPN 连接
先检查客户端首页的内核运行状态。多数图形客户端会随应用启动内核，但也有单独的“启动”或“连接”按钮。若提示启动失败，打开日志查看是否存在端口占用、配置解析失败或权限不足。此时应处理明确的启动错误，而不是反复切换节点。内核正常运行后，再根据设备类型启用接管入口。
桌面端首次验证建议先打开“系统代理”。这个开关会把系统代理设置指向客户端的本地监听地址，遵循该设置的浏览器和应用便能把请求交给内核。开启后保持客户端运行，重新打开一个浏览器窗口再访问网页。部分应用有独立代理设置，或者完全不读取系统代理，因此浏览器能访问而其他程序不能访问，并不说明订阅一定有问题。
移动端通常在主页点击“连接”或启动按钮。系统首次弹出 VPN 配置或连接授权时，核对请求来自刚安装的客户端，再批准授权。随后返回应用查看连接状态；状态栏中的 VPN 标识只能说明系统通道已经建立，仍需第四步确认实际出站。不要在另一款 VPN 应用保持连接时同时启动，系统可能切换通道，导致刚开启的客户端随即断开。
只有需要时再开启 TUN
如果目标程序不遵循系统代理，可以进一步考虑 TUN。TUN 通过虚拟网络接口接管符合路由设置的流量，通常还涉及服务安装、管理员权限或系统网络扩展授权。请使用客户端自带入口，按系统提示完成安装与授权。启用失败时先看具体错误，不要随意关闭系统安全机制，也不要从不明来源安装所谓修复驱动。
初次排查尽量保持接管方式单一：先验证系统代理，再决定是否切换或叠加 TUN，具体组合以客户端说明为准。同时运行多个代理工具，可能相互覆盖系统设置、修改路由或占用同一监听端口。先关闭其他工具及不必要的浏览器代理扩展，减少变量。关于虚拟网卡、DNS 接管与 stack 的详细取值，直接阅读TUN 配置参考，本页不展开高级参数。
到这里，客户端应该保持运行，选定配置与模式也没有被切换，系统代理或 VPN 入口已启用。暂时不要设置开机启动、后台保活或复杂覆写，先验证一条完整请求。之后需要退出客户端时，优先使用其“断开”或“退出”入口，让它恢复自身修改的网络设置；异常结束后若出现网络异常，应检查系统是否还保留着指向已停止客户端的代理地址。
第四步：验证访问与规则命中
打开一个新的浏览器窗口，访问你已知可用且有权限访问的网页，同时打开客户端“连接”或“日志”页面。观察刚刚发起的请求是否出现在记录中，再查看目标域名、匹配规则与出站链路。不同客户端展示字段略有差异，但核心问题相同：请求有没有进入内核，以及进入后交给了哪条策略。
单看网页能打开还不足以确定代理生效，因为该网页可能本来就能直连，或者由浏览器缓存显示。应在当前配置中分别选择一个预期直连、一个预期代理的目标，重新发起访问，并核对记录里的结果。若请求命中 DIRECT，先确认这是否是规则的预期；若命中代理策略，再查看最终选择的节点，而不是只看主页上的模式名称。
需要辅助判断时，可以使用自己信任的出口地址查询服务，对照切换前后的结果，但不要把它作为唯一依据。规则模式可能让查询服务直连，浏览器缓存、应用独立代理和已有连接也会影响观察。连接记录与实际访问结果相互印证，比只看一个出口地址更可靠。切换节点后尽量重新建立请求；已经建立的长连接不一定立即改用新的出站。
验证失败按层次缩小范围
如果记录里完全没有目标请求，优先检查接管入口：系统代理是否仍开启，移动端 VPN 是否保持连接，浏览器是否有自己的代理规则。若记录出现但最终使用了非预期策略，回到第二步查看命中规则和对应策略组。若策略正确却连接超时，换一个候选节点重试，并确认订阅状态；不要一开始就同时修改模式、DNS 和 TUN，以免失去可对照的结果。
日志出现解析失败时，再进入 DNS 层排查。先确认设备基础网络正常，保留客户端默认设置，并记录出错域名与错误时间。Fake-IP 下看到保留地址映射不一定是异常，不应仅因为地址陌生就关闭该模式。DNS 字段的含义与适用边界见DNS 配置参考；端口占用、授权失败、个别应用不联网等现象，可在帮助中心按问题继续定位。
当网页访问正常、记录中的规则和出站符合预期后，首次配置就完成了。记下当前使用的配置名称、接管方式和主策略组选择，后续修改时一次只调整一项。更新订阅后再做一次同样验证，尤其留意节点名称或策略组是否变化。求助时提供客户端名称、系统版本、错误文字与已尝试步骤即可；截图前遮住订阅地址、账号信息和私人访问记录。