一、从上至下的包含与生成关系
这三者之间并不是平级的概念，而是一个层层嵌套与动态驱动的层级结构：
- 最高层（分发层）：订阅 (Subscription)
是一条受保护的远程 URL 链接。它的使命是建立本地设备与服务商服务器之间的“同步管道”。服务商若更换了某个机房的 IP 或调整了加密端口，只需在后台修改，用户客户端通过“更新订阅”即可自动拉取最新信息； - 中间层（执行层）：配置 (Configuration)
客户端下载订阅内容后，在本地硬盘上生成的一个结构化文本文件（如config.yaml）。配置文件不仅包含了节点信息，还写入了路由规则（Rule）、策略组（Proxy Group）、DNS 设置和本地监听端口； - 最底层（实体层）：节点 (Node)
是配置文件中proxies数组列表里的单个数据对象。例如包含{name: "香港 01", type: ss, server: ..., port: ...}。它是网络请求最终发往的远端目的地。
二、三者交互与协作全景流程
| 交互环节 | 动作触发者 | 数据如何流动 | 解决的核心痛点 |
|---|---|---|---|
| 1. 订阅拉取 | 客户端定时任务或用户手动点击 | 云端服务端 → 客户端内存 | 避免用户手动逐个输入复杂的节点密钥与端口 |
| 2. 配置文件持久化 | 客户端核心程序 | 内存数据 → 本地磁盘 YAML 文件 | 离线断网后依然能保留上一次的完整规则和节点 |
| 3. 策略组绑定 | 分流规则引擎 | 配置中的策略组关联具体节点 | 实现“访问不同网站自动匹配不同区域节点” |
| 4. 建立网络连接 | 本地应用程序发起请求 | 本地数据流 → 选中的节点通信管道 | 完成最终的数据跨国传输与网页呈现 |
三、为什么有时更新订阅后配置却没变？
这通常由以下三个技术原因导致：
- HTTP 缓存机制：客户端在请求订阅链接时，沿途的 CDN 缓存或本地客户端设置了过长的缓存有效期，导致拉取回来的依然是旧的配置文件；
- 服务商后端未刷新：服务商虽然修改了机房，但未重新生成分发节点的订阅缓存；
- 本地配置冲突：用户在客户端中开启了“配置覆写（Profile Override）”或“合并配置（Mixin）”规则，本地强制保留了自定义参数。
四、常见认知误区排查
误区：修改了客户端里的节点名称，就能改变它的连接速度？
不能。在配置文件中修改 name 字段仅仅改变了客户端界面展示的文字，并不会改变其底层的 server（服务器地址）与 port（端口）。连接速度完全取决于底层服务器的物理链路，与命名毫无关联。
五、常见问题 FAQ
Q：应该多久更新一次订阅？
建议在客户端中开启“自动定时更新”（如每 24 小时更新一次）。若遇到大面积节点突然不可用，第一步应手动点击“更新订阅”，以获取服务商切换后的最新备用节点 IP。