Before / After
加密前后对比：安全提升了多少，代价是什么
双层加密 + 混淆 + 终止开关是一组权衡：明文暴露面收敛至零的同时，握手时延与重连耗时必然增加。本页用可对比的数据说明取舍，而不是只讲好处。
数据口径：下表全部为示例值，用于说明量级与变化趋势，不代表服务等级承诺。真实数值取决于设备算力、线路质量、节点负载与网络环境。
Comparison Matrix
六项关键指标对比表
| 对比维度 | 未启用安全功能 | 启用双重加密 | 双重加密 + 混淆 + 终止开关 | 变化说明 |
|---|---|---|---|---|
| 链路可读内容 | 可识别域名与连接对象 | 仅密文，无可识别字段 | 呈现为常规 HTTPS 会话 | 可识别信息逐层收敛至零 |
| 断线后明文出网 | 可能整段时间直连 | 存在回落窗口 | 0 字节 | 终止开关消除回落窗口 |
| 首包时延（示例） | 约 48 ms | 约 93 ms | 约 121 ms | 安全开销集中于握手阶段 |
| 重连耗时（示例） | 约 0.6 s | 约 1.1 s | 约 1.5 s | 双重握手需重新协商密钥 |
| 丢包对业务影响 | 直接中断可见 | 中断但可自动回落 | 中断后保持阻断，需手动重连 | 可用性让位于数据安全 |
| 稳态吞吐（示例） | 基准 100% | 约 96% | 约 92% | 双层封装带来的 CPU 开销 |
读表要点：三列之间是递进关系，不是互斥选项。真正的选择发生在"开多少"——下面几节按维度展开说明每一列的实际含义。
Exposure Surface
明文暴露面：从"可识别"到"零字节"
这是三项安全功能带来的最实质变化，也是唯一无法用性能数据衡量的维度。
| 暴露类型 | 未启用 | 双重加密 | 全开 |
|---|---|---|---|
| 访问的域名 | 可见 | 不可见 | 不可见 |
| 访问的 URL 路径 | 可见 | 不可见 | 不可见 |
| 真实出口 IP | 直接暴露 | 被隐藏 | 被隐藏 |
| 真实运营商 | 直接暴露 | 被隐藏 | 被隐藏 |
| DNS 查询内容 | 明文查询 | 随隧道加密 | 随隧道加密 |
| 流量属于代理协议 | 可识别 | 可识别 | 显著降低 |
| 断线瞬间明文 | 可能整段 | 存在窗口 | 0 字节 |
| 服务端可见内容 | 完全可见 | 隧道必经，可见 | 隧道必经，可见 |
需要明确的边界：VPN 是端到端隧道，落地节点在技术上必须能看到解密后的内容。快连的约束不在加密层，而在服务端的日志策略——不记录访问内容。字段级口径见隐私与安全审核。
Latency
首包时延与重连耗时
加密开销高度集中在握手阶段。用户感知的"变慢"主要来自首包延迟与重连等待，而不是稳态传输。
首包时延（示例值）
重连耗时（示例值）
为什么终止开关不影响首包与重连：它不参与数据通道的加密运算，仅在隧道异常路径上生效。正常连接时它的常驻开销接近于零。
| 网络条件 | 未启用 | 双重加密 | 全开 | 增幅 |
|---|---|---|---|---|
| 局域网 / 20ms RTT | 约 22 ms | 约 41 ms | 约 53 ms | +31 ms |
| 家宽 / 30ms RTT | 约 48 ms | 约 93 ms | 约 121 ms | +73 ms |
| 4G / 80ms RTT | 约 138 ms | 约 196 ms | 约 231 ms | +93 ms |
| 跨境 / 220ms RTT | 约 292 ms | 约 358 ms | 约 401 ms | +109 ms |
规律：基础 RTT 越高，握手开销的绝对值越大，但相对比例越小。跨境场景下 +109ms 相对 292ms 的基础延迟只占约 37%，用户感知并不明显。
Throughput
稳态吞吐与资源占用
握手结束后，加密本身对吞吐的影响很小。真正影响带宽的是链路质量与节点负载。
| 配置 | 100 Mbps 线路 | 50 Mbps 线路 | 10 Mbps 线路 | CPU 占用（4 核） |
|---|---|---|---|---|
| 未启用 | 约 98 Mbps | 约 49 Mbps | 约 9.8 Mbps | 约 6% |
| 双重加密 | 约 96 Mbps | 约 48 Mbps | 约 9.6 Mbps | 约 14% |
| 全开 | 约 95 Mbps | 约 48 Mbps | 约 9.5 Mbps | 约 17% |
耗电与移动端
- 移动端算法按设备能力自动选择（无 AES 硬件加速时使用 ChaCha20）。
- 双重加密使 CPU 占用增加约 8 个百分点，续航影响有限。
- 长时间高带宽传输时耗电差异更明显，可按场景临时关闭混淆。
低算力设备
- 建议保留双重加密 + 终止开关，关闭混淆模式。
- 混淆封装的整形处理对 CPU 消耗高于加密本身。
- 若设备内存小于 2GB，可考虑仅开启终止开关保障底线安全。
实测建议：与其相信任何对比表，不如在自己的网络上实测两次——一次全开、一次全关，用同一个测速服务对比。这比任何公开数据都更有参考价值。
Recommendations
按场景取舍
不存在对所有人都最优的配置。下表按典型使用场景给出建议组合。
| 使用场景 | 双重加密 | 混淆模式 | 终止开关 | 理由 |
|---|---|---|---|---|
| 公共 Wi-Fi 日常上网 | 开 | 按需 | 必开 | 优先防断线泄露与被动嗅探 |
| 跨境办公 / 远程接入 | 开 | 开 | 必开 | 避免 IP 暴露给服务商，全程加密 |
| 处理敏感业务（网银/后台） | 开 | 按需 | 必开 | 对 IP 与访问目标双重保密 |
| 校园网 / 企业受控网络 | 开 | 开 | 必开 | 降低被协议识别阻断的概率 |
| 家庭固定宽带 | 开 | 关 | 可选 | 可信网络，减少握手开销 |
| 追求最低时延的游戏 / 视频 | 可选 | 关 | 可选 | 减少握手开销，但保留底线防护 |
| 服务器 / 7×24 在线环境 | 开 | 按需 | 建议关 | 阻断会导致服务中断，风险自担 |
| 低算力移动设备 | 开 | 关 | 开 | 省电优先，保留核心防护 |
默认推荐：不确定该选什么时，保持"双重加密 + 终止开关"开启、混淆模式为标准档。这是在安全性与开销之间最平衡的组合。
FAQ
关于对比数据的常见追问
这些数据是真实测试的吗？
表格结构反映真实的量级关系（加密开销集中在握手、稳态影响小），但具体数值在页面上已明确标注为示例值。上线部署时应替换为实际环境下的实测数据，并注明测试条件（带宽、RTT、设备型号、客户端版本），否则不具备可比性。
为什么加密后还有 92% 的吞吐，不是 100%？
双层加密需要对每个数据包做两次加密运算并附加认证标签，占用 CPU 资源。现代设备具备 AES-NI 等硬件加速后这部分开销已很小，但在低算力设备上占比会更明显。这是加密本身的固有成本，无法完全消除。
终止开关会让断网吗？
只在隧道失效期间阻断。隧道正常时它不介入数据传输；隧道恢复后自动放行。如果需要在阻断期间仍能访问特定资源（如内网办公系统），可以配置白名单例外，但请注意例外目标将不受加密保护。
全开之后速度下降明显，还能再优化吗？
可以从三方面入手：① 选择更近的节点降低基础 RTT；② 关闭混淆模式（它对 CPU 的消耗高于加密本身）；③ 在移动端让客户端自动选择算法。详细建议见上方按场景取舍表。