问题报告里最容易让核对失败的两类字段，是含糊的版本说法和含有订阅口令的日志。仓库说明配置与日志只保存在本地、项目不收集用户数据；发布页用标签和资产文件名区分版本与架构；服务日志与文件错误日志则是追查内核停止原因的依据。电脑端安装包还按系统分成普通包、内置 Webview2 包、deb 与 rpm，版本三个字对不上资产名时，后续所有日志都失去对照坐标系。提交之前应当自己检查：版本能否在发布页对上号，日志是否已经去掉可滥用的参数。
适用条件
在填写版本或粘贴日志之前进行检查。适用于准备提交的错误报告，尤其是内核不能启动、服务安装失败、虚拟网卡或系统代理异常、域名覆写或订阅更新提示异常。也适用于准备回复无法复现时再次附上的日志，避免同一份含口令的文件被重复粘贴。
不适用：只用截图代替版本标签；把整份订阅文件当作日志附件；在仍使用已不再支持的 Win7 时，把该环境的日志当作当前发布线的有效样本。正式版与滚动更新版也必须分开标注，后者可能存在缺陷，不能写成与前者相同的版本身份。
检查版本
打开 https://github.com/clash-verge-rev/clash-verge-rev/releases ，把报告中的版本改写成与标签一致的形式，而不是只写刚刚下载。同时核对这些身份是否与资产名一致：Windows 的常用六十四位与 ARM64，以及仅在企业版或无法安装 Webview2 时使用的内置 Webview2 包；macOS 的苹果芯片包与英特尔芯片包；Linux 的 deb 与 rpm，以及六十四位、ARM64、ARMv7。架构写错时，对方会按另一组修复项理解问题。还要标明当前是正式版还是滚动更新版：前者高可靠性、适合日常使用；后者适合测试反馈、可能存在缺陷。已废弃的 Alpha 标签只用于测试发布流程，不应再填成当前版本。若报告中的 Windows 系统是 Win7，可直接判定与当前发布线不对齐。
检查脱敏日志
说明日志来源：服务自身运行日志文件，用于追查内核被停止的原因；文件错误日志，含有具体路径和失败原因；窗口中内核启动失败的原因原文，以及窗口恢复后仍提示尚未解决的错误。检查时应删除订阅完整网址，查询参数只保留 token=示例；节点地址、访问令牌、个人邮箱应去掉。路径里的用户名可以换成占位符，但应保留能够说明权限问题的目录结构，因为数据目录所有权不符、系统盘根目录权限被误判、用户目录位于外置磁盘，都是发布说明中的真实分支。不要为了看起来干净而删掉时间戳和错误原文，否则无法对应偶发的启动失败。日志必须来自本机导出，这与隐私说明中配置与日志仅保存在本地的表述一致。
判断依据与失败时下一步
版本检查通过的依据：标签、架构、包类型、构建通道都能在发布页找到对应资产。日志检查通过的依据：能看出失败原因，并且第三者无法用其中参数访问你的订阅。不能通过的依据：只有最新版三个字外加未打码链接；或者删改之后看不出当时是服务模式还是 Sidecar。
若应用没有直接给出路径，先根据已经保存的服务日志文件定位，不要填写资料中未出现的目录。若脱敏之后无法判断问题，保留错误类型与文件名、去掉口令后再贴一次。若报告里的版本号与安装包文件名不一致，以安装包文件名为准并写明。需要判断是否已经修复时，只阅读同一仓库发布说明中的修复问题列表，不要把优化改进条目当成缺陷已经消失的依据。
https://github.com/clash-verge-rev/clash-verge-rev https://github.com/clash-verge-rev/clash-verge-rev/releases