数据处理清单
把每一类数据的用途、保留期与存放位置列成表，比一句「我们重视隐私」更有用，也方便你逐条核对。
| 数据类型 | 用途 | 保留期 | 存放位置 | 能否删除 |
|---|---|---|---|---|
| 线路编号与握手耗时 | 排障与健康度统计 | 7 天滚动 | 本机 logs 目录 | 可随时手动清空 |
| 错误码 | 定位握手失败原因 | 7 天滚动 | 本机 logs 目录 | 可随时手动清空 |
| 账号邮箱 | 登录校验与订阅核对 | 订阅有效期内 | 服务端账号库 | 可申请注销 |
| 设备标识 | 同时在线计数 | 会话建立起 24 小时 | 服务端会话表 | 随会话结束清除 |
| 访问过的域名 | 不采集 | 无 | 无 | 不适用 |
上表依据 4.0.2 版客户端与账号服务在 2026 年 10 月 19 日的配置核对结果整理；其中设备标识只参与同时在线计数，不用于画像，也不跨会话关联。
加密套件与会话密钥
桌面三端默认使用 AES-256-GCM，移动端默认使用 ChaCha20-Poly1305，两套都承载在 TLS 1.3 之上。会话密钥由双方在每次握手时临时协商，不落盘、不跨会话复用（来源：4.0.2 版加密模块说明）。
实测加密带来的额外开销在 M2 MacBook Air 上是上行吞吐下降 6.8%，在 2019 款 Android 机型上是 4.1%；这组读数不含线路本身的损耗，只反映本机加密运算的成本（测试条件：本地回环压测 10 分钟，各 20 次）。
DNS 与泄漏自查
连上却打不开、速率显示为 0 这两类现象，多数都能归到解析没有走隧道上，自查只要一步。
客户端内置 DNS 解析，连接建立后查询请求走隧道；若系统仍走本地解析，就会出现连上却打不开的情况。实测在 5% 丢包的模拟环境下，把解析切到内置后首包成功率从 71% 升到 96%（测试环境：Linux 客户端 4.0.2，200 次请求采样）。
关闭内置 DNS 时状态栏会固定位置给出提醒，这个提醒在 4.0.2 版里每会话出现一次，不会被其他提示挤掉，因此看到就说明解析确实没走隧道；实测在 20 次手动关闭内置 DNS 的连接中，这条提醒 20 次全部出现，没有漏报（测试条件：4.0.2 版桌面客户端）。
自查办法：断开连接后打开日志，搜索最近一次握手的耗时行，若耗时读数在连接成功后停止刷新，基本可以判定解析仍在本地。
本站页面自身的采集口径
这是一个资料与下载站，页面本身同样遵守最小化原则，能做的不写脚本就不写。
页面不加载第三方统计脚本、不加载外链字体与外链样式，也不写入 Cookie 做跨站追踪；所有样式与逻辑都内联在 HTML 里（来源：2026 年 10 月 19 日对本站全部 8 个页面的源码自查）。
站内没有评论区、没有登录框、没有表单提交，因此不收集访客填写的任何个人信息；需要联系时请用页脚给出的客服邮箱，我们只在回复该邮件时使用你的地址。
页面中出现的性能读数标注了测试条件与样本量，属于参考环境下的一次性观测值，不构成对任何一条线路的持续承诺，这一点在服务条款的责任范围一节另有说明；站内 8 个页面的读数都标了样本量，最小的一组为 10 次（来源：2026 年 10 月 19 日源码核对）。
你可以自己核对的三件事
下面三步都不需要工具，也不需要联系客服，做完就对数据流向有个清楚的认识。
- 打开客户端配置目录下的 logs 子目录，任一文本编辑器都能读取；把最近一次连接的三行记下来，与上面的清单逐条对照。
- 在设置页把日志保留天数改为 1 天，观察 24 小时后旧文件是否被新记录覆盖，这能验证滚动删除是否真的执行（测试条件：连续 2 天观察启动次数）。
- 断网后打开客户端，确认候选列表显示为离线状态而不是继续显示上一次的读数，这能确认界面数字来自实时探测而非缓存；实测断开网络后 3 秒内全部读数转为离线（测试环境：飞行模式）。