在HTTP协议的交互过程中，请求头（Request Header）就像是客户端与服务器之间的“沟通说明书”——它承载着客户端的身份信息、请求偏好、数据格式等关键内容，服务器通过解析请求头，才能准确理解客户端的需求，进而返回合适的响应。对于前端开发者、后端工程师甚至测试人员而言，熟练掌握请求头的核心字段与使用场景，是排查接口问题、优化交互体验、保障接口安全的基础。

本文将从基础概念出发，拆解请求头的核心分类与常用字段，结合实际开发场景（如接口调试、跨域、安全防护）讲解其应用，最后梳理常见问题与排查技巧，助力大家真正吃透HTTP请求头，高效应对开发中的各类问题。

一、HTTP请求头基础认知

1. 什么是HTTP请求头？

HTTP请求头是HTTP请求报文的组成部分之一，位于请求行（Request Line）之后、请求体（Request Body）之前，由一系列“键值对”（Key: Value）组成，每个键值对代表一项具体的请求信息。

一个完整的HTTP请求报文结构如下：

请求行（Method URL HTTP版本） 
请求头（多个Key: Value键值对，每行一个） 
空行（分隔请求头与请求体） 
请求体（可选，携带POST/PUT等请求的参数数据）

示例（Chrome浏览器发起的GET请求头）：

GET /api/user HTTP/1.1 
Host: www.example.com 
Connection: keep-alive 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 
Accept-Encoding: gzip, deflate, br 
Accept-Language: zh-CN,zh;q=0.9

2. 请求头的核心作用

• 身份标识：告诉服务器客户端的类型（浏览器、APP、爬虫）、操作系统、设备信息等；

• 请求偏好：指定客户端可接受的响应数据格式、编码方式、语言等；

• 连接控制：控制HTTP连接的生命周期（如长连接、短连接）；

• 安全验证：携带身份凭证（如Cookie、Token），实现用户认证与授权；

• 缓存控制：告知服务器客户端的缓存策略，优化请求性能；

• 跨域配置：携带跨域请求相关的信息（如Origin），配合服务器实现跨域资源共享（CORS）。

二、核心请求头字段详解（必学）

请求头字段种类繁多，部分是HTTP标准定义的通用字段，部分是业务自定义字段。下面重点讲解开发中最常用、出现频率最高的核心字段，按功能分类梳理，方便记忆与应用。

1. 身份与客户端信息相关字段

这类字段主要用于服务器识别客户端的“身份”，常用于兼容性适配、数据统计、爬虫识别等场景。

（1）User-Agent（UA）

最常用的字段之一，全称“用户代理”，用于标识发起请求的客户端类型、版本、操作系统等信息。服务器可通过UA判断请求来自浏览器、APP、爬虫，进而返回适配的内容。

格式示例：

// Chrome浏览器（Windows 10）
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 

// 手机端Safari（iOS） 
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1 

// 爬虫（百度蜘蛛） 
User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)

关键拆解（以Chrome/91.0.4472.124为例）：

• Chrome/91.0.4472.124：浏览器类型为Chrome，版本号为91.0.4472.124（主版本.次版本.内部构建号.补丁版本）；

• Windows NT 10.0; Win64; x64：操作系统为Windows 10，64位；

• AppleWebKit/537.36：浏览器内核（Chrome基于WebKit内核开发）；

• Safari/537.36：兼容标识（为了兼容部分只识别Safari内核的服务器）。

实际应用：

• 兼容性适配：服务器判断客户端浏览器版本，对低版本Chrome（如Chrome 58）返回兼容的网页代码；

• 爬虫拦截：禁止非浏览器UA（如恶意爬虫）访问，保护网站资源；

• 数据统计：统计网站访问用户的浏览器、操作系统分布，辅助产品优化。

（2）Referer

标识当前请求的“来源页面”，即客户端是从哪个URL跳转过来发起当前请求的。常用于防盗链、溯源排查、权限校验。

格式示例：

Referer: https://www.example.com/login

注意点：

• 直接在地址栏输入URL发起的请求，Referer为空；

• 从HTTPS页面跳转至HTTP页面，Referer会被隐藏（出于安全考虑）；

• 防盗链场景：图片、视频等资源服务器，可通过Referer判断请求是否来自自身域名，拒绝外部域名的请求。

2. 连接与传输相关字段

这类字段用于控制HTTP连接的传输方式、连接生命周期，优化请求性能。

（1）Host

