TL;DR：订阅 URL 泄漏后，不要把它当普通链接。它通常就是凭据。正确处理是轮换 token、失效旧链接、查访问日志、重新导入客户端配置，再清理公开痕迹。

订阅 URL 看起来像一个下载地址，实际常带有 token、code、key、user 之类的凭据。谁拿到它，谁就可能拉取你的配置。泄漏发生在很多小动作里：截图没打码、Issue 里贴完整日志、群聊求助发了二维码、把配置文件推到公开仓库。

先判断泄漏类型

泄漏位置风险处理优先级
私人工单中看服务方可信度和访问日志
群聊高立即轮换
公开 Issue高立即轮换并删除历史
公开 Git 仓库高轮换，清 commit 历史，查爬取记录
截图或二维码高轮换，删除原图和缓存
本地日志只发给自己低仍建议脱敏保存

只要出现在半公开或公开环境，就按已泄漏处理。不要赌没人看到。

第一步是轮换 token

正确动作不是改订阅名称，也不是换客户端备注，而是让旧 token 失效。服务端应做到：

  1. 生成新 token。
  2. 新 token 对应新订阅 URL。
  3. 旧 token 立即返回 401 或 403。
  4. 旧 token 不再返回任何有效配置。
  5. 日志里保留旧 token 的访问记录，方便追踪。

如果面板只支持「重置订阅链接」，就执行重置。重置后把旧 URL 复制到浏览器验证，确认它已经不能拉到配置。

不建议让旧链接返回空配置

有些系统会让旧 URL 返回空 YAML 或空 JSON。这个做法不太好：客户端可能把空内容当成一次正常更新，结果本地配置被清空，排障更麻烦。

更清楚的方式是返回明确的 HTTP 状态：

401 Unauthorized

或：

403 Forbidden

客户端看到失败，用户至少知道旧链接不能继续用。

查访问日志

轮换后查旧 token 的访问记录，重点看：

字段看什么
时间泄漏后是否有新增请求
IP是否出现陌生地区或云服务器段
User-Agent是否从 Clash、sing-box、V2Ray 之外的工具请求
次数是否短时间高频拉取
响应码旧 token 是否仍返回 200

陌生 IP 不一定就是滥用。手机网络、公司网关、CDN 都会改变出口。但泄漏后突然出现多个新 User-Agent，或者从云服务器频繁拉取，就要提高风险等级。

客户端要删除旧 URL

轮换 token 后，客户端本地还保存着旧 URL。需要逐个处理：

  • Clash Verge Rev：复制 profile 备份后，删除旧远程 profile，导入新 URL。
  • Mihomo 相关客户端：检查 provider 里是否还有旧订阅地址。
  • v2rayN / v2rayNG：删除旧订阅分组，添加新订阅。
  • sing-box / SFA：检查 JSON 或订阅管理里的 URL。
  • Hiddify / NekoBox：确认二维码和剪贴板不是旧链接。

如果你只是在服务端重置，却没改客户端，下次刷新会报 401/403。这是正常结果，不是客户端坏了。

清理公开痕迹

轮换后再清公开记录。顺序不要反，先清记录再轮换会留下窗口期。

清理清单：

  • 删除公开 Issue、评论、论坛帖子里的完整 URL。
  • 替换截图，尤其是二维码和地址栏。
  • 删除公开仓库里的配置文件。
  • 如果进入 Git 历史，按平台流程处理历史提交。
  • 搜索泄漏 token 的前后 6 到 8 个字符，确认没有残留。
  • 对已被搜索引擎或平台缓存的页面，提交移除请求。

注意二维码。二维码里可能就是完整订阅 URL，肉眼看不出来，必须当作明文链接处理。

后续防漏做法

下次发配置前，先做字段脱敏：

https://example.com/sub?token=<redacted>&type=clash

保留参数名，删除参数值。这样别人能看格式问题，但拿不到凭据。日志里也一样，保留错误码、路径结构、客户端版本，删掉 token、UUID、password、server、privateKey。

给维护者的服务端建议

如果你维护订阅服务，至少提供这些能力：

  • 用户可以一键重置订阅 URL。
  • 旧 token 立即失效。
  • 旧 token 访问返回 401/403。
  • 访问日志能按 token 查询。
  • 下发页面提示用户不要公开 URL 和二维码。
  • token 不出现在页面标题、截图水印或可公开分享的短链接里。

订阅 URL 泄漏不是靠提醒用户小心就能完全避免。服务端必须让轮换足够简单，用户才会在出事后马上处理。

结论

订阅 URL 泄漏按凭据泄漏处理。先轮换，后清理；先让旧链接失效，再慢慢查日志和截图。只撤回消息、只改备注、只删除本地配置都不够。判断是否处理完成的标准很简单：旧 URL 再也拿不到有效配置，新 URL 只在你控制的客户端里使用。

相关阅读