HTTP 请求头速查

Q: X-Forwarded-For 到底算不算标准请求头？

不算。它没有被任何 IETF 标准文档定义，属于事实标准——nginx、CDN、云厂商都用，所以到处都能见到。RFC 7239 后来定义了官方的 Forwarded 头（for=192.0.2.60;proto=https;host=example.com）作为替代，但生态普及度远不如 X-Forwarded-For。本工具把这类头统一标为「非标准」，不代表它不该用，只是提醒你它的格式没有规范保证。

Q: 取客户端 IP 时能直接信 X-Forwarded-For 吗？

不能。这个头是逐级追加的（client, proxy1, proxy2），客户端可以在发起请求时就伪造一个前缀，让你的程序读到假 IP。正确做法：只信任你自己可控的代理写入的那一段（通常从右往左数第 N 级），或者直接让最外层可信代理覆盖写入 X-Real-IP。用它做限流、封禁等安全判断时尤其要谨慎。

Q: 为什么我加了个自定义请求头就多了一次 OPTIONS 请求？

因为你触发了 CORS 预检。跨域请求一旦带了非「CORS 安全列表」内的头（例如 X-Token、Authorization），浏览器会先发一个 OPTIONS 预检，带上 Access-Control-Request-Method 与 Access-Control-Request-Headers，询问服务端是否允许。服务端必须响应对应的 Access-Control-Allow-Headers 与 Access-Control-Allow-Methods，否则正式请求不会发出。想减少预检，可以把预检结果缓存（Access-Control-Max-Age）。

Q: If-None-Match 和 If-Modified-Since 有什么区别？

两者都是协商缓存的条件请求头：If-None-Match 比对资源的 ETag（内容指纹），If-Modified-Since 比对最后修改时间。ETag 精度更高（能识别 1 秒内多次修改、内容变回原样等情况），且同时存在时服务器优先判断 If-None-Match。条件成立返回 200 全量内容，不成立返回 304 Not Modified，客户端继续用本地缓存。

Q: Sec-CH-UA 这些头为什么我抓包时看不到？

它们属于 Client Hints，出于减少被动指纹收集的考虑，浏览器默认不发送绝大多数 Sec-CH-* 头：需要服务端先返回响应头 Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Model（或等价的 meta 标签）声明需要哪些，后续同源请求才会带上，且一般只在安全上下文（HTTPS）下生效。基础的 Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform 属于「低熵」提示，浏览器会默认发送。

Q: Content-Length 和 Transfer-Encoding 能同时用吗？

不能，两者互斥：Content-Length 用于长度已知的请求体，Transfer-Encoding: chunked 用于长度未知时分块传输。如果同时出现，规范要求忽略 Content-Length，实际实现里还可能被判定为请求走私（Request Smuggling）而被拒绝。日常开发中请求体长度一般由 HTTP 客户端自动计算，不需要手工设置。

Q: 请求头大小写敏感吗？

不敏感。HTTP/1.1 的头字段名大小写不敏感，content-type 与 Content-Type 等价，规范推荐用连字符大写形式（Content-Type）。需要注意的是 HTTP/2 与 HTTP/3 强制要求头字段名小写，传输时会统一转成小写；头值仍然大小写敏感（比如 Bearer、ETag 的内容）。

Q: 这份速查表能离线使用吗？

可以。所有请求头数据是页面内置的静态内容，无任何网络请求，联网与否都能查阅。点「🖨️ 打印 / 存 PDF」还能导出一份纸质版速查表。

网络调试完全免费 🔍 关键字搜索 🏷️ 标准 / 非标准标注 📥 离线可用 🌙 支持黑夜模式

调接口时看到 X-Forwarded-For、Sec-Fetch-Site、If-None-Match 一脸懵？这里把 10 类 67 个常用请求头整理成一张表：中文含义、真实示例值、什么时候用，以及它到底是不是 IETF 标准，支持关键字搜索与一键复制。

类别程序员 · 网络调试

运行方式纯前端 · 离线运行

收录范围10 类 · 67 个常用请求头

数据存储无存储

📨 HTTP 请求头速查

10 类 67 个请求头，标准与非标准都标清

按分类筛选或直接搜索；每条给出中文含义 + 示例值 + 使用场景，并标注来源是否为 IETF 标准。

核心特性

10 类 67 个常用请求头

中文含义 + 真实示例值

每条带使用场景说明

标准 / 非标准明确标注

关键字即时搜索（中英文）

分类标签快速筛选

一键只看标准请求头

整表复制与打印 / 存 PDF

请求头为什么值得单独查一遍？

状态码回答「这次请求结果如何」，请求头则回答「客户端到底要什么、是谁、能不能复用缓存」。很多线上问题的根因都藏在请求头里：Content-Type 写错导致后端解析失败报 415；If-None-Match 命中导致返回 304 让你以为接口没生效；加了自定义头触发 CORS 预检 OPTIONS，而服务端没放行 Access-Control-Allow-Headers。

更麻烦的是「是不是标准」这件事本身就很混乱：X-Forwarded-For、X-Request-Id、X-Real-IP 几乎所有项目都在用，但它们从来没有被写进 IETF 标准文档，只是事实标准；而 Forwarded（RFC 7239）才是官方给出的替代方案。反过来，Sec-Fetch-*、Sec-CH-UA 这些看着眼生的头，反而是有规范背书的。

