414 是什么
414 URI Too Long 表示请求的地址（含查询串）超过了服务端能够处理的上限。最常见的情形是把大量参数塞进 GET 查询串：几百上千个编号拼在地址里，或者把整个表单当成查询参数提交。规范定义在 RFC 9110 第 15.5.15 节。它与 431 要区分开：414 说的是地址太长，431 说的是请求头太大。
基本信息
| 状态码 | 414 URI Too Long |
|---|---|
| 语义 | 请求地址超出服务端限制 |
| 规范 | RFC 9110 §15.5.15 |
| 常见触发 | GET 查询串过长、地址里塞数据 |
| 与 431 区别 | 431 指请求头字段过大 |
| 与 400 区别 | 400 指地址含非法字符或格式错误 |
各层限制参考
| 组件 | 限制项 | 说明 |
|---|---|---|
| Nginx | large_client_header_buffers | 默认 4 8k，请求行包含在内 |
| Apache | LimitRequestLine | 默认 8190 字节 |
| Tomcat | maxHttpHeaderSize | 默认约 8k，请求行同样受限 |
| 浏览器 | 地址栏长度 | 通常 2000 到 8000 字符，各家不同 |
| HTTP/2 | 协议本身不限长度 | 由服务端实现自行限制请求路径长度 |
复现与改进写法
复现与改进写法
# 复现：把上千个编号拼进查询串
curl -si "https://api.example.com/items?ids=$(seq -s, 1 2000 | head -c 9000)" | head -3
# HTTP/1.1 414 URI Too Long
# 改进：改用 POST 批量查询接口
curl -s -X POST https://api.example.com/items/batch-query \
-H 'Content-Type: application/json' -d '{"ids":[1,2,3]}'典型使用场景
- 批量接口设计评审：判断该用 GET 查询串还是 POST 请求体
- 接入第三方回调：对方把大量参数拼在地址里，触发自身服务端限制
- 爬虫与压测脚本调优：发现超长地址导致请求被拒，改为分批提交
- 网关策略核查：确认上游与下游对地址长度的限制是否一致
- 排障区分：确认是地址过长、请求头过大还是字符非法
按 HTTP 语义，GET 请求不应该带请求体，虽然多数实现能接受，但网关与缓存的处理并不一致。需要提交大量标识时，正确做法是设计一个批量查询接口用 POST 承载，或把请求拆成多批，而不是一味调大服务端的地址长度上限。另一个常见来源是跳转时不断追加参数，地址随重定向链条越接越长，排查时应当一并检查跳转规则。