Nginx 是否正在被扫描、注入或暴力尝试，很多时候不用等业务异常才发现，日志里早就已经留下了痕迹。本文按访问日志、错误日志和安全模块日志三个层次拆开看，帮助你判断哪些字段最值得盯、哪些现象更像攻击信号，以及哪些记录更适合补进自定义日志里长期监控。
访问日志里最先暴露的攻击线索
access log记录的是每一次 HTTP 请求的基本画像，也是排查外部攻击时最先要看的数据来源。只要字段保留得足够完整，很多异常模式都能直接从访问记录中看出来。
先看来源：客户端身份信息能追到谁在发起请求
识别攻击源时，最关键的字段通常是 $remote_addr 和 $http_x_forwarded_for。前者反映直接连接到 Nginx 的客户端 IP，后者则常用于还原经过代理或负载均衡后的原始来源地址。
此外，$http_user_agent 也很有价值。如果用户代理中频繁出现“bot”“scan”“curl”这类关键词，通常说明访问不是正常浏览器行为，而更像脚本、扫描器或自动化攻击工具在探测站点。
再看请求内容：方法、路径和参数最容易暴露攻击意图
$request 字段包含请求方法、URL 和协议版本，例如 GET /admin.php HTTP/1.1。如果一个普通网站里持续出现非必要的 PUT、DELETE 请求，或者请求路径频繁指向 /wp-admin、/env 这类敏感位置，基本就不是正常访问了。
$args 则适合用来观察请求参数中的攻击载荷。如果参数里出现 ' OR 1=1 -- 这类 SQL 注入特征，或 <script> 这类 XSS 载荷，就已经属于非常明确的攻击尝试。
状态码不是结果汇总，而是攻击过程的回声
$status 往往能帮助判断攻击已经推进到哪一步。高频 404 通常意味着攻击者在批量探测目录、接口或敏感文件；短时间内集中出现大量 403，往往和权限绕过、后台探测或受限资源访问有关。
如果 500 错误开始异常增多，就需要警惕攻击者是否正在尝试触发漏洞，例如构造恶意参数导致应用抛出异常。单个错误未必说明问题，但高频、重复、带有明显路径规律的状态码变化，通常更值得重点分析。
频率和访问模式能区分正常流量与自动化攻击
访问日志还适合用来观察行为模式。比如同一 IP 在短时间内发起大量请求，如果达到“每秒超过 10 次”这一量级，就需要怀疑是否存在 DDoS 攻击、暴力破解或接口轮询。
另一个容易被忽视的字段是 Referer。异常 Referer，例如伪造来源页、和业务完全无关的外链来源，可能用于钓鱼跳转，也可能只是为了掩盖恶意请求的真实路径关系。它本身未必能单独定性，但和高频访问、敏感路径、可疑 User-Agent 叠加后，判断价值会明显提高。
错误日志里有哪些更直接的安全告警
error log 记录的是 Nginx 在处理请求和运行过程中产生的异常事件。它不像访问日志那样覆盖所有请求，但一旦出现集中报错，往往更接近安全问题已经影响到服务处理流程的阶段。
4xx 错误经常对应扫描和未授权访问
当 400 Bad Request、403 Forbidden、404 Not Found 频繁出现时，首先要判断这是不是正常业务流量带来的噪声。尤其是高频 404，通常意味着有人在枚举敏感文件、后台路径或历史接口。
如果 403 错误集中出现在管理入口、受限目录或内部接口上，则很可能是攻击者正在尝试访问未授权资源，或者测试权限控制是否存在绕过空间。
5xx 错误更像服务被打穿或被压垮的信号
500 Internal Server Error 的频繁出现，需要结合请求路径和参数一起看。它有可能说明恶意请求已经成功触发了后端异常，例如利用 SQL 注入、代码执行链或应用逻辑缺陷制造报错。
而 502 Bad Gateway、503 Service Unavailable 的集中出现，则更像后端不可用或服务器过载。如果这些错误与突发高并发请求同时发生，就要考虑 DDoS、慢请求攻击或上游服务被压垮的可能性。
配置错误本身也会暴露安全薄弱点
并不是所有安全风险都来自外部攻击，Nginx 自己的配置问题同样会在错误日志里留下记录。例如 deny 指令配置不当，可能导致本该受限的资源被放行，或者把正常请求错误拦截。
再比如 SSL 证书相关错误，也可能直接暴露 HTTPS 配置存在缺口。对于这类问题，错误日志的价值不只是“报错”，而是提醒你当前的安全边界配置并不稳固，需要尽快修复。
安全模块的报错通常包含更完整的攻击细节
如果启用了 ModSecurity 之类的安全模块，它们生成的错误日志会比普通 Nginx 报错更接近“安全事件记录”。这些内容通常会明确写出攻击类型、命中的规则、请求 payload 以及最终采取的拦截动作。
对于高级威胁识别来说，这类日志非常关键，因为它不仅告诉你“哪里错了”，还会告诉你“攻击者具体做了什么”。
安全模块和自定义日志能补齐哪些信息
仅靠默认 access log 和 error log，很多安全分析仍然不够细。想把日志真正用于持续监控，就需要借助安全模块和自定义日志格式，补充更有针对性的字段。
安全模块日志适合记录更细粒度的拦截事件
启用 ModSecurity 等模块后，可以记录更细的安全事件，例如 OWASP Top 10 攻击检测结果、自定义规则触发记录以及拦截动作。相比单纯看状态码，这类日志更适合快速定位高风险请求和规则命中原因。
如果站点需要长期面对互联网暴露面，这类日志往往是识别复杂攻击链的重要补充。
通过 log_format 补充关键字段，才能长期做安全监控
可以通过调整 log_format 指令，把更多与安全相关的字段写入日志。例如使用 $ssl_protocol 和 $ssl_cipher 记录 HTTPS 协议和加密套件，便于排查是否仍有弱加密协议在被使用。
再比如使用 $request_time 记录请求响应时间，可以辅助发现慢请求是否正在拖垮服务，进而识别潜在的 DoS 风险。对安全监控来说，真正有价值的不是“日志越多越好”，而是字段设计能否支撑后续分析和告警。
怎么把这些日志真正用在安全分析里
Nginx 日志里的安全信息并不零散，关键在于把访问来源、请求内容、状态结果和模块告警串起来看。访问日志更适合发现扫描、注入、暴力尝试等前端行为，错误日志更适合确认异常是否已经影响处理链路，而安全模块和自定义字段则负责补足证据细节。
如果只能先做一件事，优先保证访问日志字段完整、错误日志保留充分，再根据业务风险逐步补充 log_format 和安全模块记录。这样在真正遇到安全事件时，日志才能从“事后查看”变成“可用于判断和追踪的证据链”。
