“软件不能用”很难让别人判断下一步，而直接发送全部配置又可能泄露订阅和密码。有效的排错记录，应让对方复现现象，同时只包含必要信息。
环境先写清楚
记录操作系统与架构、客户端版本、实际内核版本，以及系统代理还是 TUN。客户端和内核是两条版本信息；只写“最新版本”过一段时间就无法对照。
补充网络环境，例如家庭 Wi-Fi、热点或办公 VPN，同时说明正常基线是否可用。无需公开精确地址与账户，重点是可能影响解析和路由的差异。
Party 用户还要记录实际选用的内核
Clash Party（原 Mihomo Party）当前项目说明包含 Smart 与 Mihomo 内核选择。报错记录里应写明实际使用了哪一个及其版本，不能只写“Party 最新版”。客户端相同，实际内核和生成配置也可能不同；先保留配置副本，再以相同条件对照，才容易判断问题发生在哪一层。
用一个最小操作描述现象
选择一个可以稳定出现问题的动作，写出预期结果和实际结果。比如打开某个页面后，连接记录出现了什么规则、哪个出口，以及日志给出的错误。不要把几个不同时段的故障混在一张截图里。
写明已经做过的对照：系统代理是否正常、是否只在 TUN 失败、是否只影响一个应用。一次只改变一个变量得到的结果，通常比尝试过十种“优化”更有帮助。
发出之前做脱敏
隐藏订阅完整 URL、节点服务器凭据、控制 API 密钥、账户标识和不必要的内网信息。需要保留结构时，用 example.com 等示意值替换，并标明已经替换，避免别人把样例当作真实测试目标。
日志只截取与复现时间相邻的部分，保留第一条明确错误和上下文。最后补上最近一次正常工作的状态，以及此后改动了什么。这样一份记录既方便别人协助，也方便你下次遇到类似问题时自己快速恢复。