排查 Nginx 故障时，日志中的状态码通常比报错描述更有用。它直接告诉你问题落在请求格式、访问权限、资源是否存在，还是请求体、请求头和协议协商这些环节。
这篇文章把常见的 Nginx 4xx 错误码按排障思路重新整理了一遍。你可以先根据状态码判断问题属于哪一类，再顺着对应的检查点去看 URL、请求头、上传限制、认证配置或上游业务逻辑，定位会快很多。
为什么要先看 Nginx 日志里的 4xx 错误
4xx 状态码表示请求已经到达服务器，但服务器认为当前请求本身存在问题，或者客户端暂时不满足访问条件。对运维和开发来说，这类状态码的价值在于：它能快速缩小排查范围。
- 400、414、431 往往指向请求格式、URL 或请求头异常；
- 401、403、407 常与认证、鉴权、代理配置有关；
- 404、410 多半要检查资源路径和发布状态；
- 413、415、416 常见于上传、分片和媒体类型不匹配；
- 429 通常意味着限流触发；
- 421、425、426 则更多涉及协议和连接层面的协商问题。
如果你的日志里连续出现同一类 4xx，通常说明问题不是随机波动，而是某个固定请求模式、配置策略或接口约束没有对齐。
请求格式与方法不匹配：先查 URL、请求头和方法
这类错误的共同点是：服务器还没进入真正的业务处理阶段，就已经判定请求不合规。
400 到 408：基础请求校验失败
- 400 Bad Request：请求格式不正确，常见原因是 URL 拼写错误，或请求头字段格式异常。
- 401 Unauthorized：客户端没有提供有效的身份验证凭证，或者凭证错误。
- 402 Payment Required：这个状态码虽然存在，但实际应用极少见，主要是为“付费访问”场景预留。
- 405 Method Not Allowed：请求使用了不被允许的 HTTP 方法，例如接口只接受
POST，客户端却发送了GET。 - 406 Not Acceptable：服务器无法生成客户端
Accept头要求的响应格式，例如客户端要求 JSON，但服务端只能返回 XML。 - 407 Proxy Authentication Required：需要先通过代理服务器的身份验证，通常与代理配置有关。
- 408 Request Timeout：客户端在规定时间内没有完成请求发送，可能是网络慢，也可能是客户端本身没有及时传完数据。
411 到 417：条件头、请求体和范围声明有问题
- 411 Length Required：服务器要求请求头携带
Content-Length，但客户端没有提供，常见于POST或PUT。 - 412 Precondition Failed：客户端设置了前提条件，例如
If-Match，但服务器检查后发现不满足。 - 414 URI Too Long：请求 URL 过长，常见于 GET 参数过多，或者拼接出了异常长链接。
- 416 Range Not Satisfiable：客户端请求的资源范围无效，常见于断点续传或分片下载场景。
- 417 Expectation Failed：客户端在请求头中使用了
Expect，但服务器无法满足对应期望。
看到这组错误时，建议优先检查三项：请求方法是否正确、URL 是否异常膨胀、请求头是否带了服务端不接受的条件字段。
认证、权限与资源状态：重点看访问控制和路径是否正确
当状态码指向身份验证、权限控制或资源存在性时，排查重点就不再是“请求写对没有”，而是“这个请求有没有资格访问、资源现在还在不在”。
403、404、410：最常见的访问失败信号
- 403 Forbidden：服务器明确知道客户端想访问什么，但拒绝提供。常见原因包括目录权限设置不当、IP 被限制，或访问控制策略命中。
- 404 Not Found：请求的资源不存在。可能是文件已删除、路径写错，或者链接本身就是死链。
- 410 Gone：资源已经被永久删除，服务端是在明确告诉客户端“这个地址以后也不会恢复”。
409、421 到 424：资源状态与路由目标不一致
- 409 Conflict：请求与服务器当前状态发生冲突，例如创建重复资源，或更新的版本已经被别人修改。
- 421 Misdirected Request：请求被发往了错误的服务器，通常需要更换 URI 或协议后重试。
- 422 Unprocessable Entity：请求体格式本身没问题，但内容无法通过业务规则校验。
- 423 Locked：资源当前处于锁定状态，暂时不能操作。
- 424 Failed Dependency：请求依赖的前置条件或上游资源失败，导致当前操作无法完成。
如果你已经确认请求格式正确，但日志仍是这类错误，就该重点核对目录权限、鉴权配置、反向代理目标、接口参数校验规则和上游依赖状态。
上传过大、头部过大或内容类型不对：这一组最常和配置限制有关
很多 Nginx 故障并不是应用崩了，而是请求在进入应用之前就被 Nginx 拦下了。上传和请求头相关的 4xx 错误，往往属于这一类。
- 413 Payload Too Large：请求体过大，常见于文件上传。一个典型处理方法是调整
client_max_body_size。 - 415 Unsupported Media Type：请求体的媒体类型不被接受，例如上传的是图片，但声明成了文本格式。
- 428 Precondition Required：服务器要求客户端带上某些前提条件请求头，但客户端没有提供。
- 429 Too Many Requests：客户端请求过于频繁，触发了服务端的速率限制。
- 431 Request Header Fields Too Large：请求头过大，常见原因是 Cookie 过多，或某个头字段异常膨胀。
其中 413 和 431 在生产环境里很常见：前者多见于上传接口，后者则常出现在接入层挂了多个系统、Cookie 不断叠加的场景。
少见但值得认识的状态码：看到时别误判
还有一些错误码不一定高频出现，但在特定场景下很有识别价值。
- 418 I'm a teapot：彩蛋状态码，字面意思是“我是茶壶”，严肃业务场景基本不会使用。
- 425 Too Early：客户端过早发送请求，通常与 HTTP/3 的早期数据有关。
- 426 Upgrade Required：服务器要求客户端升级协议版本，例如从 HTTP/1.1 升级到 HTTP/2。
- 451 Unavailable For Legal Reasons：资源因法律原因不可访问，例如合规限制或版权纠纷。
这组状态码的共同特点是出现频率不高，但一旦出现，方向通常比较明确，不必按常规的“代码有 bug”思路去排查。
看到错误码后，实际排查可以怎么下手
如果想把状态码真正用起来，可以按下面的顺序判断：
- 先区分是请求格式问题，还是权限/资源问题，抑或是请求体与协议限制问题。
- 如果是 400、414、431，先检查 URL、请求头、Cookie 和客户端拼接逻辑。
- 如果是 401、403、407，重点检查认证信息、目录权限、访问控制和代理设置。
- 如果是 404、410、421，优先核对资源路径、路由目标和发布状态。
- 如果是 413、415、416、429，重点看上传限制、媒体类型、分片范围和限流策略。
- 如果是 422、423、424、428，说明请求大概率已经进入更深层逻辑，需要回看接口约束和上游依赖。
总体来看，掌握这些常见 4xx 错误码，已经足够覆盖日常运维中大部分 Nginx 请求异常。日志里出现状态码时，先别急着盯配置文件全文搜索，先判断它属于哪一类，再决定该看客户端、Nginx 规则，还是上游应用，效率会高很多。
