HTTP 头部
头部(Header)是 HTTP 报文里信息量最大的部分——起始行只说"做什么","谁在做、怎么做、做的是什么类型、要怎么处理"几乎全靠头部说明。这一章把常用头分类讲清。
1. 头部的格式
头部位于起始行之后、空行之前,每行一个:
- 格式:
名字 + 冒号 + 可选空格 + 值。空格不是必须,但写上更易读。 - 名字大小写不敏感:
Content-Type和content-type等价(实战中首字母大写是惯例)。 - 同名头可以多次出现:
Set-Cookie: a=1和Set-Cookie: b=2各占一行;也可以合并成Set-Cookie: a=1, b=2(取决于头字段定义)。 - 值里如果有非 ASCII 字符,要按 RFC 5987 编码成
UTF-8''...形式,否则浏览器解析会乱。
2. 四大类
头部按用途分四类(HTTP/1.1 起这个分类已淡化,但记忆起来方便):
- 通用头(General):请求响应都能有,如
Cache-Control、Connection、Date。 - 请求头(Request):只有客户端发,如
Host、User-Agent、Accept、Authorization。 - 响应头(Response):只有服务器发,如
Server、Set-Cookie、Location、WWW-Authenticate。 - 实体头(Entity / Representation):描述消息体,如
Content-Type、Content-Length、Content-Encoding。
3. 通用头
# 通用头 (请求和响应都能出现)
Cache-Control: no-cache # 缓存策略
Connection: keep-alive # 保持 TCP 连接
Date: Tue, 05 Aug 2026 08:30:00 GMT # 报文时间
Transfer-Encoding: chunked # 传输编码 (分块)4. 请求头(最重要)
# 常用请求头
Host: api.example.com # 必填!目标主机 (虚拟主机靠它区分)
User-Agent: Mozilla/5.0 (...) # 客户端身份 (浏览器/设备/curl)
Accept: application/json # 想要什么类型
Accept-Language: zh-CN,zh;q=0.9 # 想要什么语言
Accept-Encoding: gzip, br # 接受什么压缩算法
Authorization: Bearer <token> # 认证凭证
Cookie: sessionid=abc123 # 携带的 Cookie
Referer: https://www.example.com/ # 从哪个页面跳来的
Origin: https://www.example.com # 来源 (CORS 用)
Content-Type: application/json # 请求体类型 (有 body 时必填)
Content-Length: 36 # 请求体字节数
If-None-Match: "abc" # 缓存校验 (配合 304)几个高频点:
- Host:HTTP/1.1 唯一强制要求的请求头。一台 IP 上托管多个域名(虚拟主机)就是靠它区分。
- User-Agent:客户端身份。可用于统计、反爬(虽然不可靠)。生产别依赖它做安全判断,随便伪造。
- Accept 系列:内容协商。告诉服务器"我能懂什么"。服务器据此选最合适的格式返回。
- Authorization:认证凭证。详见下面专门一节。
- Referer:来源页 URL。统计流量来源、防盗链都靠它(注意拼写是历史遗留的少一个 r)。
- Origin:仅协议+域名+端口,CORS 专用。和 Referer 区别:Origin 不含路径,更注重隐私。
5. 响应头
# 常用响应头
Server: nginx/1.25.0 # 服务器软件 (生产建议隐藏,防指纹)
Date: Tue, 05 Aug 2026 08:30:00 GMT # 响应时间
Content-Type: application/json # 响应体类型
Content-Length: 47 # 响应体字节数
Content-Encoding: gzip # 响应体已用 gzip 压缩
Cache-Control: max-age=600 # 浏览器可缓存 600 秒
ETag: "abc123" # 资源指纹 (配合 304)
Last-Modified: Mon, 04 Aug 2025 ... # 最后修改时间
Location: /users/42 # 重定向目标 (3xx) 或新建资源 URL (201)
Set-Cookie: sessionid=xyz; HttpOnly # 让浏览器存 Cookie
WWW-Authenticate: Bearer # 401 时告诉客户端怎么认证
Access-Control-Allow-Origin: * # CORS 允许跨域几个高频点:
- Server:服务器软件。生产环境建议隐藏或改写,减少攻击面(黑客据此找已知漏洞)。
- Set-Cookie:服务器让浏览器存 Cookie,详见第 7 篇。
- Location:3xx 重定向的目标 URL、201 Created 的新资源 URL。
- ETag / Last-Modified:缓存校验字段,配合 304 用。
- WWW-Authenticate:401 时告诉客户端"应该用什么认证方案"。
6. Authorization:认证凭证
# Authorization 头几种常见方案
Authorization: Basic dXNlcjpwYXNz # Basic Auth (user:pass 的 Base64)
Authorization: Bearer eyJhbGciOi... # JWT Token (OAuth2 常用)
Authorization: ApiKey abc123 # API Key (各 RPC 框架自定义)
# 警告: Basic Auth 的 Base64 不是加密!抓包就能解出明文密码,
# 必须配合 HTTPS 使用实战中 90% 的现代 API 用 Bearer Token(JWT 是其常见格式)。
7. 缓存头:Cache-Control
这是性能优化里最重要的头。和 ETag、Last-Modified、If-None-Match、If-Modified-Since 配合工作。
# Cache-Control 是 HTTP/1.1 缓存指令,功能最强
Cache-Control: max-age=600 # 浏览器/CDN 缓存 600 秒
Cache-Control: no-cache # 每次都要去服务器问"变没变" (可 304)
Cache-Control: no-store # 绝对不缓存 (敏感数据/银行)
Cache-Control: public # 浏览器和 CDN 都能缓存
Cache-Control: private # 只让浏览器缓存,CDN 不许
Cache-Control: immutable # 永远不会变,过期前都不用问
# 配合 ETag / If-None-Match 实现 304:
# 响应: ETag: "abc123"
# 下次请求: If-None-Match: "abc123"
# 服务器没变就回 304,变了回 200 + 新 body8. CORS 头:跨域必备
浏览器同源策略默认禁止跨域请求(协议/域名/端口任一不同即跨域)。CORS(跨源资源共享)通过一组头让服务器显式允许:
# CORS 跨域相关头 (浏览器才有, curl 不受 CORS 限制)
# 请求方 (浏览器自动加):
Origin: https://www.example.com
# 响应方 (服务器必须显式允许):
Access-Control-Allow-Origin: https://www.example.com # 允许这个域名
Access-Control-Allow-Origin: * # 允许任何域名 (公开 API)
Access-Control-Allow-Methods: GET, POST, PUT, DELETE # 允许的方法
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true # 允许带 Cookie
Access-Control-Max-Age: 86400 # 预检结果缓存 1 天注意:
- CORS 是浏览器行为,curl/Postman 不受影响——所以"接口用 curl 没问题、前端报跨域错误"很常见。
- 带 Cookie 的跨域:
Access-Control-Allow-Origin不能写*,必须写具体域名 +Access-Control-Allow-Credentials: true。 - 非简单请求(如带
Authorization头、Content-Type: application/json)会先发 OPTIONS 预检。
9. 自定义头
# 自定义头: 通常加 X- 前缀 (历史惯例,新规范不再强制)
X-Request-Id: 9f3a2b1c-... # 链路追踪 ID
X-RateLimit-Limit: 100 # 限流配额
X-RateLimit-Remaining: 87
X-Forwarded-For: 1.2.3.4 # 反向代理记录真实客户端 IP
X-Forwarded-Proto: https # 反代记录原始协议
# 现代风格:直接用业务名,不加 X- (例如 Github-API 把版本写在头里)
Github-Version: 2022-11-28命名约定(RFC 6648 之后不再强制):
- 历史惯例:自定义头加
X-前缀。 - 新规范:直接用业务名(如
Request-Id、Trace-Id)。 - 避免和别人冲突:可以用项目名作前缀(如
Acme-Trace-Id)。
10. 反向代理常用头
Nginx/CDN/负载均衡器会注入这些头给后端,让后端知道真实客户端信息:
X-Forwarded-For:客户端真实 IP 链路(每一跳追加一个)。X-Forwarded-Proto:客户端原始协议(http 还是 https)。X-Real-IP:客户端真实 IP(Nginx 特有,单值)。Forwarded:标准化版本(RFC 7239),把上面这些合在一起。
注意:客户端可以伪造这些头!后端取信任 IP 时一定要确认"上一跳是不是可信代理"。
11. 安全相关头(运维加,开发者了解)
Strict-Transport-Security:强制 HTTPS(HSTS)。Content-Security-Policy:CSP,限制脚本来源,防 XSS。X-Content-Type-Options: nosniff:禁止浏览器猜 MIME 类型。X-Frame-Options: DENY:禁止被嵌入 iframe,防点击劫持。Referrer-Policy:控制 Referer 暴露多少。
小结
记住几个高频头就够日常用了:Host Content-Type Content-Length Authorization Cache-Control User-Agent Accept Cookie Set-Cookie Location ETag。CORS 头是前后端分离的必修内容。
← 上一篇 HTTP 状态码
下一篇 请求体与 Content-Type →