工单 01 / 配置入口
导入订阅，启用配置
先准备由可信服务提供方给出的订阅地址，确认它是面向 Clash 或 mihomo 的配置订阅，而不是用户中心网址、付款页面或单个节点的分享文本。订阅地址常带有用于识别账户的参数，应像账号信息一样保管，不要粘贴到公开评论、截图或在线转换网站。客户端只是读取配置并建立连接，安装客户端本身不会生成可用的远程服务器。
打开客户端后，先进入“配置”“订阅”或“Profiles”页面，寻找“新建”“添加订阅”或“从 URL 导入”。在地址栏粘贴完整链接，名称可以写成便于辨认的短标签，例如“日常配置”。粘贴后检查开头和结尾有没有多出来的空格、换行或聊天软件附带的标点；不要为了让地址看起来简短而删除问号后面的参数。确认后点击“导入”“下载”或“保存”，等待客户端完成首次拉取。
下载成功后，还要选中这份配置
配置列表出现新卡片，并不一定表示它已经投入使用。点击该卡片的“使用”“激活”或选择按钮，确认出现当前配置标记；若客户端提示重载内核，按提示完成重载。接着进入代理页面，应该能看到订阅定义的代理组；在规则页面，也应能看到规则列表或相应的加载状态。部分配置会继续下载规则集和数据文件，首次加载需要等待，过程中先不要反复点更新。
如果提供方给的是本地 YAML 文件，使用“从文件导入”选择该文件，不要把文件内容整段塞进订阅地址栏。本地文件通常不会自动跟随远程订阅更新；远程订阅则可以在配置页手动更新。初次操作建议先手动更新一次，确认配置能正常读取，再设置自动更新间隔。更新订阅可能覆盖直接改在订阅文件里的内容，个性化修改应使用客户端提供的覆写或合并入口，首次上手暂时不需要处理这些设置。
导入失败，先辨认失败发生在哪一层
提示下载超时，说明还没有顺利取得配置，先检查基础网络、链接有效期以及服务提供方是否要求特定获取方式；提示 YAML 解析错误、缺少字段或未知协议，则说明已经取得内容，但格式或内核兼容性可能不对。浏览器能打开某个地址，也不能证明返回的就是配置，返回内容可能是登录页面或错误说明。Base64 节点列表与 Clash YAML 不是同一种配置格式，不能假定任何订阅都能直接使用。
遇到格式问题，优先向提供方索取适配当前客户端的订阅，不要先把完整地址发给陌生转换服务。有关格式差异，可继续阅读订阅链接导入与格式说明。这一步的完成条件很明确：当前配置已选中，代理组能够显示，没有持续出现的解析错误。达到这些条件，再继续选择运行模式。
工单 02 / 出口选择
选择规则模式与代理组
配置加载完成后，回到客户端首页、仪表盘或代理设置，找到运行模式选项。首次使用通常选择“规则”或“Rule”。规则模式会根据当前配置中的域名、地址等条件决定连接出口：有的请求直连，有的交给代理组，有的会被拒绝。因此，开启客户端不等于所有网站都经由同一个远程节点，这正是规则分流的作用。
同一位置常见的另外两个选项是“全局”与“直连”。全局模式把进入内核的请求交给全局出口选择，适合临时对照排查，不适合不看配置就一直保持；直连模式通常让进入内核的请求直接连接目标。运行模式决定内核怎样处理已经收到的请求，并不负责把所有应用的流量自动送进内核。不要把“已选规则模式”和“系统代理已开启”当成同一件事。
模式选对后，检查规则实际使用的组
进入“代理”或“Proxies”页面，找到当前配置用于日常访问的选择组。不同订阅可能把它命名为“节点选择”“代理”或其他名称，本页不预设固定组名。点击展开后，在手动选择组里选一个可用节点；如果组内列出自动选择组，也可以选中那个组，让其按配置设定执行健康检查。界面上的勾选、边框或当前值应随选择发生变化，退出该页面再回来，确认选择仍然保留。
订阅里可能还有面向不同服务的专用组，这些组可以独立选择，也可以继续指向主选择组。只修改一个名字显眼的组，不代表所有规则都使用了它；后续验证时需要看实际请求命中的出口链路。首次操作不要同时调整每个组，先保留订阅默认关系，只确认主要出口没有误选为直连或拒绝，再用一次实际请求确定路径。
若客户端提供“连接测试”“健康检查”或“测速”按钮，可以执行一次，用于检查相应测试目标的可达性。测试出现结果，只说明该节点到测试目标的路径在当时可用，不代表所有网站都能访问，也不代表实际下载速度。反过来，单次测试超时也可能与测试地址有关。先尝试一个符合预期的节点，不必连续反复测试整份列表。
保留默认规则，减少首次配置变量
此时不建议把网上找到的大段规则直接覆盖到订阅中。规则引用的组名必须与配置一致，匹配顺序也会改变出口；即使 YAML 格式正确，名称不一致仍可能造成加载失败或走错路径。想理解“代理组”“规则模式”和“节点”的区别，可先查概念速查；协议支持、内核家族与配置兼容性放在技术参考中展开，本页先保留可以跟着执行的主线。
离开这一步前，确认模式显示为规则，主出口组已有选择，并且内核没有因为切换配置而报错。记住当前所选组和节点名称，下一步接入系统流量后，就可以拿它们与连接列表里的实际出口进行对照。
工单 03 / 接通流量
启动内核，开启连接
配置与出口确定后，先看客户端首页的内核状态。桌面客户端有的打开即启动内核，有的需要点击“启动”或“连接”；确认状态进入运行中，再开启“系统代理”。系统代理会通知遵循系统代理设置的应用，把请求交给本机监听端口。它不等于接管设备上的全部网络流量，某些游戏、命令行程序或带独立网络设置的应用可能不会使用这个入口。
如果客户端同时提供“系统代理”和“TUN”，首次验证建议先使用系统代理这条较容易检查的路径。不要一上来同时开启两者，再同时调整 DNS 和路由。TUN 通过虚拟网络接口接入流量，通常还需要服务组件或更高权限；等浏览器请求已经能够正确分流，再按具体应用需要评估是否启用。不同平台的 TUN 支持情况与配置要求并不完全相同。
桌面端：先运行，再打开系统代理
在 Windows、macOS 或 Linux 的桌面客户端中，进入“设置”“网络”或托盘菜单，打开系统代理开关，然后返回首页确认开关保持开启。部分 Linux 桌面环境还需要应用自身遵循桌面代理设置，因此开关成功并不能代替实际验证。首次操作可以关闭其他代理工具，避免两个程序争夺系统设置；浏览器若装有独立代理扩展，也应暂时恢复使用系统设置，否则测试的可能是扩展的出口。
看到权限提示时，先辨认它对应的是哪项操作。系统代理开关、安装服务组件和启用虚拟接口并不是同一种权限需求。只有在主动执行对应设置、确认提示来自正在使用的客户端时再继续；不要因为普通网页没有打开，就把所有程序都改成管理员运行。若界面明确提示服务尚未安装，按该客户端说明安装所需组件，再回到原来的步骤。
如果日志出现监听地址被占用，先停止其他可能使用同一端口的代理程序，再重试启动。常见的 mixed-port 是 HTTP 与 SOCKS 共用的监听端口，但实际端口以当前配置和客户端设置为准。需要换端口时，应保证客户端显示的监听端口与应用中手动填写的代理端口一致；不要把教程里的端口数字当成设备上必须使用的固定值。
手机端：确认系统 VPN 授权与连接状态
在 Android 或 iOS 客户端里，回到首页点击“连接”或启动按钮。第一次通常会出现系统 VPN 配置或连接请求，核对应用名称后允许。完成后应能看到客户端的连接状态变化，以及系统对应的 VPN 状态提示。这里的 VPN 表示流量接入系统网络接口，并不意味着当前所有请求必然走远程代理；规则仍会决定哪些连接直连、哪些使用所选出口。
若系统提示已有其他 VPN 连接，先断开原来的连接，再测试当前客户端。连接成功后暂时保持客户端在前台，完成下一步验证，再检查切到后台是否稳定。Android 的省电限制可能影响后台运行，但不要在尚未验证基本连接时就到处修改电池设置。有关后台断开、权限反复弹出和端口冲突的具体处理，可查常见问题，先按眼前提示定位，不做无关改动。
工单 04 / 实际请求
核对规则与出口，验证是否生效
连接按钮变成开启状态，只证明某个组件已经启动；真正的验证要看请求有没有进入内核，以及最终选择了什么出口。先打开浏览器，新建标签页，访问一个已经知道能够正常打开的网站，确认基础网络仍然可用。随后访问一个按当前配置应由代理组处理的目标。不要只盯着旧标签页反复看，旧页面可能来自缓存，已有长连接也不一定会立即采用刚修改的出口。
回到客户端的“连接”“Connections”或请求日志页面，查找刚才访问的目标域名。不同客户端显示的字段不同，重点看目标、命中规则和出站链路：目标应与本次请求对应，命中规则解释为什么选择该路径，出站链路则应包含预期的代理组或节点。规则选择直连时显示 DIRECT 是正常结果，不能因为某条请求没有走节点就判断客户端失效。
分开验证直连路径与代理路径
选择两个预期出口不同的目标，分别发起新请求，再对照连接列表。若两次都符合配置，说明系统接入与规则分流的基本链路已经接通。出口地址查询网站可以作为补充观察，但它只能反映访问该查询网站时使用的出口，不能证明其他应用和所有域名都走同一路径。判断规则是否生效，应以该次连接的匹配结果为主，而不是只看一个地址有没有变化。
如果连接列表里完全找不到浏览器请求，先检查系统代理是否真正开启，以及浏览器是否被独立扩展或手动代理设置接管。先不要更换节点，因为请求还没有进入当前内核，换出口解决不了入口问题。若只有某个应用没有记录，则查看该应用是否支持系统代理；确实需要接入更多流量时，再考虑 TUN，而不是把规则模式误改成全局来尝试接管应用。
如果请求已经出现在列表，但出口不符合预期，返回第二步检查当前模式、命中规则和代理组选择。若出口符合预期却连接失败，再检查该节点的可用性、服务状态以及日志中的具体错误。解析错误通常指向域名解析链路，连接超时则需要结合目标与节点判断，不能只凭“超时”两个字认定是 DNS 问题。每次只改一个变量，重新发起请求后再看结果，这样才知道哪项调整真正有效。
完成一次重连，再结束首次配置
基本访问正常后，执行一次断开与重新连接，再发起新的网页请求，确认配置和代理组选择仍然保留。桌面端也可以正常退出客户端后检查系统代理是否恢复；如果退出后网页异常，先关闭遗留的系统代理设置，再重新启动客户端处理。不要直接删除配置，否则原本正常的出口选择和订阅信息也会丢失，反而增加恢复工作。
最后回到配置页手动更新一次订阅，确认更新后仍使用预期配置，主要代理组仍有有效选择。开机启动、后台运行和自动更新可以在基本链路验证完成后再设置，不必在首次导入时一起完成。至此，四张工单的结果应当一致：配置能加载、模式选规则、系统流量已接入、实际请求的规则与出口符合预期。
后续只是偶发打不开，先按故障排查分类找对应现象；需要理解协议差异、移动端资源取舍或 mihomo 配置兼容性，再看协议与内核技术参考。把可用的基础配置保留下来，再逐项增加功能，比一次改完整张设置页更容易维护。