诊断报告如何自动脱敏，以及发送前还要检查什么
诊断报告天生处在一个尴尬的位置：它越详细，对排查越有用；它越详细，泄露的风险越大。一份原始的连接诊断可能包含你的订阅地址（等于账号本身）、系统用户名、内网结构和出口 IP——把它随手贴进群聊或工单，相当于把这些一起贴了出去。ConnProof 的答案是把脱敏做成默认的、自动的、最后一道工序：你需要主动确认才能拿到未脱敏的报告，而不是主动操作才能获得保护。
默认脱敏的完整清单
报告在渲染前整体通过脱敏模块，以下内容被处理：
| 类别 | 处理方式 | 示例效果 |
|---|---|---|
| URL 查询参数与 fragment | 整段替换 | https://sub.example/api?token=abc → https://sub.example/api?[REDACTED] |
| Authorization / Proxy-Authorization 头 | 值替换 | Authorization: [REDACTED] |
| Cookie / Set-Cookie | 值替换 | Cookie: [REDACTED] |
| token / apikey / session 等键值对 | 值替换 | token=[REDACTED] |
| UUID | 整体替换 | 设备与账号标识不外泄 |
| Windows 用户目录 | 用户名替换 | C:\Users\[REDACTED]\... |
| macOS / Linux home 路径 | 用户名替换 | /home/[REDACTED]/... |
| 邮箱地址 | 整体替换 | 联系方式不外泄 |
| 32 位以上十六进制 / 40 位以上 Base64 串 | 整体替换 | 兜底捕获明显的密钥形态 |
| password / secret 类配置字段 | 值替换 | 配置片段可安全引用 |
IP 地址采用分级策略而不是一刀切：
- 回环地址（127.0.0.1、::1）完整保留——它们不含个人信息，而本地代理排查恰恰依赖它们；
- 私网地址部分遮盖（
192.168.1.23→192.168.*.*）——保留网段特征供判断，隐去主机位； - 公网地址部分遮盖（前两段保留）——足以看出运营商与大致地区，不足以定位到你。
订阅地址被特别对待：除了参数剥离，包含订阅特征路径的 URL 会被标记为 subscription-url 类别，出现在报告的脱敏分类记录里，提醒你这份报告曾经接触过订阅信息。
脱敏在流程中的位置
顺序很重要：检测器产生原始证据 → 组装成报告结构 → 脱敏模块处理整个报告 → 渲染成文本/JSON/Markdown → 输出与保存。本地保存的副本（~/.connproof/last-report.json）保存的也是脱敏后的版本——即使这个文件将来被其他程序读到，损失也有限。每份报告的 privacy 段记录脱敏是否执行、命中了哪些类别，让"这份报告经过什么处理"本身可查。
关闭脱敏：刻意设置的摩擦
--no-redact 存在的合理场景只有一个：你自己在自己的机器上核对完整证据。为此它被设计得"难用"：必须在交互式终端里回答风险确认（输入 yes），管道和脚本环境中直接拒绝生效；生成的报告中隐私声明被替换为醒目的警告文字，避免它被误当作已脱敏版本转发。如果你发现自己经常需要 --no-redact，先想想是不是把它用在了不该用的地方——绝大多数排查场景，脱敏报告的信息量已经足够。
自动脱敏不能替代你的眼睛
必须诚实地说明边界：脱敏基于模式匹配，它认识常见的敏感数据形态，但不认识你的特殊情况。以下内容可能漏网：
- 私有格式的凭据（不符合常见 token 形态的自定义密钥）；
- 出现在自由文本里的个人信息（比如你把姓名放进了配置的备注字段）；
- 域名本身的敏感性（
公司内部系统.example.com这个域名的存在就是信息）； - 检测目标本身（报告必然包含你检测了什么——如果"你在访问某服务"这件事本身敏感，报告不适合外发）。
所以发送前的人工复查不是可选项。清单很短：
- 从头到尾读一遍要发送的内容（不是扫一眼）；
- 特别检查目标域名、路径和所有
details字段； - 确认报告开头的隐私声明是"已自动脱敏"而不是警告文字；
- 只发必要的部分——工单需要的往往只是错误码加关键证据，不必全文粘贴。
分场景的分享粒度建议
不是所有场景都需要（或应该）分享整份报告。按接收方裁剪粒度：
- 服务方客服：Markdown 全文报告是合适的——他们需要完整证据链，且与你存在服务关系。前提仍是通读复查；
- 公开社区/论坛求助：只贴错误码 + 关键证据行（三五行足够），目标域名视情况用"某订阅域名"代称。公开场合的信息会被搜索引擎永久收录，粒度宁小勿大；
- 给朋友帮忙看看：口头说错误码和结论即可，报告文件没必要流转——文件会留在对方设备上，超出你的控制；
- 提交本项目的 Issue：用 Issue 模板要求的字段，目标域名一律脱敏或用示例域名代替。项目排查的是工具行为，几乎从不需要你的真实目标。
粒度裁剪的原则一句话：接收方的排查职责有多大，给的信息就多大。职责越远，信息越少。
脱敏分类记录的另一个用途
报告 privacy.redactedCategories 字段列出了本次命中的脱敏类别（如 subscription-url、home-path）。它除了记录处理过程，还能反向提醒你这份报告曾经接触过哪些敏感面：看到 subscription-url 在列，说明原始证据里出现过订阅地址——即使已被处理，你也应该意识到这份报告与你的账号存在关联，在公开场合分享时多一分谨慎。空的分类列表则说明这次检测根本没碰到敏感数据，分享压力小得多。把这个字段当作报告的"敏感度标签"来用。
与客服/社区打交道的补充建议
- 客服若要求"完整订阅链接以便测试"，正确做法是让他们在自己的面板后台查你的账号，而不是你把链接发过去。正规服务方的客服有后台权限，不需要你的链接；
- 社区求助时，截图比文本更容易失控——截图会把终端里未脱敏的历史输出、窗口标题里的用户名一并带上。优先粘贴
--format markdown的文本报告； - 发出去的东西收不回来。对"这段能不能发"犹豫时，答案就是不发，先问清楚对方到底需要哪个字段。
常见疑问
脱敏会不会影响排查效果？ 极少。排查依赖的是结构性事实——哪层失败、什么错误码、耗时多少——这些都完整保留。被移除的凭据类信息对排查连接问题没有帮助（客服不需要你的 token 才能看服务端日志）。能不能只脱敏一部分？ 当前版本是整体开关：默认全脱敏，确认后全不脱敏。折中做法是用默认脱敏报告为主，个别需要补充的字段在通读确认后手工附上。发出去才想起没检查怎么办？ 依平台能撤回就撤回，然后评估暴露面：报告默认脱敏时实际风险通常很小；若用了 --no-redact，把其中的订阅地址视为已泄露，去面板重置订阅链接。