樱花猫 sakuracat 无日志架构拆解:隐私零留存如何实现

“无日志”是 VPN 行业最常被提及、也最容易被误读的三个字。本文从 樱花猫 sakuracat 的实际架构出发,讲清楚哪些数据根本没有被记录,哪些数据被记录了但会在短时间内自动销毁,以及这中间的工程取舍。

樱花猫 sakuracat 无日志架构封面图,展示日志最小化设计
樱花猫 sakuracat 无日志架构:日志最小化设计(封面图)

本文目录

先明确边界:无日志不等于“系统完全无状态”。账号需要知道你的订阅是否有效,计费需要知道还剩多少时长。这些与身份绑定、但无法回溯浏览轨迹的数据,属于维持服务的最小必要信息。

哪些数据根本不被记录

核心节点的服务端不写访问日志、不写连接日志、不保存出口 IP 与用户真实 IP 的映射关系。这意味着即使有人拿到服务器,也无法拼出“某个账号在某个时间访问了某个网站”的画像。这是无日志承诺里最关键的一层,也是第三方审计重点核查的对象。

数据类别是否记录留存位置
访问网站列表不记录—
连接时间戳不记录—
真实 IP 与出口映射不记录—
流量内容不记录—

这一层靠的是“默认不采集”而不是“采集后加密存储”。因为加密存储仍留有可解密的副本,只有从源头不写,才谈得上不可回溯。

共享内存记账与会话密钥

在线状态和流量计费需要某种形式的计数。樱花猫采用共享内存计数,把并发连接数和瞬时流量写入内存,内存数据不落盘、进程重启即清零。这样既能支撑“同一账号最多五台设备”的限制判断,又不会留下可事后审计的连接明细。

樱花猫 sakuracat 共享内存记账与会话密钥轮换示意
共享内存记账:数据不落盘,重启即清零

会话密钥采用短周期轮换,每个隧道使用独立密钥,服务端不保存可复用的长期密钥。密钥只在建立连接时短暂存在,断开后即失效,配合前向保密,即使某段会话被截获也无法解密历史流量。

临时诊断日志的生命周期

完全不保留任何日志会让排障变得困难。樱花猫保留了一类“临时诊断日志”,只记录连接建立失败的错误码与节点负载,不含用户身份与访问内容。这类日志默认 24 小时自动清理,官方已承诺按审计意见把周期压缩到 4 小时。

日志类型记录内容保留周期
访问日志不记录—
临时诊断日志错误码、节点负载4–24 小时
账号数据邮箱、套餐、时长订阅期内

一位长期关注隐私议题的独立开发者在试用后做了抓包与服务器侧抽查,确认连接阶段没有向第三方统计接口回传可关联身份的字段。这个案例不构成权威结论,但至少说明无日志承诺可以被普通用户用基础工具做初步验证。

樱花猫 sakuracat 临时诊断日志自动清理周期示意
临时诊断日志的自动清理周期示意

总结:无日志不是一个开关,而是“默认不采集 + 内存记账 + 短周期轮换 + 临时日志最小化”的组合。它做不到绝对的数学证明,但能把可回溯性降到工程上可控的最低。配合 第三方安全认证,这套架构才算有了外部验证。对普通用户,选 VPN 时与其看“无日志”三个字,不如问一句:服务端到底写不写、写什么、存多久。

← 返回新闻列表

用户评论(5)

岳岳先生 · 2026-10-02 11:09

共享内存记账这个说法解释得清楚,之前一直不懂无日志和计费怎么共存。

曹曹女士 · 2026-10-02 13:44

临时日志 4 小时清理,这个细节够硬,说明不是糊弄人。

邓邓同学 · 2026-10-02 16:27

抓包那段挺真实,自己动手验证比看广告强。

万万先生 · 2026-10-03 08:51

会话密钥轮换这块没展开讲,能再出一篇密钥管理的文章吗?

宋宋女士 · 2026-10-03 19:15

问一句“写不写、写什么、存多久”这个思路值得所有隐私服务借鉴。

相关阅读