日志的用途是还原发生了什么，而不是越长越有用。先选定一个可重复的失败任务，再记录相同时间范围内的错误、规则和出口。阅读时把配置加载、地址解析、建立连接和目标响应分开，能够避免把不同阶段的失败都归结为节点不能用。
先写任务，再打开日志
明确执行的操作，例如在浏览器读取一个公开页面，或更新当前订阅。记下设备、接入网络、客户端与配置名称。关闭无关的大量传输，减少日志里同时出现的其他活动，再重现一次问题，不要一边高频刷新一边收集。
记录时间和时区，方便对应客户端与系统显示。若问题发生在刚启动程序时，保留启动附近的相关记录；若只有某个操作失败，就关注该操作附近的片段。整个使用周期的日志未必比准确的一小段更有解释力。
按阶段区分错误
配置解析错误意味着内容未被正确加载，应先检查格式和兼容性。解析目标地址失败与连接建立超时发生在不同环节。目标已经返回状态或权限提示时，则应阅读网站响应，不能仍然只描述成没有联网。
例如，订阅能下载但客户端提示某个字段不支持，应优先核对配置格式；节点连接成功但网站提示账户权限不足，应确认账户条件。这个例子仅说明分类方法，不对应任何实际服务的故障结论。
看命中规则和最终出口
若客户端提供连接详情，检查失败请求是否进入内核、命中了什么规则以及最终使用哪个节点。策略组名称并非最终出口，自动选择组还可能在不同时间切换。记录实际结果，可以避免把组名相同误认为测试条件相同。
一个网页可能请求多个域名，主页面正常不代表登录或图片请求正常。先找与失败操作相关的连接，不要把日志里任何一条警告都当成根因。关联时间与目标，比凭颜色最醒目的一行作判断更可靠。
临时增加详细程度
有些内核支持不同日志级别，详细级别可能输出更多连接信息。只有现有记录不足时，才按项目说明临时提高级别；完成复现后恢复日常设置。详细记录会增加信息量，也可能增加需要处理的隐私内容。
不要为了求助长期公开运行日志，也不要假设某一等级绝对不含敏感字段。实际输出受软件和配置影响，发送前仍须阅读。如果客户端能够导出诊断包，应先了解包内包含哪些文件，再决定分享范围。
脱敏时检查所有表示形式
遮盖完整订阅地址、认证令牌、密码、二维码、账户标识和无关的本地用户路径。需要保留结构时，用一致的替代名称表示同一个对象，让支持人员仍能看懂前后关系。不要只隐藏第一处，却让同一凭据出现在后面的请求中。
原始日志保存在私有位置，另做供沟通使用的副本。裁剪应保留错误前后的必要上下文，不要把两个不同时间的片段拼成看似连续的记录。无法判断某字段是否敏感时，先说明字段类型并询问是否确有必要提供。
把求助信息写成一条完整记录
按预期行为、实际表现、复现步骤、环境和已做对照组织信息，再附上相关日志片段。描述你实际完成的检查，不写尚未执行的推测。比如换同一网络中的另一个节点后结果改变，应连同节点选择和时间一起说明。
收到建议后一次改一项，并回复该项操作后的真实结果。问题解决时记录原因与最终设置，恢复临时日志级别并收回不再需要的分享。日志应帮助减少盲目尝试，而不是成为持续传播个人连接资料的渠道。