必选字段（HTTP/1.1要求），用于指定服务器的域名或IP地址，以及端口号（可选，默认80端口）。核心作用是：当一台服务器托管多个域名时，服务器通过Host字段判断客户端请求的是哪个域名对应的服务。

格式示例：

// 默认80端口（HTTP） 
Host: www.example.com 

// 自定义端口（如8080） 
Host: api.example.com:8080

注意：如果请求中缺少Host字段，服务器会返回400 Bad Request（错误请求）。

（2）Connection

控制HTTP连接的类型，主要有两个值：

• keep-alive（长连接）：默认值，请求完成后，连接不会立即关闭，后续请求可复用该连接，减少TCP连接建立/关闭的开销，提升性能；

• close（短连接）：请求完成后，立即关闭连接，适用于单次请求、并发量极低的场景。

格式示例：

Connection: keep-alive

（3）Accept-Encoding

指定客户端可接受的响应数据编码方式，服务器可根据该字段对响应数据进行压缩，减少传输体积，提升加载速度。

常用值：

• gzip：最常用的压缩方式，压缩率高；

• deflate：另一种常用压缩方式，兼容性较好；

• br：谷歌推出的压缩方式，压缩率比gzip更高，但兼容性稍差；

• *：接受所有编码方式。

格式示例：

Accept-Encoding: gzip, deflate, br

3. 数据格式与偏好相关字段

这类字段用于告知服务器，客户端希望接收的数据格式、语言等，实现“按需返回”。

（1）Accept

指定客户端可接受的响应数据类型（MIME类型），服务器根据该字段返回对应的格式，若无法满足，返回406 Not Acceptable（无法接受）。

常用值：

• text/html：HTML页面（浏览器默认优先接受）；

• application/json：JSON格式（接口开发中最常用）；

• application/xml：XML格式；

• image/*：所有图片格式；

• */*：接受所有类型。

格式示例（接口请求常用）：