这份速查表按内容协商、认证与凭证、缓存与条件请求、请求体、请求上下文、范围与连接、跨域与安全、客户端提示、代理与链路、常见非标准共 10 类收录 67 个请求头，每条都标明来源。所有内容为静态文档，无任何网络请求，可离线使用。

怎么用

搜索请求头

在搜索框输入头名或关键词（如 cookie、跨域、缓存），表格会即时过滤。
按分类筛选

点上方分类标签切换到某一类；「常见非标准」会集中列出 X- 系列等事实标准头。
只看标准头

点「只要标准请求头」可过滤掉所有非 IETF 标准的头，写规范性文档时很实用。
复制或打印

点「📋 复制当前列表」把当前筛选结果复制成纯文本，点「🖨️ 打印 / 存 PDF」可导出纸质速查表。

使用技巧

Host 是 HTTP/1.1 里唯一必需的请求头，虚拟主机靠它区分同一 IP 上的不同站点。
Content-Type 决定服务器如何解析请求体：提交表单常用 application/x-www-form-urlencoded，提交 JSON 必须写 application/json; charset=utf-8。
Authorization: Basic xxx 只是 base64 编码而不是加密，任何人都能还原，必须走 HTTPS。
带自定义头（如 X-Token）的跨域请求会触发 CORS 预检，服务端必须放行 Access-Control-Allow-Headers。
Sec-CH-*（Client Hints）绝大多数需要服务端先用响应头 Accept-CH 声明，且仅在 HTTPS 下发送。
X-Forwarded-For 可以伪造：取客户端 IP 时应只信任你可控的那一级代理写入的值，别拿它做安全依据。
Referer 是规范里的拼写（少一个 r），可能为空或被 Referrer-Policy 裁剪，不要依赖它做鉴权。

更新记录

v1.0 2026-09-20 首次上线：10 类 67 个常用 HTTP 请求头速查，含中文含义、示例值与使用场景，标准 / 非标准来源标注，关键字搜索、分类筛选、只看标准头、整表复制与打印。

常见问题

X-Forwarded-For 到底算不算标准请求头？

不算。它没有被任何 IETF 标准文档定义，属于事实标准——nginx、CDN、云厂商都用，所以到处都能见到。RFC 7239 后来定义了官方的 Forwarded 头（for=192.0.2.60;proto=https;host=example.com）作为替代，但生态普及度远不如 X-Forwarded-For。本工具把这类头统一标为「非标准」，不代表它不该用，只是提醒你它的格式没有规范保证。

取客户端 IP 时能直接信 X-Forwarded-For 吗？

不能。这个头是逐级追加的（client, proxy1, proxy2），客户端可以在发起请求时就伪造一个前缀，让你的程序读到假 IP。正确做法：只信任你自己可控的代理写入的那一段（通常从右往左数第 N 级），或者直接让最外层可信代理覆盖写入 X-Real-IP。用它做限流、封禁等安全判断时尤其要谨慎。

为什么我加了个自定义请求头就多了一次 OPTIONS 请求？

因为你触发了 CORS 预检。跨域请求一旦带了非「CORS 安全列表」内的头（例如 X-Token、Authorization），浏览器会先发一个 OPTIONS 预检，带上 Access-Control-Request-Method 与 Access-Control-Request-Headers，询问服务端是否允许。服务端必须响应对应的 Access-Control-Allow-Headers 与 Access-Control-Allow-Methods，否则正式请求不会发出。想减少预检，可以把预检结果缓存（Access-Control-Max-Age）。

If-None-Match 和 If-Modified-Since 有什么区别？

两者都是协商缓存的条件请求头：If-None-Match 比对资源的 ETag（内容指纹），If-Modified-Since 比对最后修改时间。ETag 精度更高（能识别 1 秒内多次修改、内容变回原样等情况），且同时存在时服务器优先判断 If-None-Match。条件成立返回 200 全量内容，不成立返回 304 Not Modified，客户端继续用本地缓存。

Sec-CH-UA 这些头为什么我抓包时看不到？

它们属于 Client Hints，出于减少被动指纹收集的考虑，浏览器默认不发送绝大多数 Sec-CH-* 头：需要服务端先返回响应头 Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Model（或等价的 meta 标签）声明需要哪些，后续同源请求才会带上，且一般只在安全上下文（HTTPS）下生效。基础的 Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform 属于「低熵」提示，浏览器会默认发送。

Content-Length 和 Transfer-Encoding 能同时用吗？

不能，两者互斥：Content-Length 用于长度已知的请求体，Transfer-Encoding: chunked 用于长度未知时分块传输。如果同时出现，规范要求忽略 Content-Length，实际实现里还可能被判定为请求走私（Request Smuggling）而被拒绝。日常开发中请求体长度一般由 HTTP 客户端自动计算，不需要手工设置。

请求头大小写敏感吗？

不敏感。HTTP/1.1 的头字段名大小写不敏感，content-type 与 Content-Type 等价，规范推荐用连字符大写形式（Content-Type）。需要注意的是 HTTP/2 与 HTTP/3 强制要求头字段名小写，传输时会统一转成小写；头值仍然大小写敏感（比如 Bearer、ETag 的内容）。

这份速查表能离线使用吗？

可以。所有请求头数据是页面内置的静态内容，无任何网络请求，联网与否都能查阅。点「🖨️ 打印 / 存 PDF」还能导出一份纸质版速查表。

💬 留言板 0

全部留言需审核通过后展示

💬

还没有留言，来抢沙发吧！