怎么把转换结果变成长期可用的订阅链接

三种出口，解决的是三种问题

站内和订阅有关的入口不少，但它们的职责并不一样。把它们分清楚，后续维护会轻松很多。

convert

convert 更像一个“订阅生成器页面”。你可以在页面上调参数，确认目标平台、来源链接和转换选项，然后得到可继续使用的参数组合。

/sub

/sub 是真正的动态输出接口。它根据 query 生成订阅结果，更适合被客户端直接订阅。

/dynamic

/dynamic 是固定地址模式，适合长期分发。你不需要把所有参数都暴露给最终用户，而是维护一个更稳定的 path + security 入口。

推荐场景

场景一：你只是临时测试

如果只是临时试一条转换规则，直接从 convert 开始就够了。它的优点是快，适合试错。

场景二：你已经确认参数组合可用

当你确认 query 已经稳定，而且客户端以后会反复拉取，就应该切到 /sub 这个动态输出层，不要再把页面调试结果手动复制来复制去。

场景三：你要把地址长期发给别人

如果这条订阅地址要长期给自己或团队使用，优先进入 动态订阅管理，生成固定 /dynamic 地址。这样后续替换上游订阅、调整 User-Agent、增加手动节点，都不需要重新发链接。

为什么不要长期分发一次性转换结果

很多维护成本都来自“把临时结果当正式出口”。常见问题包括：

• 旧 query 参数散落在聊天记录里
• 切换上游后需要重新通知所有人
• 自定义请求头或多个来源难以集中管理
• 无法快速知道到底是谁在访问哪个固定地址

而固定 /dynamic 地址的好处是，把不稳定的上游变化收敛到站内后台维护。

一个可执行的迁移步骤

1. 先在 convert 里把目标平台和参数调通
2. 用客户端验证一次 /sub 输出
3. 确认后进入 动态订阅管理
4. 把多个来源、自定义 User-Agent 和手动节点收敛到 /dynamic
5. 最后只分发固定地址

示例：上游地址更换后，客户端仍显示旧节点

1. 打开 动态订阅管理，找到客户端正在使用的那条订阅，更新对应的上游来源并保存。
2. 从管理页复制现有的固定订阅地址，与客户端保存的地址核对，避免更新了另一条订阅。
3. 在客户端手动刷新订阅，检查节点名称或数量是否符合新的来源。
4. 若仍然显示旧内容，查看刷新时间和错误日志，再检查上游地址是否可访问、返回格式是否正确，以及是否存在缓存。

固定地址可以减少重新分发链接的次数，但客户端仍需刷新才能获取最新内容。订阅地址中的安全参数应和密码一样妥善保管。

推荐工具与延伸阅读

• 先在 动态订阅转换 里把参数跑通，再进入 动态订阅管理 固定出口。
• 如果你还在整理原始节点或检查节点兼容性，可以先回到 节点转换。
• 如果你想把订阅源文件和分发边界再拆清楚，可以继续看 把配置文件放回仓库管理：什么时候该用 GitHub / GitLab / Gitee 文件工具。