服务器日志留多久：目录站的日志留存期限、脱敏和到期删除
服
看服务器访问日志能知道搜索引擎是不是真的来过、来了多少次、被 500 挡了多少。这类信息在别处问不出来。
但同时，日志里每一行都记着某个 IP 在几点几分请求了哪个路径。当你开始认真看它的时候，它也就是一份个人信息处理活动。
图片来源：网络，版权归原作者所有，侵权请联系删除
两条要求，方向完全不同
先看锚点。
《网络安全法》第二十一条（三）：网络运营者应当采取监测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月。这是一条下限。
《个人信息保护法》第十九条：除法律、行政法规另有规定外，个人信息的保存期限应当为实现处理目的所必要的最短时间；第六条要求处理个人信息应当限于实现处理目的的最小范围，不得过度收集；第五十一条要求采取分类管理、去标识化等安全技术措施。
一条说至少六个月，一条说越短越好。合起来的解法是：不要按「一份大日志」来管，要按用途分层。
三段式留存
| 层级 | 保留期 | 内容 | 用途 |
|---|---|---|---|
| 热日志 | 7 到 14 天 | 原始行，完整字段 | 故障排查、反爬阻断、攻击取证 |
| 温日志 | 不少于 180 天 | 原始行，但 IP 已脱敏 | 满足法定留存、爬虫行为的月度趋势 |
| 冷归档 | 按需，通常一年以上 | 只存聚合结果，不存原始行 | 年度对比、抓取预算分析 |
关键在于最后一层：归档时不留原始行，只留按天汇总的数字——每个爬虫 UA 的请求数、状态码分布、被抓的热点路径排行、分片耗时分位数。这些东西足够看出一年的趋势，又不把每个人的访问明细永久保存下来。
顺带解决另一个实际问题：日志按月无限增长、最后把磁盘和 inode 打满，是目录站很常见的半夜事故。有了分层的到期删除，膨胀就不会失控。
哪些字段要脱敏，怎么写
一、IP
- IPv4：保留前 24 位，最后一段归零（比如
203.0.113.0）。粒度到运营商或企业出口，仍然够做地区分析。 - IPv6：一般取前 48 位，后面抹平。IPv6 地址空间大得多，按单子网保留依旧能保持可用性。
脱敏必须在写入时做，不是读取时过滤。到读取时才想起来要过滤，往往已经晚了一步。
二、URL 里可能藏着东西
这是最容易被忽略的一类。用户会往 URL 里放的东西五花八门：
- 11 位连续数字（手机号）
- 邮箱地址
- 各种 token、sessionid、重置码（
?token=、?code=、?signature=）
做法是在日志格式里对 query string 走白名单：只保留你知道有用且无害的参数（page、sort、q 之类），其余一律写成一个占位符。这条规则要跟着新功能更新——每加一个新参数就盯一次。
三、Cookie 与会话标识不要进访问日志
默认的 nginx 日志格式不含 Cookie，但一旦有人为了调试把 $http_cookie 加进去，后面基本没人记得删。这条应该写成配置里的硬规定。
站内搜索日志：单独一类，处理更严
搜索框是访客最容易把自己的信息放进去的地方——手机号、订单号、快递单号、身份证后几位，几乎每种都在真实的搜索日志里见过。
三条建议：
- 写库之前做一次格式识别，命中手机号、邮箱、连续多位数字的直接不入库或打码
- 热词榜这种前台展示的地方，展示前再过一遍；永远不要把单个用户的搜索串原样回显在「搜索历史」里
- 搜索日志的保留期单独设短一些（比如 30 天），它沉淀出来的「热词统计」另行归档
访问控制三件事
- 日志别和 Web 服务放同一台机器。远程写 syslog 或者对象存储归档，攻击者拿到 Web 权限时不顺带拿到历史。
- 只有只读账号加堡垒机。不要给每个开发一把能看原始行的钥匙。
- 同步到测试或分析环境前必须脱敏。这一步是事故高发区——为了复现一个 bug 把生产日志拉到本地或者灌进测试库，从此就多了一份说不清在哪的全量数据。
到期删除要有证据
「我们配了 logrotate」和「我们真的删掉了」是两回事，被问到的时候要拿得出东西：
- 日志按天分片，文件名带日期，删除按时间整份走
- 删除任务跑完写一条带时间戳的记录，成败都要能被看到（失败要报警，不然它会在某天悄悄失效）
- 每季度抽查一次：随机找一天的历史日志，确认它在预期之外不存在
出海站补一句
如果同一个站还服务欧盟用户，那边的主导原则是「不超过必要期限」，方向和「至少六个月」相反。解法还是分层：安全合规用途的日志按当地要求确定期限，SEO 与产品分析用途的日志单独一组、期限更短、脱敏更强，并在隐私政策里写清各组的用途与时限。
把日志当成一份需要说明的数据，而不是一串可以随便复制的文本，这些问题自然就有了答案。