akashaProxy 配置文件关系总览：四份文件各管一段

理解 akashaProxy 配置文件关系的第一步，是承认这里存在两个层级。clash.config 属于模块启动层面，它决定模块以什么方式运行；config.yaml 与 config.example.yaml 属于 mihomo 内核配置层面，它们决定代理本身如何处理流量。packages.list 又站在另一个角度，它以名单方式筛选哪些内容进入代理。如果脑子里没有这条分层线，看到“改了配置但没变化”就会无从下手。

整个关系可以压缩成一张总览。clash.config 管模块启动配置，包括开机自启、代理模式和插件，改错后模块可能不按预期启动，但代理规则本身没变。config.yaml 是实际生效的 mihomo 配置文件，改错后代理行为直接改变。config.example.yaml 是默认配置模板，通常不用于直接生效，改它不会立即改变当前运行状态。packages.list 管代理黑名单或白名单，改错后某些应用被错误地纳入或排除代理，名单方向一旦弄反，现象会非常典型。

clash.config 的职责比较集中：开机自启决定模块是否随系统启动，代理模式决定流量进入代理的入口方式，插件则影响模块加载时的附加能力。这三项都属于“模块怎么跑”的问题，而不是“某条流量怎么走”的问题。换句话说，这份文件安放在模块启动配置的位置上，它不直接编写具体规则，也不决定哪一个域名走哪条出口。

所以，当有人改完 clash.config 却发现上网行为没有变化时，最可能的原因是改错了对象。clash.config 管启动，不管规则。真正控制代理走向的是 config.yaml 以及其引用的分流规则。想要修改代理行为，却先在 clash.config 里翻找字段，这属于层级的误判。确认模块是否按预期启动，是排查的第一步；确认规则是否按预期编写，则是另一个方向。

config.yaml 是 mihomo 配置文件，当前运行所依赖的正是它。config.example.yaml 则是默认配置模板，akashaProxy config.example.yaml 的主要意义在于提供一个可以参考、可以对照的默认形态。模板存在的价值，是让人在配置被改乱之后还能回到一个相对完整的起点，而不是手忙脚乱地东拼西凑。

官方给出的用法很直接：把 config.example.yaml 重命名为 config.yaml，即可作为初始配置使用。如果一份手改的 config.yaml 已经被反复打补丁，字段之间开始互相冲突，回到模板重新开始反而是更干脆的选择。akashaProxy config.example.yaml 提供默认配置的基础形状，把它重命名或复制为 config.yaml 后，再按需调整端口、DNS 或 TUN 相关字段，通常比继续在原有文件上追加更清晰。需要区分的是：不要直接依赖模板生效，实际被读取的是 config.yaml；把模板当成修改蓝本，而不是运行时入口。

packages.list 用于代理黑名单或白名单。

使用 akashaProxy 自备配置时，有若干字段不能随意删除。

大类分流使用内置 GeoSite.dat 和 GeoIP.dat。内置库适合处理粗粒度判断，比如按地区、按站点大类先分一遍。细分类则使用 .mrs 规则集，它面向更具体的匹配需求，可以承载更细的规则条目。两者是粒度差异，是分工关系。内置库解决“先分大类”的需求，.mrs 规则集解决“大类之内再细分”的需求。

配置时按实际需要选择：需要按大类快速分流，就调用内置 GeoSite.dat 或 GeoIP.dat；需要在某个大类内部继续细分，就引入对应的 .mrs 规则集。akashaProxy 配置文件关系在这里再次体现：数据文件本身不是配置，但它们被 config.yaml 引用后才真正进入规则体系。改 config.yaml 时，务必确认引用的 GeoSite.dat、GeoIP.dat 或 .mrs 规则集路径与实际文件位置对得上。

国内社交类应用按 Android 应用包名分流时，PROCESS-NAME 是入口。通过 PROCESS-NAME 匹配包名，可以把某个应用的流量交给规则处理。包名分流写在规则层，而 packages.list 名单写在名单层，两者不要混为一谈。

网上行为异常，不代表一定是规则写错。很多人会第一时间去翻节点或换端口，却忽略配置文件本身的对应关系。更合理的自查顺序是：先确认模块是否按 clash.config 启动，再确认 config.yaml 是否为实际生效的配置，然后检查 packages.list 名单方向是否正确，最后再看分流数据粒度是否匹配。

如果模块没有随系统启动，后面的一切都无从谈起，这时去看 clash.config。如果代理行为偏离预期，先确认当前运行的到底是不是你以为的那份 config.yaml，而不是只盯着某个字段。如果某个应用无论如何设置都走不了代理，或者不该走代理的却走了，先看 packages.list，确认它是黑名单还是白名单。如果大类分流出现异常，检查是否把细分类需求交给了内置 GeoSite.dat 或 GeoIP.dat，或者把大类需求交给了 .mrs 规则集。这个顺序本身也可以减少排查时的盲目翻找。

自备配置并非一定要从零手写。跑通之后再逐步叠加修改，每一轮只动一个层级，问题定位会容易得多。

改动前保留可回退的原始文件，是操作习惯层面的建议。任何配置修改都有让代理暂时失效的可能，尤其在 Root 环境里，系统级行为更容易被改变。保留一份改动前的 config.yaml、clash.config 以及 packages.list，比在出问题后凭记忆恢复更可靠。

akashaProxy config.example.yaml 能直接改吗？ 官方给出的用法是将其重命名为 config.yaml 后使用。建议先保留一份原始模板，再在重命名后的 config.yaml 上修改，这样既能让配置生效，又不会弄丢默认值。

packages.list 清空后会全部走代理还是全部不走？ 官方只说明 packages.list 用于代理黑名单或白名单。建议在清空名单前先确认当前配置的名单方向，并保留清空前的原始文件以便恢复。

.mrs 规则集和内置 GeoSite.dat 同时命中时以谁为准？ 官方只区分大类使用内置库、细分类使用 .mrs，未给出重叠时的优先级。建议在配置时避免让同一流量同时落入两类互相冲突的规则，减少不确定行为。

如果只是想弄懂 akashaProxy 配置文件关系，把总览过一遍即可。如果是修改后出现异常，按自查顺序从 clash.config 开始确认运行状态。如果涉及具体某类应用分流，看清它适合 packages.list 还是 PROCESS-NAME。每一步都可以回来看，不用一次记住全部。