服务器磁盘告警的网站那天下午，我打开Nginx访问日志，访问看到一个IP在三个小时内请求了四万七千次。日志全是网站POST，全打在同一个登录接口上。访问这不是日志正常用户能干出来的事。

日志文件就是网站这样，平时没人看，访问出事第一个被翻出来。日志它躺在/var/log/nginx/access.log里，网站每来一个请求就追加一行，访问安安静静，日志像个从不主动说话的网站目击者。但你要是访问知道怎么问它，它能告诉你的日志东西比监控图表还多。

一行日志里藏着什么

拿一条典型的Nginx日志出来看：

203.0.113.42 - - [12/Mar/2025:14:23:07 +0800] "GET /api/v2/users?page=3 HTTP/1.1" 200 4823 "https://example.com/dashboard" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36"

从左往右：客户端IP、远程用户标识（通常是空的）、认证用户名（也经常是空的）、时间戳、请求方法和路径、协议版本、响应状态码、响应体字节数、Referer、User-Agent。

大多数人只关注状态码和IP。但真正有意思的东西往往藏在后面那几个字段里。比如Referer能告诉你流量从哪来——是搜索引擎、社交媒体，还是某个你根本不知道的站点在盗链你的图片。User-Agent更是个信息富矿，爬虫、扫描器、正常浏览器，一眼就能分辨。

那个被暴力破解的夜晚

回到开头那个案例。四万七千次POST请求，状态码几乎全是401。我写了个简单的awk命令按IP聚合：

awk '{ print $1}' access.log | sort | uniq -c | sort -rn | head -20

排名第一的IP贡献了绝大部分请求量。再看它的User-Agent——Python-requests/2.28.1。正常用户不会用这个。再查请求间隔，每秒三到四次，规律得像机器在敲钟。

把时间戳拉出来一看，攻击从凌晨两点零三分开始，到五点十一分结束。那个时间段正好是我睡得最沉的时候。服务器没装fail2ban，Nginx也没配限流，等于门开着让人随便试钥匙。

后来我加了limit_req模块，对登录接口做了每分钟十次的限制。又装了个脚本，每小时扫一遍日志，某个IP如果401超过五十次就自动丢进iptables黑名单。这些操作都不复杂，但前提是你得先去看日志。

404不一定是坏事

有段时间我发现404错误特别多，集中在/wp-login.php和/xmlrpc.php这两个路径上。我的站点根本不是WordPress搭的，这些请求显然是自动化扫描器在批量探测常见漏洞。

但另一些404就有意思了。有个老链接/blog/2019/redis-pitfalls被频繁请求，来源是某个技术论坛的帖子。那篇文章我两年前迁移站点时忘了做重定向，读者点过去就是404。这种404是真实用户在告诉你：你的网站有问题。

所以我养成了一个习惯，每周过滤一次404日志，把高频出现的路径挑出来，该做301的做301，该恢复的恢复。用户体验的提升有时候就是这么具体而微。

日志格式可以自定义

Nginx默认的combined格式够用，但不够好。我在nginx.conf里改成了这样：

log_format detailed '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time';

多了两个字段：$request_time是Nginx处理请求的总耗时，$upstream_response_time是后端应用返回的时间。这两个数字一对比，你立刻能判断瓶颈在前端还是后端。如果request_time是2秒，upstream_response_time是0.01秒，那问题出在网络传输或客户端本身；反过来，那就要去查应用代码了。

这个改动很小，但它把日志从“谁来了”升级到了“来了之后体验怎么样”。

别等出事才翻日志

我见过太多团队，日志写了几个月没人看，磁盘满了就删，出了安全事故才后悔没留证据。日志的价值不在于记录本身，而在于你愿不愿意定期去读它。

不需要什么高级工具。一条grep，一个awk，加上一点好奇心，就能从那些看似枯燥的文本行里挖出很多故事。攻击、爬虫、死链、性能瓶颈、用户行为——全在里面。它不说话，但它什么都知道。

(责任编辑：焦点)