接口联调定位问题
前后端联调时，前端说接口没返回数据，后端说已经发了。双方各执一词时，把请求和响应头完整抓下来，对比 Content-Type、Content-Length 和 Transfer-Encoding 字段。一次联调中，后端误将 JSON 数据设为了 text/html 编码，前端解析失败。本工具能逐字段比对，让双方在同一个事实基础上讨论，而不是靠感觉猜测。
传 输 方 向Request · Response · General
头 部 分 类内容/实体 · 请求 · 响应 · 缓存 · CORS · 安全
H T T P 头 全 表Gallery · 点卡片看语法与示例
点选左侧任一 HTTP 头
查看 说明 / 取值语法 · 示例与相关头
查看 说明 / 取值语法 · 示例与相关头
就绪 · 对照 MDN / RFC 9110 · 含请求/响应/缓存/CORS/安全头 + 方向 + 取值语法 + 示例 · 全程浏览器本地
第一节
关于本工具
About调试接口时，服务端返回 403，翻遍文档也猜不透是哪个请求头没传对。在这个工具里粘贴 cURL 或逐字段输入，它立即解析并列出所有请求头与响应头的标准含义、必需性、常见取值，连非标准头也标注来源。所有解析在浏览器本地完成，请求头数据不会离开设备。
使用场景
排查 CDN 缓存命中
运维同事发现某张商品图片更新后，用户端看到的还是旧图。用本工具查看响应头中的 X-Cache 字段：若显示 HIT 或 TCP_HIT，说明 CDN 节点未过期；若显示 MISS 或 TCP_MISS，则回源正常。同时检查 Cache-Control 的 max-age 值，确认缓存策略配置是否合理。一次排查中，发现某个静态资源被设置了 7 天的 TTL，导致紧急更新无法即时生效。
API 鉴权失败排查
第三方开发者接入支付回调时，一直收到 401 错误。用本工具查看请求头中的 Authorization 字段，发现签名算法写对了，但时间戳 timestamp 比服务器时间慢了 3 分钟，触发防重放攻击拦截。同时检查 User-Agent 和 Accept 字段，确认请求格式是否与服务端预期一致。这个工具把十几个请求头字段平铺展示，不用逐条去翻浏览器 DevTools。
网站重定向链分析
SEO 同事发现某个着陆页被搜索引擎索引了多个版本（http、https、www、非 www）。用本工具依次请求各版本 URL，查看响应头中的 Location 字段，绘制出完整的重定向链条。一次分析中，发现由于 Nginx 配置错误，http://example.com 先跳到 https://www.example.com，再跳回 http://example.com，形成了死循环。本工具能一次性展示每次跳转的响应头，不用反复按 F12。
移动端网页适配调试
手机浏览器打开公司官网，页面布局错乱。用本工具查看响应头中的 Vary: User-Agent 字段，确认服务端是否根据设备类型返回了不同的 HTML。同时检查 Content-Type 的 charset 部分，看编码是否与页面声明的 meta 标签一致。一次调试中，发现服务端对移动端返回了 gzip 压缩后的内容，但未设置 Content-Encoding 头，导致手机浏览器无法解压显示乱码。
第二节
使用指南
Getting Started使用步骤
- 1在「请求头」标签页的输入框中粘贴或键入原始 HTTP 请求头（每行一个头字段），下方表格立即解析出字段名与值
- 2切换到「响应头」标签页，粘贴服务器返回的响应头文本，表格同步展示状态行与各字段键值对
- 3点击任一字段行右侧的「复制」图标，该字段的完整键值对（如 Content-Type: text/html）自动写入剪贴板
- 4在表格顶部的搜索框输入字段名关键词（如 cache），表格实时过滤只显示匹配的请求头或响应头行
- 5展开底部「原始文本」区域，查看当前标签页所有头字段的纯文本拼接结果，支持全选复制
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: text/html | 请求头： GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: text/html 解析结果： - 请求方法：GET - 请求路径：/index.html - HTTP 版本：1.1 - Host: example.com - User-Agent: Mozilla/5.0 - Accept: text/html | 常规：标准 HTTP GET 请求，验证工具能正确解析请求行和各请求头字段，展示基本结构。 |
| HTTP/1.1 200 OK Content-Type: application/json Content-Length: 42 Cache-Control: no-cache | 响应头： HTTP/1.1 200 OK Content-Type: application/json Content-Length: 42 Cache-Control: no-cache 解析结果： - 状态码：200 - 状态描述：OK - HTTP 版本：1.1 - Content-Type: application/json - Content-Length: 42 - Cache-Control: no-cache | 常规：标准 HTTP 响应，验证工具能正确解析状态行和常见响应头字段。 |
| GET / HTTP/1.0 Host: test.com Connection: close | 请求头： GET / HTTP/1.0 Host: test.com Connection: close 解析结果： - 请求方法：GET - 请求路径：/ - HTTP 版本：1.0 - Host: test.com - Connection: close | 边界：HTTP/1.0 版本，Host 头在 1.0 中非必需，但现代工具仍会解析，验证对旧版本兼容性。 |
| POST /api/data HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary=---12345 Content-Length: 0 | 请求头： POST /api/data HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary=---12345 Content-Length: 0 解析结果： - 请求方法：POST - 请求路径：/api/data - HTTP 版本：1.1 - Host: example.com - Content-Type: multipart/form-data; boundary=---12345 - Content-Length: 0 | 边界：POST 请求且 Content-Length 为 0，验证工具能处理空正文的 POST 请求，不因长度为零而报错。 |
| GET /test HTTP/1.1 Host: example.com X-Custom-Header: value with spaces and special chars: @#$% | 请求头： GET /test HTTP/1.1 Host: example.com X-Custom-Header: value with spaces and special chars: @#$% 解析结果： - 请求方法：GET - 请求路径：/test - HTTP 版本：1.1 - Host: example.com - X-Custom-Header: value with spaces and special chars: @#$% | 易错：自定义头包含空格和特殊字符，验证工具能正确解析非标准头字段，不截断或转义。 |
| GET / HTTP/1.1 Host: example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c | 请求头： GET / HTTP/1.1 Host: example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c 解析结果： - 请求方法：GET - 请求路径：/ - HTTP 版本：1.1 - Host: example.com - Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c | 易错：Authorization 头携带长 JWT Token，验证工具能处理超长值而不截断或导致解析失败。 |
| GET / HTTP/1.1 Host: example.com Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 Cookie: sessionid=abc123; theme=dark | 请求头： GET / HTTP/1.1 Host: example.com Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 Cookie: sessionid=abc123; theme=dark 解析结果： - 请求方法：GET - 请求路径：/ - HTTP 版本：1.1 - Host: example.com - Accept-Encoding: gzip, deflate, br - Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 - Cookie: sessionid=abc123; theme=dark | 常规：包含多个值（逗号分隔）和 Cookie 头，验证工具能正确解析复合字段和 Cookie 格式。 |
常见错误对照
1.请求头名大小写混用，依赖服务端区分
✗ 错误
content-type: application/json✓ 修复
Content-Type: application/jsonHTTP 标准（RFC 7230）规定头名不区分大小写，但实际服务端实现可能按规范处理；全小写虽合法，但多数工具和文档使用首字母大写格式，统一风格可避免解析歧义。
2.请求头值包含多余空格或换行
✗ 错误
Authorization: Bearer abc123✓ 修复
Authorization: Bearer abc123HTTP 头值末尾的空格（包括换行符）会被某些服务器视为非法字符，导致 400 Bad Request。RFC 7230 要求头字段值不能包含首尾空白，建议用工具自动 trim。
3.Content-Type 缺少 charset，中文乱码
✗ 错误
Content-Type: text/plain✓ 修复
Content-Type: text/plain; charset=utf-8没有 charset 时，客户端默认用 ISO-8859-1 或系统编码解析，中文字符会变成乱码。明确指定 utf-8 可确保跨平台正确显示。
4.Cookie 头值未 URL 编码特殊字符
✗ 错误
Cookie: session_id=abc; name=张三✓ 修复
Cookie: session_id=abc; name=%E5%BC%A0%E4%B8%89Cookie 值中不允许出现分号、逗号、空格等特殊字符，RFC 6265 要求对非 ASCII 和分隔符进行 URL 编码，否则服务端解析会截断或报错。
5.User-Agent 写死旧版本，被服务端限制
✗ 错误
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)✓ 修复
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36很多现代网站会检查 User-Agent 并拒绝过时浏览器（如 IE6），返回兼容性页面或直接拦截。使用当前主流浏览器标识可避免被误判。
6.Accept 头缺失，服务端返回非期望格式
✗ 错误
（不设置 Accept 头）✓ 修复
Accept: application/json不指定 Accept 时，服务端可能返回 HTML、XML 或纯文本，而非期望的 JSON。明确声明可让服务端按需响应，减少解析错误。
7.Referer 头拼写错误（写成 Referrer）
✗ 错误
Referrer: https://example.com✓ 修复
Referer: https://example.comHTTP 标准头名是 Referer（少一个 r），这是早期规范拼写错误遗留至今。写成 Referrer 会被服务端忽略，导致防盗链或日志记录失效。
8.Cache-Control 值冲突，缓存行为混乱
✗ 错误
Cache-Control: no-cache, max-age=3600✓ 修复
Cache-Control: no-cacheno-cache 要求每次验证，而 max-age 指定缓存有效期，两者语义矛盾。多数代理会忽略 max-age 或按优先级处理，导致缓存策略不可预测。
第三节
工作原理
How It Works核心公式
Content-Length = 消息体字节数（不含空行）
变量说明
Content-LengthHTTP 消息体大小（字节）消息体字节数实际传输的 payload 字节数
示例
POST 请求体为 JSON 字符串 {"user":"alice"}，UTF-8 编码共 16 字节（不含 HTTP 头部空行）。Content-Length: 16。服务器据此读取完整 16 字节后解析请求体。
用户输入
本地解析与匹配
输出结果
第五节
常见问题
Q & A问我复制了 Chrome 开发者工具里的请求头直接粘贴过来，为什么解析出来是乱的？＋
答
开发者工具复制的原始请求头通常是多行文本（如 `Host: example.com` 换行 `User-Agent: ...`），本工具支持直接粘贴这种原始格式并自动按冒号分割。但如果复制的内容包含行号或多余空格（比如带 `1. Host:` 这种序号），会导致解析错误。建议只复制键值行，去掉序号和多余空白行。若仍乱，先粘贴到记事本检查格式是否干净。
问这个工具能帮我检查网站有没有开启 HSTS 吗？＋
答
可以。把网站返回的响应头完整粘贴到本工具，找到 `Strict-Transport-Security` 字段即可。该字段的值（如 `max-age=31536000; includeSubDomains`）会直接显示，一眼就能看出是否启用以及有效期多长。如果响应头里没有这个字段，说明该域名当前没有开启 HSTS。注意：本工具只解析你提供的原始响应头，不主动发起请求。
问为什么我抓到的请求头里 Content-Type 有两种写法？＋
答
`Content-Type` 的值确实有不同格式，常见的是 `application/json` 这类媒体类型，但有时会带上字符编码，如 `text/html; charset=utf-8`。后一种写法表示资源类型是 HTML，且编码为 UTF-8。本工具会原样展示你粘贴的值，不会做任何修改或归一化。如果你发现同一个资源在不同工具里显示不一样，通常是对方主动拼接或截断了参数，本工具只做纯展示。
问我想看一个请求的 Cookie 具体有哪些字段，这个工具能拆开吗？＋
答
本工具把 `Cookie` 整个字段值（如 `sessionid=abc123; token=xyz`）作为一个键值对展示，不会进一步按分号拆成子条目。如果你需要逐条查看每个 cookie 的名称和值，建议把 `Cookie` 字段的值单独复制出来，粘贴到文本编辑器里按 `; ` 分割。本工具的设计目标是展示所有请求/响应头的完整原文，不做深层解析，避免修改原始数据。
问我导入了抓包工具的请求头，为什么里面的中文变成了乱码？＋
答
中文在 HTTP 头中通常需要 URL 编码（如 `%E4%B8%AD%E6%96%87`），或者直接用 ASCII 字符集，某些抓包工具导出时可能没有正确处理编码。本工具只展示你粘贴的原始字节序列，不会自动解码。如果看到乱码，说明你粘贴的内容本身编码就是错误的。建议在抓包工具里检查导出设置，确保使用 UTF-8 或 ASCII 输出，而不是 GBK 等非标准编码。
问这个工具和在线 curl 转换器有什么区别？＋
答
在线 curl 转换器（如 curlconverter）是把 curl 命令解析成编程语言的 HTTP 请求代码（Python、JavaScript 等）。本工具不做任何代码生成，只做纯展示：你把请求头或响应头的原始文本粘贴进来，它按字段名排序并高亮显示每个键值对。适合快速查看原始头里有什么字段、值是什么，而不是把请求转成另一种格式。两者是互补关系，不是替代关系。
问粘贴进去的请求头太长，能不能只显示我关心的某几个字段？＋
答
当前版本不支持筛选显示。工具会把所有粘贴的键值对全部列出，按字母顺序排列。如果你只想看特定字段（比如 `Authorization` 或 `Cache-Control`），建议在浏览器里用 Ctrl+F / Cmd+F 搜索字段名。本工具未来可能会加入搜索或筛选功能，但目前请手动查找。
问这个工具支持解析 HTTP/2 的伪头部（如 :method :path）吗？＋
答
支持。HTTP/2 的伪头部（如 `:method: GET`、`:path: /api`）也是以冒号分隔的键值对，本工具会正常解析并展示。注意伪头部字段名以冒号开头，在标准 HTTP/1.x 请求中不会出现。如果你是从 HTTP/2 的抓包数据中复制的，直接粘贴即可，无需特殊处理。
问为什么同样的请求头，在不同网站查到的字段顺序不一样？＋
答
本工具默认按字段名的字母顺序排序展示，方便快速查找。原始请求头在发送时顺序由客户端（浏览器、curl 等）决定，可能任意排列。不同工具展示顺序不同是因为它们各自有排序策略。本工具选择字母排序是为了让相同字段在每次粘贴时都出现在同一位置，方便对比两个请求头的差异。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。