先搭出可回退的策略组结构
订阅拉下来只有一堆散装节点，没有地区分组，也没按用途分流。手动整理又怕一改就弄坏整个 YAML。比较稳的做法是先理清 Stash 链式代理的结构，再决定策略组、覆写和规则路由谁先动。Stash for Android 是 Stash 的 Android 抢先体验版本，可读取与 macOS、iOS 版相同的 YAML 配置，桌面端整理好的思路能延续到手机端，检查顺序则要按移动端习惯重排。
安装来源与配置入口
先确认手上的应用是不是正版。同名应用和仿冒页面不少，确认开发者、包名与签名，与官方页面比对后再安装。Android 版本获取 Android 版本时应回到 Google Play，官方未另放 APK。所谓“来路不明版本”“未经查验版本版”来源不明，轻则配置导不进去，重则账号信息外泄。
安装后进入配置管理。Android 版支持 Android 7.0 及以上系统，当前面向移动设备，不支持 Android TV。想在电视盒子上用，需要提前调整预期，不要在电视端反复尝试导入后再回头怀疑配置本身。
导入配置有两条路：一是通过机场订阅链接导入，由应用拉取远端 YAML；二是导入本地已有的 YAML 文件。订阅省事，内容由服务方决定；本地文件灵活，但要自己维护。两条路最终都落在同一份 YAML 上，策略组和规则都写在这份文件里。导入之前先想清楚自己走哪条路，不要一边用订阅拉取、一边又手工大改同一份文件，否则订阅一更新，手工改动可能全部丢失。若确实需要在订阅之上做修改，应当把改动放进覆写，而不是直接改订阅内容。
stash导入节点：先理清节点来源
有人把导入节点理解成粘贴一串链接就完事。导入之后还要确认节点以什么形式存在。Stash 支持策略组和订阅来源，订阅拉下来的节点通常自动归入某个代理集合，策略组负责把这些节点按地区、按用途或按延迟重新编排。
导入时按这个顺序检查：
- 确认订阅返回的是 YAML 配置，不是单纯的节点列表；
- 确认节点名称没有重复，重名会让策略组引用产生歧义；
- 确认代理集合字段拼写与官方文档一致，大小写和缩进都要看；
- 导入后先别开全局代理，先看策略组有没有正常生成。
订阅只给节点、没给策略组时，需要自己在配置里补上策略组段落。这时 stash覆写怎么用就派上用场了：覆写能在不改动原始订阅内容的前提下增补或替换配置，订阅更新时改动不会被冲掉。
导入环节的常见错误集中在两处。一处是把节点列表当成完整配置直接导入，结果策略组段落缺失，规则里引用的组名全部落空；另一处是订阅内容能正常拉取，但节点名带空格或特殊符号，手工写规则时引用不上。遇到这两种情况，先回到节点来源确认订阅内容的形式，再决定补策略组还是清理节点命名，不要急着改规则。
stash覆写怎么用：在订阅之上做增量修改
覆写是配置体系里容易被忽略的一环。它的价值在于把订阅提供的内容和你想要的调整分开存放：订阅负责节点来源，覆写负责策略组、规则和局部参数的修正。订阅更新后，不必每次重做分组。
使用覆写要注意几点：
- 覆写针对配置结构，不针对节点本身，别指望用它换节点；
- 覆写内容要写在正确层级，策略组和规则通常位于顶层字段之下，缩进错位会让整段失效；
- 每次修改后重新载入配置，看策略组列表是否按预期出现；
- 留一份修改前的配置副本，方便回退。
文档资料列出入门、规则类型、代理协议和配置文件示例等资料。字段拿不准时对照文档，不要凭记忆拼写。配置文件示例可以当结构参考，但其中的节点和策略需要替换成自己的订阅信息，不能直接照搬。
覆写也有操作顺序可循。先在副本上写覆写内容，再在应用中重新载入配置，然后检查策略组列表是否按预期出现，最后才去动规则。顺序反过来，规则先写、覆写后补，中间任何一层出错都难以判断问题出在覆写层级还是规则引用。覆写的常见错误是缩进错位和层级放错：把策略组写进了规则段落之下，或者把顶层字段多缩进了一层，表现都是整段配置不生效，而应用未必给出明确的报错提示。另一个常见错误是把本该由订阅维护的节点信息也写进覆写，订阅更新后两处内容互相覆盖，反而更难排查。
stash 配置教程：策略组、覆写、规则路由的推进顺序
三者的关系可以这样理解：策略组决定流量交给谁，覆写决定配置怎么改，规则路由决定什么流量走哪个策略组。顺序错了，排查会很痛苦。
- 先定策略组结构。想清楚要几个组：按地区分、按用途分，还是两者结合。组太多界面臃肿，组太少分不细。定结构时顺手把组名写下，后面写覆写和规则都以这份组名为准。
- 再用覆写落地策略组。把分组逻辑写进覆写，订阅更新后结构仍然稳定。这一步做完先重新载入一次，确认策略组已生成，再继续下一步。
- 最后写规则路由。Stash 支持规则可选择直接路由、改写去向或阻断连接，规则决定域名、IP 或进程匹配后走向哪个策略组。每条规则引用的组名，都必须能在上一步生成的策略组里找到。
- 逐条验证。每加一条规则就切换一次目标应用，确认流量确实按预期走。
这个顺序的逻辑是：策略组是骨架，覆写是维护骨架的手段，规则是挂在骨架上的判断条件。反过来先写规则，很容易出现规则指向不存在的策略组，配置载入失败却找不到原因。
按这个顺序推进，回滚检查也要按同样的顺序逆向走。改完覆写后先停在这一步，重新载入配置，确认策略组列表与预期一致；如果列表没变化或者整段消失，先回退覆写内容，再对照官方文档确认字段与缩进，不要带着可疑的覆写继续写规则。规则写完后再做一次整体载入，逐条确认规则引用的组名是否存在。回滚时用修改前的配置副本恢复，而不是凭记忆逐行撤销，后者很容易漏掉一处缩进，让问题以另一种形式重现。
链式代理在移动端的落地
链式代理指的是流量经过多个代理环节再出站。在 Stash 的配置语境里，它体现为策略组之间的引用关系：一个策略组可以把另一个策略组作为成员，前后衔接。
在手机上配置链式结构，注意这几点：
- 链路越长，排查成本越高，先用两段结构跑通再考虑扩展；
- 每一段都要有明确命名，避免组 A 引用组 B、组 B 又引用组 A 的循环；
- 链式结构对规则路由要求更高，规则要能准确判断哪些流量需要走完整链路；
- 移动网络切换频繁，链路中任一环节不可用都会影响整体，关键环节保留备用策略。
链式结构的操作顺序同样要服从前面的推进逻辑：先把链路两端的策略组在覆写里定义好，重新载入确认两组都正常生成，再在规则里把需要走完整链路的流量指向链路入口组。若先写规则再补链路，规则指向的入口组还不存在，载入失败时很难分辨是规则写错还是链路没建好。链式结构最常见的错误是循环引用，A 组把 B 组当成员、B 组又把 A 组当成员，配置载入时可能直接失败，也可能表现为某个组的成员列表异常；其次是链路中间环节没有备用策略，移动网络切换时整条链路一起不可用。改动链式结构后，建议先简化到两段结构验证，确认无误再恢复完整配置。
Android 版Android 端仍属于抢先体验，配置动作应以当前页面说明为参照。链式结构相关行为以当前应用内的实际表现为准，遇到异常先简化配置，再定位问题。
收尾检查清单
配置改完后按下面这份清单过一遍：
- 应用来源是否为官方来源途径，开发者与包名是否确认过；
- 订阅是否成功拉取，节点是否完整显示；
- 策略组是否全部生成，名称是否与规则中的引用一致；
- 覆写是否生效，订阅更新后结构是否保持；
- 规则路由是否逐条验证过，有没有指向空组的规则；
- 链式结构有没有循环引用或单点依赖。
这份清单也承担回滚检查的作用。任何一项不通过，先回到对应的那一步：策略组缺失回退覆写，规则指向空组回退规则，链路异常回退到简化结构，而不是在最后一步试图一次性修补所有问题。改配置前留副本、改完后按清单逐项确认，比凭印象判断“应该没问题”可靠得多。
还有一点容易忽略：macOS 或 iOS 的授权不能直接用于 Android，Android 版通过 Google Play 计费，跨平台授权不通用，购买前先确认自己的使用场景。想了解安装步骤可以看下载客户端，初次上手看快速开始，订阅来源的选择参考机场推荐，遇到具体报错查帮助，更多配置思路在博客里，回到产品可以看整体导航。
配置字段与行为如有调整，以官方页面说明为准。先对照官方文档，再改覆写内容。
出现异常时先回到最小配置
链式代理涉及多个选择层，排查时先暂时只保留一个代理和一个策略组，确认基础连接，再逐步加回覆写与规则。若一加入覆写就出现异常，优先比较覆写前后的字段变化；若策略组能显示但请求没有按预期分流，再检查规则顺序和匹配条件。把问题拆成“代理能否连接”“策略组是否选中”“规则是否命中”三个问题，定位会更快。
修改前保存一份原始 YAML，回滚时不要凭记忆重写。Stash 支持规则可选择直接路由、改写去向或阻断连接，三种动作的目标不同，写在同一段配置里时尤其要看顺序。遇到不认识的代理协议或规则类型，先查官方文档，再决定是否加入配置。这样既能保留链式代理的结构，也能避免一次改动覆盖多个变量。