很多导入问题都卡在这里：用户以为自己复制的是同一条链接，实际上客户端拿到的内容不一样。浏览器看到说明页，Clash 拿到 YAML，sing-box 拿到 JSON，V2Ray 客户端拿到 base64 列表，这在订阅系统里很常见。

常见格式对照

正文特征可能格式常见客户端
proxies:、proxy-groups:Clash/Mihomo YAMLFlClash、Clash Verge Rev
{ "outbounds": ... }sing-box JSONSFA、Hiddify、Karing
vmess://、vless:// 多行URI 列表V2Ray 系客户端
一整段 base64V2Ray 订阅包装V2RayN、V2RayNG
<html>网页或错误页浏览器预览

第一步不是猜，而是保存响应正文。只看 App 的「失败」提示，信息量太少。

User-Agent 对返回格式的影响

HTTP 请求会带 User-Agent。订阅端可以据此判断请求来自浏览器、Clash、sing-box 还是其它客户端。再加上 URL 查询参数，例如 target=clash、flag=singbox，就能把同一份账号数据转换成不同配置。

这不是坏设计。问题在于：当订阅端判断错客户端，或者用户把浏览器预览地址复制给 App，返回格式就会错位。

实用排查流程

  1. 复制原始订阅 URL，保存一份不要改。
  2. 用浏览器打开，看是否为网页、配置或空响应。
  3. 用目标客户端导入，记录错误提示。
  4. 在订阅后台选择明确的客户端格式。
  5. 再次导入，不要把旧二维码截图继续转发。

如果你需要多端共用，选择兼容 Clash / Singbox / V2Ray 的订阅时，也要分别取 Clash、sing-box、V2Ray 三种导出链接，而不是强行一条链接跑全部客户端。

给订阅维护者的检查表

  • 返回 Content-Type 与正文一致，不要把 YAML 当 HTML。
  • 浏览器访问时给出清楚提示，不要静默返回空文本。
  • 支持显式参数固定格式。
  • 错误 token 返回 401/403，而不是 200 空白。
  • 在文档里写明各客户端推荐格式。

把格式固定下来后，所谓「某客户端导入玄学」会少很多。

订阅 URL User-Agent 格式的收尾动作

协议兼容、规则集和订阅格式会随着客户端更新变化；正文没有覆盖的系统版本，应以维护者文档和当前 Release 说明为准。

订阅 URL User-Agent 格式这类工具页要把回滚动作、费用影响和权限变化写清楚。安装包只从维护者仓库、Release、应用商店或系统包源获取，生产设备只保留可追溯来源。

改配置前备份原文件，保留客户端版本、内核版本和错误日志。路由器、NAS、手机和桌面端的权限模型不同，不能把同一条命令直接搬过去。

项目看什么不宜继续的信号
回滚动作当前后台、日志或设置页里能直接看到的字段页面提示和手头资料对不上
费用影响费用、权限、地区或设备造成的实际影响已经影响付款、审核、生产环境或家庭使用
权限变化回退入口、旧配置、官方支持材料找不到回滚方式，或责任人无法确认

相关阅读