Nginx 长查询返回 414：请求行要能放进单个缓冲区

普通页面能访问，但查询参数变长后返回 414 Request-URI Too Large。如果这条响应由 Nginx 在读取客户端请求时产生，应检查 large_client_header_buffers 的单个缓冲区大小。把缓冲区数量从 4 改成 8，并不会让一条请求行获得两倍空间。

本文讨论 Nginx 接收 HTTP/1.x 长请求行的场景。HTTP/2、HTTP/3 的头部限制机制不同，不能直接按 HTTP/1.x 请求行长度套算；上游应用或前置代理返回的 414，也需要检查它们自己的限制。

先确认拒绝请求的是哪一层

保留触发错误的真实请求，核对 Nginx 错误日志、访问日志和上游是否收到请求。日志若显示客户端请求行过长，而上游没有收到这次请求，就先处理 Nginx 接收阶段。

如果请求已经进入上游，或前置 CDN、负载均衡器先返回 414，修改这台 Nginx 不一定生效。仅看到响应中的 Server 名称也不足以判断生成错误的组件，应把同一时间段的各层记录对应起来。

请求行包含方法、请求目标与 HTTP 版本，不只是某一个参数的长度。中文等内容经过 URL 编码后，传输长度也可能变大；应按实际发送的请求判断，不按界面里显示的字符数估算。

调整 size，而不是只增加 number

配置格式为：

large_client_header_buffers number size;

HTTP/1.x 的一条请求行不能超过一个缓冲区的大小，否则返回 414；一个请求头字段超过单个缓冲区时则可能返回 400。这与 client_max_body_size 控制请求体的用途不同，也与 proxy_buffer_size 接收上游响应头的用途不同。

例如，确认业务需要后，可以评估下面的配置片段：

large_client_header_buffers 4 16k;

16k 是示例值，需依据实际业务上限选择，不是所有 414 的推荐值。这个指令允许放在 http 或 server 中，不能放在 location。如果已有同层配置，应修改那一项，不要再追加重复指令。

缓冲区按需要分配，但放宽限制仍可能增加处理大请求的资源需求。不要为了一个长 URL 把每个缓冲区直接设置成数 MB，也不要同时调整不相关的上传或响应缓冲区。

配置写在目标站点，未必就是读取时采用的值

Nginx 创建连接时先处于默认 server 的配置上下文，后续才可能通过 TLS SNI、请求行或 Host 选择站点。读取某些请求内容时，目标站点尚未选定，可能使用该监听地址的默认 server 配置。

因此，多站点部署中只修改一个 server，应核对实际请求读取阶段是否已经采用它。需要一致的公共上限时，可以在 http 层设置，并检查各 server 是否存在覆盖；只想调整一个站点时，要同时评估默认 server 与其他站点的影响，不能随意更换 default_server 来试错。

修改前保存原配置，并确认当前进程实际使用的配置文件和 include 文件。先做配置语法检查，再按现有管理方式平滑重载；检查失败时保留运行中的旧配置，不强行重启。回退时恢复本次修改并重新检查、重载。

放行后的请求还要通过上游限制

用同一条业务请求验收：不再由 Nginx 返回 414，上游确实收到请求，最终响应也符合接口预期。若随后出现 400、502 或上游自己的长度错误，应继续处理新报错，不能把“414 消失”当成整个请求成功。

长期需要携带大量筛选条件或对象数据的接口，可以评估调整接口设计，把适合放在请求体的数据移出查询字符串。这需要客户端与服务端共同支持相应方法、缓存和鉴权行为，不能只在代理上把 GET 强行改成 POST。