HTTP 请求头大全

HTTP 请求头是客户端发给服务器的「附加说明书」——它不改变请求的目标，却决定了服务器如何理解这个请求：接受什么格式、用什么身份、能不能走缓存、来自哪个 IP、经过哪条链路。这个工具收录了 168 个常用请求头，按 17 个分类整理，并附带一个请求头原文解析器。

怎么用

1. 在搜索框输入关键词（如 Accept、缓存、X-Forwarded、追踪），列表实时筛选；
2. 点分类标签可只看某一类，如「代理与转发」「Client Hints」；
3. 点击请求头名称*复制名称，点击*示例值复制示例；
4. 下方「请求头解析」面板可以粘贴整段请求头（每行一条 Name: value），自动逐条解析并标注是否已收录；
5. 从浏览器开发者工具「Copy as cURL」复制的内容也能直接粘贴——会自动提取其中的 -H 参数。

分类速览

请求头的结构：为什么冒号不能省

一个请求头由三部分组成：

名称: 值

• 名称是大小写不敏感的。Content-Type、content-type、CONTENT-TYPE 在服务端看来完全等价，按惯例使用 Header-Case 只是为了可读性。
• 值可以是单个 token、带引号的字符串、逗号分隔的列表，或带参数的结构（如 text/html;q=0.9）。
• 名称与值之间的冒号必须是英文冒号，值前面的空格会被忽略，Name:value 与 Name: value 等价。

一个常见的坑：用中文冒号「：」或全角空格书写请求头，服务器会直接解析失败，或把整行当作无效头丢弃。

端到端头与逐跳头

RFC 9110 把请求头分成两类，这个区别直接影响反向代理的行为：

• 端到端头（End-to-End）：面向最终接收方，代理必须原样转发。绝大多数请求头属于这一类，如 Accept、Authorization、Content-Type。
• 逐跳头（Hop-by-Hop）*：只对单次连接有效，代理*必须在转发前移除，且不得继续传递。规范定义的逐跳头只有 8 个：Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、TE、Trailer、Transfer-Encoding、Upgrade。

所以如果你在 Nginx 里配置 proxy_set_header Connection ""，本质上就是在清理逐跳头，避免它被错误地传给上游。

关于 X-Forwarded-For：一个必须警惕的头

反向代理场景下，后端服务器看到的 REMOTE_ADDR 永远是代理的 IP。为了把真实客户端 IP 传下去，业界约定用 X-Forwarded-For 记录 IP 链路：

X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
                    ↑ 原始客户端      ↑ 一级代理      ↑ 二级代理

关键点在于：这个头是客户端可以随意伪造的。攻击者只要自己发一个 X-Forwarded-For: 1.2.3.4，你的日志里就会出现假 IP。

正确的取值方式是「从右往左数，跳过所有你信任的代理」：

1. 入口代理必须无条件覆盖而非追加该头，确保最右侧始终是你自己写入的可信值；
2. 后端取值时按「从右向左、跳过已知代理 IP 段」的顺序定位真实客户端；
3. 只有限定了「仅接受来自自家 CDN 或负载均衡器回源」的入口，才可以信任 CF-Connecting-IP 这类由厂商覆盖写入的头。

如果直接把 X-Forwarded-For 的第一个值当作客户端 IP 用于风控或限流，等于把限流开关交给了攻击者。

Client Hints：User-Agent 的替代方案

User-Agent 是个历史包袱：格式混乱、各家随意扩展、既暴露隐私又难以解析。浏览器厂商的应对是 UA 缩减（UA Reduction），把 UA 字符串冻结成固定模板：

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

注意 Chrome/128.0.0.0——次要版本号被统一填成 0.0.0，真实版本不再暴露。

替代方案是 Client Hints，一套以 Sec-CH- 开头的请求头，按「熵」分级：

• 低熵（默认发送）：Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform，足够做基础的浏览器与平台识别；
• 高熵*（需服务器显式申请）：Sec-CH-UA-Platform-Version、Sec-CH-UA-Arch、Sec-CH-UA-Model、Sec-CH-UA-Full-Version-List 等。服务器必须在响应中返回 Accept-CH 列出需要哪些提示，浏览器才会在*后续请求中发送。

这种「按需申请」的机制，把「是否暴露指纹」的决定权交还给了服务器与用户代理之间的协商，而不是让每个请求都带上完整指纹。

Sec-Fetch-*：浏览器提供的可信信号

传统上服务端判断「这个请求是不是跨站伪造」只能依赖 Origin 和 Referer，而这两个头都可能缺失或被策略裁剪。

Sec-Fetch-* 系列由浏览器强制写入，页面脚本无法伪造，这是它最有价值的地方：

一个典型的加固规则：对写操作接口要求 Sec-Fetch-Site 为 same-origin 或 same-site，拒绝 cross-site；同时对没有该头的请求（老浏览器、脚本客户端）单独走 Token 校验。这样既不影响正常调用，又能挡掉绝大多数浏览器发起的 CSRF。

链路追踪：让请求跨服务可追

微服务下，一个用户操作可能横跨十几个服务。追踪头的作用是把「同一次调用」串起来：

• traceparent 是 W3C Trace Context 标准，格式为 版本-追踪ID-SpanID-标志位，跨厂商互认，是当前首选；
• tracestate 配合它传递厂商私有状态；
• Baggage 用来传递业务上下文（租户 ID、实验分组），让下游服务不必再查库；
• X-Request-ID 则是最朴素的方案：一个请求一个 ID，贯穿日志即可用检索串起全链路。

实践中两者常常并存——X-Request-ID 给运维看日志，traceparent 给 APM 画调用树。

常见坑

• Content-Length 与 Transfer-Encoding: chunked 同时出现：不同实现取值不同，是「HTTP 请求走私」的经典入口，二者必须互斥。
• 大小写不一致导致取不到值：虽然规范说名称大小写不敏感，但自己写的解析代码若用 headers['Content-Type'] 硬匹配，遇到 content-type 就会取空，解析前应统一转小写。
• Referer 的拼写：标准里就是 Referer（少一个 r），这是 RFC 沿用的历史笔误，写 Referrer 服务器收不到。
• 同名头重复出现：多数情况下应合并为逗号分隔列表，但 Set-Cookie 例外，它必须分行，不能合并。
• Cookie 里的 = 和 ;：Cookie: a=b=c; d=e 中只有第一个 = 是分隔符，值里可以含 =，但含 ; 必须编码。
• 代理链路头被无限追加：如果代理只追加不覆盖，X-Forwarded-For 会越来越长，最终触发头部大小限制返回 400 或 431。

以上请求头均可直接用于业务开发，复制后按需替换示例值即可。