发 Clash 日志求助前，哪些订阅和隐私信息必须打码？
日志可能包含订阅 token、节点密码、控制端 secret、邮箱、设备路径和访问域名。先复制文件、最小截取并脱敏，泄露的凭据要立即轮换。
先看重点至少遮住完整订阅 URL/二维码及 token、节点服务器密码/UUID/密钥、控制 API secret、邮箱订单号、完整公网 IP、用户名和本机路径。保留时间、错误类型、协议名称与脱敏后的域名即可。若原文已公开发送，撤回不等于安全，应立即重置订阅或轮换凭据。
Clash/Mihomo 日志适合判断请求有没有进入内核、命中什么规则以及在哪一层失败，但完整日志不是普通截图。订阅地址、节点认证字段、访问域名和本机路径一旦发到公开群，就可能长期留在转发、机器人和搜索缓存里。
必须遮住的内容
- 完整订阅 URL、二维码、
token=参数； - 节点密码、UUID、private key、pre-shared key；
external-controller的secret；- 代理 URL 中的用户名和密码；
- 机场登录邮箱、订单号、支付信息；
- 完整公网 IP、设备名称、系统用户名；
- 文件路径中能识别个人或公司的部分；
- Cookie、Authorization、Bearer token 与会话 ID。
OWASP 建议日志不直接记录 access token、密码、连接字符串、加密密钥和敏感个人信息；需要分析时应移除、遮罩或脱敏。
哪些信息应保留
过度打码也会让日志失去价值。通常可以保留：
- 精确到分钟的故障时间；
- 客户端和内核版本、操作系统；
- 错误类型，例如 timeout、reset、TLS alert；
- 入站类型、规则名和策略组名；
- 域名的必要部分，或用一致占位符表示同一目标；
- IP 的网段/归属，而不是完整个人出口；
- 能复现问题的最短步骤。
如果域名本身就是问题核心，可以在可信的一对一工单中提供；公开群里先写“目标 A”，等支持人员说明必要性再补充。
先复制，再处理副本
不要直接在原日志里一边查一边发。复制到新文本，截取故障前后几十行，用一致占位符替换敏感值，例如：
https://example.com/sub?token=[SUBSCRIPTION_TOKEN]
server: [NODE_HOST]
password: [NODE_PASSWORD]
user path: C:\Users\[USER]\...替换后再次搜索 http、token、password、secret、uuid、Authorization、@ 和常见密钥格式。截图还要检查标题栏、通知、二维码和浏览器地址栏。
自动打码不能完全依赖
GitHub 文档提醒，秘密经过 URL 编码、Base64 或结构化转换后，自动脱敏不一定匹配。聊天软件更不会替你识别机场 token。真正发送前必须人工复核。
压缩包可能包含历史日志、完整配置和崩溃转储，比单张截图风险更高。支持人员若只需要错误片段，不要上传整个配置目录。
已经发出去了怎么办
撤回或删除只是第一步。凭据已经进入其他人的通知、下载或机器人时，应按已泄露处理：
- 到机场后台重置订阅 token；
- 更新所有设备中的新订阅；
- 轮换自建节点密码、UUID、API secret；
- 清理公开消息和可控的云端文件；
- 检查异常设备数、流量与登录记录。
GitHub 对泄露秘密的处置也把撤销/轮换放在删除历史之前，因为删除副本不能让旧凭据失效。
最小披露原则
先发版本、时间、错误行和脱敏后的上下文；对方确实需要更多时再逐步增加。能用文字说明的问题，不必上传整个屏幕录像。日志是诊断工具，不应成为第二次安全事故。
资料来源
以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……