Accept: application/json, text/plain, */*

（2）Content-Type

非常关键的字段，用于指定请求体的数据格式（仅在POST、PUT、PATCH等有请求体的请求中存在）。服务器通过该字段解析请求体参数，若格式不匹配，会导致参数解析失败。

开发中最常用的3个值：

• application/x-www-form-urlencoded：默认的表单提交格式，参数以key=value&key=value的形式拼接，适用于简单表单提交；

• multipart/form-data：用于文件上传（如图片、文档），同时可携带普通表单参数，请求体中会分隔不同的参数和文件；

• application/json：JSON格式的请求体，适用于接口请求（前后端分离项目的主流格式）。

格式示例：

// JSON格式（前后端分离常用） 
Content-Type: application/json 

// 表单提交格式 
Content-Type: application/x-www-form-urlencoded 

// 文件上传格式 
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

（3）Accept-Language

指定客户端可接受的自然语言（如中文、英文），服务器可根据该字段返回对应语言的响应内容，实现多语言适配。

格式示例：

// 优先接受中文（中国大陆），其次接受中文，最后接受所有语言 
Accept-Language: zh-CN,zh;q=0.9,*;q=0.8

说明：q表示权重（0~1），权重越高，优先级越高，默认权重为1。

4. 安全与认证相关字段

这类字段用于实现用户认证、防止CSRF攻击、保障请求安全，是接口安全的核心。

（1）Cookie

用于携带客户端的Cookie信息（如用户登录凭证、会话ID），是实现会话保持、用户认证的常用方式。Cookie由服务器通过响应头（Set-Cookie）设置，客户端后续请求会自动携带对应的Cookie。

格式示例：

Cookie: userId=123456; token=abcdef123456; rememberMe=true

注意：Cookie受域名、路径、过期时间限制，且存在跨域限制（默认不允许跨域携带）。

（2）Authorization

用于携带身份认证凭证，替代Cookie实现无状态认证（如JWT认证），是前后端分离项目中最常用的认证方式。

常用格式（JWT认证）：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsIm5hbWUiOiJhZG1pbiIsImV4cCI6MTY5NzAwMDAwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

说明：Bearer后面跟的是JWT令牌，服务器解析令牌即可完成用户认证，无需存储会话信息（无状态）。

（3）Origin

用于跨域请求中，标识当前请求的来源域名（协议+域名+端口），服务器通过该字段判断是否允许跨域请求（CORS跨域核心字段）。

格式示例：

Origin: https://www.example.com

注意：Origin与Referer的区别——Origin只包含协议+域名+端口，不包含路径；Referer包含完整的来源URL（协议+域名+端口+路径）。

三、实际开发场景中的请求头应用

掌握了核心字段后，结合实际开发场景，才能真正发挥请求头的作用。下面梳理3个最常见的开发场景，讲解请求头的具体应用。

场景1：接口调试（Postman/浏览器开发者工具）

日常接口调试中，我们经常需要手动设置请求头，模拟不同场景的请求：

• 模拟不同浏览器：修改User-Agent字段，模拟Chrome、Safari、手机浏览器的请求；

• 携带认证凭证：设置Authorization字段（JWT令牌），访问需要登录的接口；

• 指定请求格式：设置Content-Type为application/json，提交JSON格式的参数；

• 模拟跨域请求：设置Origin字段，模拟前端跨域发起的请求，排查跨域问题。

技巧：Chrome开发者工具（F12）→ Network → 选中请求 → Headers → Request Headers，可查看当前请求的所有请求头，也可通过Edit and Resend功能修改请求头，重新发起请求。

场景2：跨域资源共享（CORS）

前端跨域请求时，浏览器会自动添加Origin请求头，服务器需要解析该字段，返回对应的响应头（如Access-Control-Allow-Origin），才能允许跨域请求。

示例（前端跨域请求的请求头）：

GET /api/user HTTP/1.1 
Host: api.example.com 
Origin: https://www.frontend.com // 前端域名（跨域来源）
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124 Safari/537.36 
Accept: application/json

服务器判断Origin是否在允许的跨域列表中，若允许，返回响应头Access-Control-Allow-Origin: https://www.frontend.com（前端域名），前端才能正常接收响应。

场景3：接口安全防护

利用请求头字段，可实现简单的接口安全防护，防止恶意请求：

• 拦截恶意爬虫：校验User-Agent字段，拒绝非浏览器、非合法APP的UA请求；

• 防止CSRF攻击：校验Referer/Origin字段，确保请求来自自身域名；

• 身份认证：通过Authorization/Cookie字段，校验用户身份，拒绝未登录的请求；

• 限制请求来源：通过Host字段，拒绝非指定域名的请求（防止域名劫持）。

四、常见问题与排查技巧

开发中，很多接口问题都与请求头相关，下面梳理4个最常见的问题，给出排查思路和解决方案。

问题1：接口返回400 Bad Request（错误请求）

常见原因：

• 缺少Host字段（HTTP/1.1要求必传）；

• 请求头格式错误（如键值对缺少冒号、拼写错误）；

• Content-Type与请求体格式不匹配（如设置为application/json，但请求体是表单格式）。

排查技巧：检查请求头是否完整、格式是否正确，重点核对Host、Content-Type字段。

问题2：接口返回401 Unauthorized（未授权）

常见原因：

• 未携带认证凭证（Authorization/Cookie字段缺失）；

• 认证凭证过期（如JWT令牌过期、Cookie过期）；

• 认证凭证格式错误（如Authorization字段缺少Bearer前缀）。

排查技巧：检查请求头中是否携带正确的认证凭证，核对凭证格式和有效性。

问题3：跨域请求失败（浏览器报CORS错误）

常见原因：

• 请求头中Origin字段对应的域名，未在服务器的跨域允许列表中；

• 跨域请求携带了Cookie，但未设置withCredentials: true（前端），且服务器未返回Access-Control-Allow-Credentials: true；

• 请求头中包含自定义字段（如X-Token），服务器未返回Access-Control-Allow-Headers允许该字段。

排查技巧：查看请求头中的Origin字段，确认服务器是否允许该域名跨域；检查前端是否设置withCredentials，服务器是否返回对应的跨域响应头。

问题4：接口返回406 Not Acceptable（无法接受）

常见原因：请求头中Accept字段指定的响应格式，服务器无法提供（如客户端要求application/json，服务器返回text/html）。

排查技巧：检查Accept字段的设置，确保其与服务器支持的响应格式一致。

五、总结

HTTP请求头是客户端与服务器沟通的核心桥梁，其核心价值在于“传递请求信息、实现按需适配、保障请求安全”。本文梳理了请求头的基础概念、核心字段、实际应用及常见问题，重点讲解了User-Agent、Content-Type、Authorization、Origin等高频字段的用法——这些字段贯穿了接口开发、调试、安全防护的全流程，是每个开发者必须掌握的基础。

在实际开发中，建议多利用浏览器开发者工具、Postman等工具，查看和调试请求头，积累排查问题的经验。同时，根据业务需求，合理设置请求头字段（如自定义认证字段、跨域相关字段），既能提升接口性能，也能增强接口安全性。