“把日志发来看看”不等于“把客户端整个文件夹打包发过去”。别人排查需要的是出错时发生了什么，不是你的订阅、节点密码和一整天的访问记录。

最实用的做法是：先写清故障，再选对应日志，只复制相关片段到本地新文档，检查隐私后再发送。下面以 Clash Verge Rev 桌面端和 mihomo 内核为例；其他客户端可以参考整理方法，但日志入口和内容不一定一样。

先说清楚：哪里坏了，什么还正常

求助消息里只有一句“不能用了”，对方还得反复追问。先记下这些信息，不用改任何网络设置：

• 系统名称和版本、客户端完整名称及版本；能在界面看到内核版本时也记下来，看不到就写“不清楚”。
• 当前是家庭 Wi-Fi、手机流量还是公司网络，不需要公布公网 IP。
• 系统代理、TUN、规则或全局模式的当前状态，只记录，不为了填模板切换开关。
• 故障发生的具体时间和时区，以及做了什么操作。
• 预期结果和实际结果：是订阅更新失败、窗口打不开，还是某个网页打不开？其他网页是否正常？

注意，“Clash”可能指不同软件。客户端版本和内核版本也不是同一件事，写清楚比多发十张截图更有用。不同地区的网络环境、登录状态也可能影响结果，但不需要为说明这些条件提供账号密码。

选日志，不要先选整个配置目录

Clash Verge Rev 的官方导出日志说明区分了界面日志和内核日志。窗口或界面操作异常，先找应用、GUI 相关记录；代理连接异常，内核记录通常更值得查看。两类都不能单独保证找到原因。

不同版本的日志入口、文件夹名称可能变化，按自己版本的界面和官方说明找，不要照着网上一个目录名把整个数据文件夹发出去。日志窗口与保存到磁盘的文件也未必包含同样的内容。

尤其别把 .yaml、订阅配置或备份包当成“日志附件”。官方隐私政策提醒：配置中可能有订阅 token 和节点凭据，日志也可能包含域名、IP 等连接信息。文件名字里没有“密码”两个字，不代表里面没有隐私。

这是流程示意图，不是软件截图，也不是一次实际排障的测试结果。

用故障时间找片段，别抓一天的记录

打开已有日志后，先查刚才记下的时间。如果操作本身只是打开普通网页、没有付款或删除数据等风险，可以再重复一次，记下时间；不方便复现，就说明“目前不能复现”，不要强行重做。

复制报错行和附近有关系的上下文到 Notepad++ 等本地文本编辑器的新文档中。比如同一时间段的连接、规则选择和随后出现的错误，而不是从早上开机一直复制到现在。不要改动原日志，后续需要核对时还找得到。

片段不是越短越好。只有 timeout 一个词，可能连哪一步超时都看不出来；只截最后一行，也可能漏掉前面的配置加载错误。先保留能说明操作顺序的几行，再按对方的具体问题补充。

如果对应时间没有记录，先如实说没有。不要把旧报错当成本次故障，也不要一上来就全天开启 DEBUG。mihomo 文档说明 DEBUG 会输出更多运行信息；它不等于更安全，也不保证一定能定位问题。本文不要求修改日志级别或重启服务。

隐藏敏感值，但别把错误类型一起抹掉

发送前，从头到尾看一遍准备发出的副本。重点查订阅地址、token、key、password、UUID、secret，以及账号、邮箱、文件路径中的用户名。它们可能出现在报错文字里，不只存在于配置文件。

处理时可以按这几个原则来：

1. **订阅链接整条替换。**写成 [订阅链接已隐藏]，不要只删问号后的 token：有些凭据在路径里，剩下的地址仍可能有用。
2. **节点与目标用不同代号。**节点地址写 [节点A]，访问目标写 [目标A]。同一个对象前后用同一个代号，别全部替换成“网址”，否则连接关系也看不懂了。
3. **认证内容不要留半截。**密码、UUID、控制接口密钥、Authorization、Cookie 等内容不需要靠露出前后几位来证明真实性。URL 路径、请求参数和二维码也要检查。
4. **保留非敏感的诊断信息。**时间与时区、错误类型、失败操作、客户端版本、规则匹配结果通常比具体凭据更有帮助；规则或节点名称若含私人信息，也换成代号。

这是检查思路，不是“搜几个关键词就能百分之百安全”的工具。敏感值可能没有明显字段名，账号信息也可能藏在路径或截图边角里。看不懂某段内容时，先不要发送，改发版本、现象和不含敏感值的报错摘要。不要把原文件上传到不明网站，让网站替你脱敏。

脱敏也有代价：隐藏实际域名后，对方可能无法核对某条域名规则。如果确实需要这项信息，先问清楚需要哪一个域名、为什么需要，再决定是否通过可信渠道单独提供；不必同时交出浏览历史或完整带参数的 URL。

求助消息可以这样填写

下面是填写模板，不是实际日志。方括号里的内容按自己的情况填；没有做过的对照测试就写“未测试”，不要为了让信息齐全编结果。

客户端及版本：[完整软件名称、版本]
系统及版本：[系统名称、版本]
内核版本：[可见版本，或不清楚]
网络：[家庭 Wi-Fi / 手机流量 / 其他]
当前状态：[系统代理是否开、TUN 是否开、规则或全局模式]
发生时间：[年月日、时分秒、时区]
复现步骤：[进行了什么操作，不含订阅和私人网址]
预期与实际：[想得到的结果；实际出现的现象]
影响范围：[一个网页 / 多个网页 / 订阅更新 / 客户端界面]
已有对照：[实际做过的测试和结果，没有就写未测试]
报错摘要：[保留错误类型，敏感值用代号替换]
日志类型：[GUI / 内核 / 不清楚]
附加片段：[已逐行检查的相关上下文；不能确认则暂不附]

比如只看到 connection refused，就先写清“在哪个操作后出现”，别直接下结论“机场跑路了”。一个错误词可能对应不同环节，日志是排查线索，不是故障判决书。

对方还要完整文件，怎么办

先问需要哪种文件、哪个时间段、哪些字段，以及能否用最小片段代替。公开论坛、群聊、GitHub Issue 与私人工单的可见范围不同；私聊也不等于无需检查隐私。

不确定文件能不能发，可以停在上面的文字模板这一步。不要为获得帮助提供订阅二维码、完整备份、登录密码或验证码，也不要因此开放远程控制接口。对方能否继续排查，取决于信息是否够用，不能保证一个模板解决所有故障。

如果订阅已经误发，事情就从“整理求助信息”变成“凭据泄露处理”了，可以接着看订阅链接泄露后的处理说明。如果只是延迟测试超时而网页能正常使用，则先看节点 Timeout 与实际连接的区别，避免拿错问题方向。