HTTP / HTTPS 请求头详解：从结构到实际应用，一次讲清楚

前后端联调时，经常遇到接口报 401 未授权或 404 找不到资源。排查了半天发现是请求头里没带 Token，或者 Content-Type 设错了。请求头是 HTTP 通信中最核心的组成部分之一，但很多人对它的理解停留在"复制粘贴"阶段。本文从结构出发，结合实际案例，帮你彻底掌握 HTTP 请求头。

本文仅作技术分享，不包含任何付费或商业推广信息。部分工具的列举仅为说明技术方案，不代表任何立场。

一、请求头是什么？

HTTP 请求头是客户端在发送 HTTP 请求时附带的元数据（metadata），用于告诉服务器：客户端的身份、期望的响应格式、支持的数据压缩方式、以及附加的认证信息等。

一个典型的 HTTP 请求头结构：

http 复制代码

GET /api/v1/video/123 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json
Content-Length: 0

每一行都是一个键值对，用冒号分隔。这些信息对服务器理解客户端需求至关重要。

二、常见请求头分类与详解

2.1 通用请求头（General Headers）

这类头部不区分请求或响应，而是描述消息本身。

头部名称	作用	示例
Cache-Control	缓存策略	Cache-Control: no-cache
Connection	连接管理	Connection: keep-alive 或 close
Date	消息时间戳	Date: Tue, 25 Jun 2024 03:00:00 GMT
Pragma	兼容旧版缓存（HTTP/1.0）	Pragma: no-cache

2.2 请求头（Request Headers）

这类头部专门用于请求，描述客户端的特征和偏好。

Host（必需）

指定要访问的服务器域名和端口号。HTTP/1.1 协议要求必须包含此头部，用于支持虚拟主机。

text 复制代码

Host: www.example.com:8080

User-Agent（标识客户端）

标识客户端类型（浏览器、爬虫、API 客户端、移动应用等）。服务器可根据 UA 返回不同版本的内容。

text 复制代码

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Accept（期望的响应格式）

告诉服务器客户端可以接受的 MIME 类型，多个类型用逗号分隔，可用 q 参数指定优先级（0-1）。

text 复制代码

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Encoding（支持的压缩算法）

告诉服务器客户端支持的编码压缩方式（如 gzip、br），可显著减少传输数据量。

text 复制代码

Accept-Encoding: gzip, deflate, br

Accept-Language（期望的语言）

告诉服务器客户端偏好的自然语言（用于内容本地化）。

text 复制代码

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Referer（来源页面）

告诉服务器当前请求是从哪个页面跳转过来的，常用于防盗链和统计分析。

text 复制代码

Referer: https://www.google.com/search?q=video+codec

Authorization（认证凭证）

携带用户身份凭证（如 JWT Token、Basic Auth、API Key）。

text 复制代码

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Cookie（会话状态）

携带服务器之前通过 Set-Cookie 设置的会话标识。

text 复制代码

Cookie: sessionId=abc123; userId=1001

Content-Type（请求体的格式）

当请求包含 Body（如 POST/PUT 方法）时，此头部指定请求体的数据格式。

text 复制代码

Content-Type: application/json
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Type: application/x-www-form-urlencoded

Content-Length（请求体大小）

请求体的字节长度，用于服务器校验数据完整性。

text 复制代码

Content-Length: 348
Range（范围请求）
用于请求资源的部分内容，常用于视频/音频的断点续传或拖动播放。

text
Range: bytes=0-1023

2.3 条件请求头（Conditional Headers）

这类头部用于验证资源是否发生变化，可节省带宽。

头部名称	作用	示例
If-Match	仅当 ETag 匹配时才执行操作	If-Match: "abc123"
If-None-Match	仅当 ETag 不匹配时才返回内容	If-None-Match: "abc123"
If-Modified-Since	仅当资源在此时间后修改过才返回内容	If-Modified-Since: Tue, 25 Jun 2024 03:00:00 GMT
If-Range	范围请求的条件版本	If-Range: "abc123"

