配置进入应用后按处理链依次变化
订阅原文是链路的起点，全局扩展与订阅扩展随后参与处理。中间出现过的值还要经过后续阶段，因而检查配置时，要追到负责该字段的阶段。
| 处理阶段 | 核对内容 |
|---|---|
| 订阅原文 | 从订阅取得的初始配置 |
| 应用设置 | 应用自己的配置处理 |
| 全局扩展配置 | 全局范围的 YAML 覆写或合并 |
| 全局扩展脚本 | 全局范围的 JavaScript 调整 |
| 订阅扩展配置 | 当前订阅范围的配置处理 |
| 订阅扩展脚本 | 当前订阅范围的脚本调整 |
| 应用设置回写 | 接管字段由应用选项确定 |
这个顺序解释的是处理关系，不是界面里的点击位置。想改当前订阅，先看订阅扩展；涉及全局范围时再核对全局扩展，不能只按名称相近选择位置。
配置采用 YAML，脚本采用 JavaScript，两者都可以参与配置调整。脚本入口接收配置参数并返回修改后的参数，文档同时说明不支持网络或文件 IO 操作。
设置接管的字段要回到设置页核对
设置页选项的优先级高于订阅原文、扩展配置和扩展脚本。被应用接管的字段，即使中间写入别的值，也会在链路末尾回到应用设置的值。
在扩展里写过某个值，不等于它就是最终采用的值。
接管范围含 mixed-port、socks-port、port、mode、allow-lan 等顶层项目，也包含 tun.enable。TUN 对话框保存过的部分设置同样在接管范围内。
对照时把字段名称保留完整，看看它是否出现在接管清单。若已由设置页管理，就同时查看对应选项，不靠反复修改订阅原文来推测结果。
替换还是合并由字段类别决定
合并规则里，列表和普通值是整体替换，文档点名的有 rules 和 tcp-concurrent。改这几项时，别指望写进去的内容会接在原列表后面。
其他嵌套对象采用子字段合并，写出的部分才参与替换，例子包括 tun 和 sniffer。读到对象这一层时，还要确认里面的具体字段有没有应用接管。
v2.5.5 之后，扩展配置里只要写了 dns 或 hosts，就是整段覆盖原来的内容；这条版本界线别漏掉。
- 原始订阅告诉你改动前的内容，不能代表链路终点。
- 扩展范围告诉你改动落在哪一层，不决定接管字段结果。
- 字段类别决定替换或合并，版本条件也属于核对内容。
改配置前按字段和范围准备
- 写下要改的完整字段名，确定它是列表、普通值还是嵌套对象。
- 对照全局与订阅作用范围，选择对应的扩展配置或脚本。
- 检查设置页是否接管该字段，再按处理链核对后续覆盖关系。
如果目的是调整规则先后，文档还提供订阅右键里的编辑规则入口。规则插入位置与配置字段合并属于不同操作，先把想改变的对象说清再选入口。
下单前的常见疑问
只改当前订阅时先核对哪层？
先区分订阅扩展与全局扩展的作用范围，再选配置或脚本。订阅扩展在全局扩展之后处理，但应用接管字段还会在末尾由设置页回写。
扩展里的列表会接在原列表后面吗？
列表和普通值整体替换，嵌套对象才按子字段合并；动 rules 之前，先想清楚自己要的是覆盖还是追加。
mode写在扩展里还要对照哪里？
还要看应用设置。mode 属于被接管的顶层字段，中间扩展写入的值会经过末尾回写，最终不能只凭扩展中的一行决定。