CSRF（跨站请求伪造）防护已经成为Web应用的标配，但在实际部署中，经常会出现合法请求因为token缺失而被服务端拒绝的情况。Nginx作为反向代理和Web服务器，处于所有HTTP流量的必经之路，它的日志比应用层日志更早、更完整地记录了每一次请求的原始状态。当我们怀疑某些接口是因为CSRF token没有正确传递而被拦截时，直接分析Nginx日志往往比翻查后端框架日志更高效。
很多团队在排查CSRF相关故障时，习惯先去后端查业务日志，但后端日志通常只记录“校验失败”，却看不到请求头里到底有没有携带token，也无法快速按客户端IP或URL聚合。Nginx如果配置了合适的日志格式，就能把请求行、请求头、响应状态码以及上游响应时间全部落盘。通过对这些字段的提取和过滤，我们可以明确知道哪些请求没有带token、它们访问了什么路径、返回了什么状态。
在深入日志检查之前，需要先理解CSRF token在HTTP协议中的常见承载方式。绝大多数框架要求前端把token放在请求头（如X-CSRF-Token）或者表单字段中。如果前端是Ajax调用但忘记从Cookie或元标签里读取并注入请求头，那么Nginx收到的请求里就不会出现对应的头。此时后端校验中间件会直接返回403，而Nginx的访问日志中$status变量就会记下这个值。
配置Nginx日志格式以捕获关键字段
默认情况下，Nginx的combined日志格式只包含远程地址、用户代理、请求行和状态码，并不记录自定义的CSRF请求头。要检查token缺失，我们必须先在http块或server块中定义一个新的日志格式，把可能需要排查的头信息写出来。例如使用$http_x_csrf_token变量可以获取客户端传来的X-CSRF-Token头，若为空就代表缺失。
下面是一段典型的日志格式定义，它在传统combined基础上增加了token头和上游状态码，方便后续用脚本区分“真正缺失”和“带了但错误”的情况：
log_format csrf_check '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'csrf_token:"$http_x_csrf_token" '
'upstream_status:"$upstream_status" '
'request_time:"$request_time"';
access_log /var/log/nginx/access_csrf.log csrf_check;
配置完成后重载Nginx，让新格式生效。这里要注意，变量名中的下划线对应头部的连字符，即X-CSRF-Token在Nginx里写成$http_x_csrf_token。如果应用使用的是X-XSRF-TOKEN，则要写成$http_x_xsrf_token。日志写入后，缺失token的请求在该字段显示为一个短横线，这是Nginx对空值的默认表示。
除了访问日志，错误日志也有价值。当后端返回403时，如果配置了error_log的info级别，有时会记录上游返回的明细。不过错误日志不如访问日志结构化，因此主要排查手段还是访问日志配合格式化字段。建议在预发环境先验证日志内容，确认token头能被正确打印，再推到生产。
使用命令行工具筛选缺失token的异常请求
当日志按上述格式运行一段时间后，我们会得到一个包含csrf_token字段的文本文件。下一步就是用Linux命令行快速找出“状态为403且token为空”的记录。最常用的是awk，它可以按空格或引号切割字段，但因为我们格式里用了引号包裹，更简单的方式是用grep配合正则。
例如，要列出所有token字段为短横线且状态码为403的行，可以执行：
grep 'csrf_token:"-"' /var/log/nginx/access_csrf.log | grep '" 403 '
这条命令先筛出token缺失的行，再从中找403响应。得到的结果可以直接用awk提取IP和URL做统计：
grep 'csrf_token:"-"' /var/log/nginx/access_csrf.log | grep '" 403 '
| awk '{print $1}' | sort | uniq -c | sort -nr | head -20
上面这段脚本会输出发起缺失token请求最多的前20个客户端IP。如果发现某个内部服务IP大量出现，那很可能是后台定时任务或微服务间调用没有走前端渲染流程，自然也没有token。如果大量来自真实用户IP，则多半是前端资源未正确加载元标签，或者Ajax封装层漏掉了头注入。
除了命令行，也可以把日志丢进ELK或Grafana Loki，用查询语言做可视化。但无论用什么工具，核心逻辑都是“用token空值加异常状态码构建过滤条件”。这种思路比盲目看全部403要清晰得多，也能避免把正常的无token静态资源请求（如GET图片）误判为攻击。
结合业务场景区分真实缺失与误报
并不是所有没有CSRF token的请求都是故障。在RESTful API设计中，如果接口本身被标记为匿名可访问，或者使用了基于Bearer Token的认证而非Cookie同步模式，那么CSRF防护可能根本不适用。此时Nginx日志里token为空是正常的。我们需要结合$request中的方法和路径来排除这些场景。
举个例子，如果缺失token的请求全是GET /static/开头的资源，那完全不需要处理。只有当POST、PUT、DELETE等修改型请求且指向/api/前缀时才需要关注。可以用如下方式进一步过滤：
grep 'csrf_token:"-"' /var/log/nginx/access_csrf.log | grep -E '"(POST|PUT|DELETE) /api/' | grep '" 403 '
通过这种方法，能把排查范围收敛到真正有问题的写操作接口。再配合前端源码检查，确认相关页面的JavaScript是否从<meta name="csrf-token">读取并塞进请求头，基本就能闭环定位。对于后端开发者来说，也可以在框架中间件里临时把“缺失token但本应放行”的接口打印出来，和Nginx日志做交叉验证。
最后要提的是，CSRF token缺失有时是HTTPS和HTTP混用导致的Cookie不下发，进而前端读不到token。这种情况在Nginx日志里表现为token缺失伴随$scheme为http。因此建议在日志格式里也加上$scheme变量，便于识别协议层面的配置遗漏。整体来看，Nginx日志检查是一条低成本的排障链路，不需要改动业务代码即可快速看清流量全貌。
NginxCSRF_token日志分析修改时间：2026-08-14 17:45:33