三、请求头在视频技术中的应用

3.1 视频播放中的断点续传（Range 请求）

浏览器在播放长视频时，并不是一次性下载整个文件，而是通过 Range 请求逐步下载片段。当用户拖动进度条时，浏览器会发送新的 Range 请求获取目标时间段的字节数据。

text 复制代码

GET /video/sample.mp4 HTTP/1.1
Host: video.example.com
Range: bytes=1048576-2097151

服务器返回 206 Partial Content 状态码，以及对应的字节片段。

3.2 防盗链与 Referer

视频平台常常通过 Referer 头部实现防盗链：只允许来自本站页面的视频请求，外站直接访问视频链接会被拒绝。

text 复制代码

Referer: https://www.example.com/video/123

如果 Referer 缺失或来自非白名单站点，服务器返回 403 Forbidden。

3.3 自适应码率切换

HLS / DASH 等流媒体协议中，客户端通过请求头中的 Accept-Encoding 和 Accept-Language 向服务器传递设备和网络信息，服务器据此决定推送何种码率的视频片段。

四、实战排查：请求头导致接口报错的几个典型案例

案例1：401 Unauthorized（未认证）

现象：调用一个需要登录的接口，返回 401。
排查：检查 Authorization 头部是否缺失或格式错误。常见错误：
写成 Authorization: Token xxx 但服务器要求 Authorization: Bearer xxx
Token 过期或格式不正确

正确示例：

http 复制代码

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

案例2：415 Unsupported Media Type（不支持的媒体类型）

现象：POST 请求返回 415。
排查：检查 Content-Type 是否与请求体实际格式一致。

错误场景：

请求体是 JSON 格式，但 Content-Type 没设（默认 text/plain），或设成了 application/x-www-form-urlencoded
服务器只接受 application/json，但客户端发送了 text/xml

正确示例：

http 复制代码

POST /api/video/upload HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"title": "视频标题", "url": "https://..."}

案例3：视频无法拖放播放

现象：视频可以播放但无法拖动进度条，或拖动后回到原点。

排查：

服务器是否支持 Range 请求。检查响应头是否有 Accept-Ranges: bytes。
客户端是否发送了正确的 Range 头部。如果有，检查服务端是否返回 206 Partial Content。

正确示例（服务端响应头）：

http 复制代码

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 1048576
Content-Range: bytes 0-1048575/10485760

五、命令行工具：用 curl 查看和发送自定义请求头

5.1 查看目标服务器的响应头（用于排查）

bash 复制代码

curl -I https://example.com/video/sample.mp4

5.2 发送带自定义请求头的请求

bash 复制代码

# 带 Bearer Token + JSON 请求体
curl -X POST https://api.example.com/video/upload \
  -H "Authorization: Bearer your_token" \
  -H "Content-Type: application/json" \
  -d '{"title":"我的视频","url":"https://..."}'

5.3 只查看请求头（不下载内容）

bash 复制代码

curl --head https://example.com/video/sample.mp4

六、附：常用工具推荐

日常调试请求头时，以下几个方案比较实用：

浏览器开发者工具（F12→Network）：最直接，可查看请求头、响应头。
Postman / Insomnia：可视化 API 测试，方便管理不同环境。
VidDown 的 API 测试工具：支持自定义请求头和方法，适合快速验证。感兴趣- 的读者可自行了解，通常搜索 API 测试工具能找到同类服务。

在线 JSON 格式化工具：用于解析 API 返回的 JSON 数据，方便阅读。

七、总结

HTTP/HTTPS 请求头是 Web 通信的"说明书"------它告诉服务器客户端的身份、能力和需求，也决定了服务器如何响应。理解每个头部字段的含义和用途，可以快速定位各类接口错误，优化视频传输体验，并在日常开发中更加高效。

希望这篇文章能帮你建立完整的请求头知识体系。如果下次联调时遇到 401 或 415 报错，不妨先检查一下请求头是否配置正确。