使用方法
- 把浏览器开发者工具里复制出来的请求头原文贴进文本框；页面已服务端直出一段示例，含起始行 1 行与头字段 12 行，整段 534 字符，打开即可看到解析结果。
- 按 Ctrl（Mac 上是 Command）+ Enter 触发解析；文本框里的 Enter 留给换行，不会误触发。
- 「字段名筛选」填字段片段即可只看匹配字段，例如填 cache 只看缓存相关头、填 content 只看协商与实体头；留空则列出全部。
- 结果区给出起始行、头字段行数、整段文本字符数、最长与最短字段、平均头值长度。
- 列表下方的三个按钮分别用于继续展开、以 TSV 复制当前表格、导出带 UTF-8 BOM 的 CSV（Excel 直接打开不乱码）。
- 点「重置为示例」回到初始那段请求头，方便重新对照。
这个HTTP请求头速查表能解决什么问题
调试跨域、缓存、鉴权或断点续传时，最耗时的往往不是改代码，而是确认「浏览器到底发了什么」。本页把一段请求头原文拆成可核对的清单：每个字段属于哪一类、值有多长、能不能在 fetch 里被改写。头被服务端拒掉时，可以按「单条超限」还是「总量超限」来判断方向——nginx 按单条 8 KB 卡并返回 400，整个头区超出服务器缓冲会被断连，431（RFC 6585）表示请求头字段过大，而被误当成头问题的 413 说的是请求体过大、与头无关。另外，Sec- 前缀、Host、Cookie、Accept-Encoding 这类由浏览器保留的标头，在 fetch 里写了也不会生效，本页把它们单独标出来，省去一轮无效排查。
计算原理与变量说明
解析按四步走：先统一换行符，再按行切分，然后从每一行里取出字段名与值，最后做长度与类别统计。
- 起始行识别：包含
HTTP/的行视为起始行（如示例的GET /tools/http-headers/index.htm HTTP/1.1），不参与头字段统计。 - 字段切分：以第一个冒号为界，冒号前是字段名、冒号后到行尾是值；冒号后那一个空格属于书写规范，不计入值长度。示例 12 个值合计 336 字符，除以 12 得到平均头值长度 28.0 字符。
- 最长与最短：按值长度排序取两端。示例中最长是
User-Agent，值 111 字符；最短是Cache-Control，值 8 字符——两者相差 14 倍，说明头长度的瓶颈几乎总在 UA 与 Cookie 上。 - 类别归属：16 个常用字段按请求上下文 2 个、内容协商 3 个、凭证与状态 2 个、缓存与条件 4 个、CORS 与来源 2 个、代理与实体 3 个归类。
- 可改性判定：浏览器保留
Sec-前缀标头，并把Host、Cookie、Accept-Encoding、Upgrade-Insecure-Requests、Origin一并纳入自动附加范围，JS 设置这些头会被静默丢弃或抛异常。
为什么「头太大」不能只靠一个数字判断？因为各家实现的卡点是两种口径混在一起。nginx 的 large_client_header_buffers 4 × 8k 限制的是单条头不超过 8 KB，超了返回 400；Apache 的 LimitRequestFieldSize 默认 8190 B 同样是单条头口径；Tomcat 的 maxHttpHeaderSize 默认 8192 B 限制的是整个请求头；Node.js 没有硬性的头条数上限，但 headers 总长超过 16 KB 会直接断开连接。于是「一条头很长的请求」与「很多条中等长度的头」会在同一台服务器上产生完全不同的结果，这也是排查时必须先看列表的最大单条长度、再看总量的原因。
431 与 413 为什么常被混淆：两者都在 4xx 里且都与「太大」有关，但 431 由 RFC 6585 定义为「请求头字段过大」，而 413 指的是请求体过大，和标准定义的头字段没有任何关系。看到 413 时去调头的大小，方向就完全错了。另外 HTTP/2 用 HPACK 压缩头部，上限由 SETTINGS_MAX_HEADER_LIST_SIZE 通告，常见取值是 8 KB 或 16 KB，和 HTTP/1.1 的字节数上限不能直接换算。
书写层面的两条硬规矩：头名大小写不敏感（content-type 与 Content-Type 等价），但冒号后必须有空格；同名头可以重复出现，服务端通常按逗号合并成一条。X- 前缀的自定义头则已被 RFC 6648 劝退——它本意是标记非标准扩展，一旦字段标准化就得改名字，反而制造兼容负担，所以推荐直接用不带前缀的业务名。
完整示例（数值仅作演示）
把示例原文粘进来（默认已填好）点「解析请求头」，应得到下面这组数，本页所有示例数字都由页面自身的算法复算得出。
- 起始行 1 行；头字段 12 行；整段文本 534 字符。
- 最长字段 User-Agent，值 111 字符；最短字段 Cache-Control，值 8 字符。
- 平均头值长度 28.0 字符（12 个值合计 336 字符）。
- 16 个常用字段按类别分布：请求上下文 2 / 内容协商 3 / 凭证与状态 2 / 缓存与条件 4 / CORS 与来源 2 / 代理与实体 3。
- 标记为「不可改」的字段里，
Host与Cookie由浏览器按目标站点自动附加，Accept-Encoding决定压缩方式，三者都不应由业务代码指定。 - 本段文本没有任何一行超过 8190 B，也不会触发 16 KB 的总量断连阈值，因此它是一份「干净」的对照基线。
HTTP请求头对照表
下表列出 16 个常用请求头字段的类别、能否由 JS 改写与常见取值。
| 字段名 | 类别 | 能否在 fetch 里改 | 常见值 |
|---|---|---|---|
Host | 请求上下文 | 不能，由浏览器自动填入 | www.liuquan.net |
User-Agent | 请求上下文 | 不能，属禁止修改的标头 | Chrome/131.0.0.0 Safari/537.36 |
Accept | 内容协商 | 可以 | application/json, text/plain, */* |
Accept-Encoding | 内容协商 | 不能，浏览器保留 | gzip, deflate, br |
Accept-Language | 内容协商 | 随浏览器语言设置 | zh-CN,zh;q=0.9 |
Authorization | 凭证 | 可以 | Bearer 令牌串 |
Cookie | 状态 | 不能，按同源策略附加 | sid=8f3a91c2; theme=dark |
Cache-Control | 缓存 | 可以（请求侧） | no-cache / max-age=0 |
If-None-Match | 条件请求 | 可以，配合 ETag 取 304 | 实体标签值 |
If-Modified-Since | 条件请求 | 可以，配合 Last-Modified | Wed, 01 Oct 2026 00:00:00 GMT |
Origin | CORS | 不能，跨域与 POST 时自动带 | https://www.liuquan.net |
Referer | 来源 | 受 Referrer-Policy 控制 | https://www.liuquan.net/tools/ |
Range | 范围请求 | 可以，断点续传与视频拖拽 | bytes=0-1023 |
X-Forwarded-For | 代理追加 | 客户端可伪造成立 | 203.0.113.42 |
Content-Type | 实体头 | 可以，POST/PUT 必填 | application/json; charset=utf-8 |
Upgrade-Insecure-Requests | 导航 | 不能，值固定为 1 | 1 |
下表是各家实现对请求头体积的上限，注意「单头」与「全部头」是两种口径。
| 实现 | 配置项 | 默认值 | 约束口径与后果 |
|---|---|---|---|
| nginx | large_client_header_buffers | 4 × 8k | 单头 ≤ 8 KB，超出返回 400 |
| Apache | LimitRequestFieldSize | 8190 B | 单头 ≤ 8190 B |
| Tomcat | maxHttpHeaderSize | 8192 B | 整个请求头 ≤ 8 KB |
| Node.js http | 无硬性条数上限 | 16 KB | headers 总长超 16 KB 直接断连 |
| HTTP/2（HPACK） | SETTINGS_MAX_HEADER_LIST_SIZE | 8 KB / 16 KB | 由对方通告，常见取这两档 |
| Cookie（RFC 6265 建议下限） | 浏览器实现 | ≥4096 B / ≥50 条 | 单条不低于 4096 B，每域名不低于 50 条 |
下表是常见状态码与请求头的联动关系，状态码本身的定义请看专门的对照页。
| 状态码 | 与请求头的联动 |
|---|---|
| 200 | 正常返回，可带 ETag 供下次条件请求使用 |
| 204 | 无响应体，Content-Length 省略 |
| 206 | Range 生效，响应带 Content-Range |
| 301 / 302 | Location 必带 |
| 304 | If-None-Match 或 If-Modified-Since 命中 |
| 400 | 头超长或头语法错误 |
| 401 | 缺失或错误的 Authorization |
| 403 | 权限不足，与 401 的区别在于身份是否有效 |
| 405 | 请求方法与路由不匹配 |
| 412 | If-Match 或 If-Unmodified-Since 未命中 |
| 413 | 请求体过大，与头无关 |
| 431 | 请求头字段过大（RFC 6585） |
结果边界、舍入与适用说明
- 平均头值长度保留 1 位小数（示例 28.0），其余计数为整数；中间过程不二次舍入。
- 整段文本字符数按 Unicode 码点统计，包含换行符；中文字段名各计 1 个字符。
- 空行会被跳过；既不含冒号、也不含
HTTP/的行计入「无法识别」，不计入字段数。 - 「能否改写」针对浏览器环境的
fetch与 XHR；服务端发出的请求不受这套保留列表约束。 - X-Forwarded-For 由反向代理追加，客户端可以直接伪造，因此不能作为真实来源 IP 的判据。
- 本页不解析请求体、不发请求、不校验证书，也不参与 Cookie 的读写。
- HTTP/2 与 HTTP/3 的头经过压缩传输，这里的长度均指解压后的原始字段长度；各家上限取自默认配置，实际部署可能被改小或放大。
常见问题
为什么我在 fetch 里设置了 User-Agent 却不生效？
User-Agent 属于浏览器保留的「禁止修改的标头」，这类名字由浏览器自己填。Sec- 前缀的标头同样如此，JS 里写了会被静默忽略。若确实需要自定义标识，改用不带前缀的业务头。
头太长时到底会看到 400 还是 431？
取决于卡在哪一层。nginx 的 large_client_header_buffers 默认 4 × 8k，是单头口径，超过 8 KB 判 400；431 由 RFC 6585 定义，语义就是请求头字段过大。Tomcat 的 8192 B 针对整个头，Node.js 则在 headers 总长超过 16 KB 时直接断连。
413 是不是也属于头太大？
不是。413 指请求体过大，与头字段无关；真正在讲头过大的是 431。看到 413 应该去查上传体积、网关的 body 限制，而不是头的长度。
自定义请求头还能用 X- 前缀吗？
不推荐。RFC 6648 已劝退 X- 前缀：字段日后被标准化还得改名，反而制造兼容负担。推荐直接使用不带前缀的业务名。
冒号后面不加空格会被服务器拒绝吗？
规范要求冒号后有一个空格。多数服务器会宽容处理，但严格实现会直接判 400，而且不同代理层的宽容程度不一致。本页会单独列出「冒号后缺空格」的行。
同一个字段名能出现两次吗？
可以。请求侧同名头允许重复，服务端通常按逗号合并为一个逻辑值；真正不能乱用的是响应侧的 Set-Cookie，它有专门的多次出现语义。
这个工具免费吗？
免费，无需注册即可使用。
输入的数据安全吗？
安全。解析在当前浏览器本地完成，不会上传输入内容。