什么是 HTTP 请求头？2025 年指南及示例

核心要点：

• HTTP 请求头是网络通信中的元数据，以键值对形式随每次 HTTP 请求和响应一同发送，用于说明应如何处理该请求或响应。
• 它们使网络客户端与服务器能够交换内容类型、缓存、身份验证等关键信息，而不仅限于主体数据本身，从而确保传输和显示正确的内容。
• 正确使用请求头可以通过缓存与压缩提升性能、通过针对 HTTPS 与内容策略的专用响应头增强安全防护，并有助于调试和 API 开发。
• 开发者可使用浏览器开发者工具、cURL 等工具或 API 客户端查看和修改请求头。了解 HTTP 请求头是什么以及它们的工作原理，对网络爬取、API 集成和构建安全的 Web 应用至关重要。

HTTP 请求头是 HTTP 协议的核心组成部分，由随每次请求和响应一同传输的附加信息构成。它们本质上是以键值对格式（如 Header-Name: header value）书写的文本行，包含在 HTTP 消息的请求头部分中。

这些请求头使客户端和服务器能够传递关于请求或响应的指令或元数据。换言之，请求头是描述或指导如何处理 HTTP 消息中主体数据的幕后数据。

为什么 HTTP 请求头很重要

请求头承担多种作用，促进网络浏览器（或其他客户端）与服务器之间的通信，包括定义缓存行为、实现身份验证、管理会话状态以及执行内容协商等功能。

借助请求头，客户端与服务器可以协商数据格式（如 HTML、JSON 等）、通过缓存机制提升效率、携带凭证或令牌以实现安全访问，并确保通过 HTTPS 进行加密且经过身份验证的响应。这使得请求头在日常浏览和 API 交互中都至关重要。

由于请求头承载着如此重要的元数据，它们在多种场景中都发挥着关键作用：

• Web API

调用 REST API 时，通常会包含 Content-Type（例如告知服务器您发送的是 JSON 数据）或 Authorization（用于传递 API 密钥或令牌）等请求头。服务器的响应头中可能包含速率限制信息或 CORS 权限。如果没有请求头，可靠的 API 通信将难以实现。

• 浏览器

浏览器在每次页面请求中都会自动发送大量请求头字段（如 User-Agent、Accept 等），服务器则返回响应头（如 Cookie、内容类型、缓存指令）。这些请求头确保 HTTP 请求得到正确处理（例如服务器能够知晓您偏好的语言或内容类型），并确保浏览器能够正确渲染 HTTP 响应。

• 调试与开发

检查 HTTP 请求头是一种常见的调试手段。如果网页出现异常（例如因跨域问题导致字体无法加载），开发者会检查 Access-Control-Allow-Origin 等请求头和内容类型。浏览器开发者工具或代理监控工具等可用于查看请求头以排查此类错误。简而言之，当网络通信出现问题时，请求头往往是最先需要检查的地方。

总之，HTTP 请求头之所以重要，是因为它们使客户端与服务器之间的通信不仅限于原始数据传输，而能够实现更丰富、更可控的交流。它们确保双方理解上下文（数据格式、缓存方式、安全处理方式等），从而让网络得以顺畅运行。

HTTP 请求头的工作原理

HTTP 是一种请求-响应协议：客户端（如浏览器）发送 HTTP 请求，网络服务器返回 HTTP 响应。请求头是这一交互过程中不可或缺的一部分。在一条 HTTP 消息（无论是请求还是响应）中，整体格式为：起始行，随后是一行或多行请求头，接着是一个空行，最后是消息主体（如果存在）。

每一行请求头由不区分大小写的名称、一个冒号 : 以及对应的值组成。例如，一个请求头可能形如 Content-Type: text/html。请求头名称不区分大小写（因此 Content-Type 与 content-type 被视为相同），但按照惯例通常会首字母大写。

在 HTTP/2 及更高版本中，协议会自动以小写形式发送请求头名称，但语义保持不变。可以同时存在多个请求头，每个各占一行。

请求头之后的空行标志着请求头部分的结束，随后是消息主体（负载）内容。消息主体是实际传输的内容（如页面的 HTML、JSON 数据、图片字节等），而请求头则用于描述或影响这些内容。

下面用一个简单的示例来说明带有请求头的 HTTP 请求与响应：

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/117.0.0.1 Safari/537.36
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9

这是浏览器尝试从 example.com 获取 /index.html 时发出的 HTTP 请求，以请求行（GET /index.html HTTP/1.1）开头，随后包含若干请求头：

• Host: example.com 指定请求所针对的主机（域名）。

• User-Agent: Mozilla/5.0 (Windows NT 10.0; ... Safari/537.36 用于标识客户端软件及其版本（此处为浏览器与操作系统的详细信息）。

• Accept: text/html,... 表示客户端可接受的内容类型（HTML、XHTML 等）。

• Accept-Language: en-US,en;q=0.9 表示客户端偏好的语言（此处为美式英语）。

请求头之后是一个空行。（在本示例中，由于 GET 请求通常不携带消息主体，因此没有消息体。）

服务器的 HTTP 响应则可能形如下方所示：

HTTP/1.1 200 OK
Date: Fri, 24 Oct 2025 16:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 3472
Connection: keep-alive
Set-Cookie: sessionId=abc123; HttpOnly; Path=/

<html>
  ... [HTML content of the page] ...
</html>

响应的起始行为 HTTP/1.1 200 OK（表示请求成功，状态码为 200），随后是以下响应头：

• Date: Fri, 24 Oct 2025 16:00:00 GMT —— 服务器发送该响应的日期和时间。

• Content-Type: text/html; charset=UTF-8 —— 响应主体的媒体类型（此处为采用 UTF-8 编码的 HTML 文本）。

• Content-Length: 3472 —— 消息主体的字节大小（此处 HTML 页面为 3472 字节，即响应负载的长度）。

• Connection: keep-alive —— 表示连接应保持打开状态（这样客户端无需重新建立连接，即可在同一条底层传输连接上发出后续请求）。

• Set-Cookie: sessionId=abc123; HttpOnly; Path=/ —— 服务器在客户端浏览器中设置的 Cookie（用于会话跟踪）。

在这些响应头之后是一个空行，随后才是该页面实际的 HTML 内容，位于消息主体中。浏览器将依据请求头信息来判断如何解析主体中的字节（本例中借助 Content-Type 字段判断其为 HTML 文本）、主体的长度，以及如何处理连接复用。

请注意，部分请求头是请求头（由客户端发送至服务器），另一些则是响应头（由服务器发送至客户端）。

某些请求头（如 Content-Type）既可出现在请求中，也可出现在响应中（例如，客户端发送 POST 请求时会包含 Content-Type 和 Content-Length 来描述其请求主体）。另一些则仅用于特定方向（例如 Set-Cookie 仅出现在响应中，Authorization 仅出现在请求中）。

此外值得注意的是，某些请求头属于端到端类型（代理必须将其转发给最终接收方），而另一些则属于逐跳类型（仅对单条底层传输连接有效，不会被中介转发）。

例如，Connection 请求头就是逐跳类型：它控制是否保持当前 TCP 连接处于活动状态，代理会消耗这一字段而不是将其转发出去，从而避免代理无意中将连接保持在错误的目标上。

实际上，这意味着 Connection 请求头中列出的字段（如 Keep-Alive 或特定于代理的指令）会被代理移除或处理，而端到端请求头（如 Content-Type 或 Cache-Control）则会原样传递给最终接收方。

理解 HTTP 请求头的结构和传输方式，有助于开发者更高效地使用 HTTP。无论是在调试 API 调用、配置缓存，还是排查网页行为异常，查看请求头往往能够揭示幕后发生的情况。

通用 HTTP 请求头

通用请求头同时适用于请求和响应，提供通用信息或控制连接的相关方面，并不专属于请求或响应中的任意一方。在较早的 HTTP 规范中，这类请求头被称为“通用请求头字段”。以下是几个重要的通用请求头：

• Cache-Control

该请求头包含中介（如代理）和浏览器应遵循的缓存指令，在请求和响应中均可使用，用于控制缓存的执行方式。

• Date

Date 请求头表示消息由服务器（或客户端）发出的日期和时间。在响应中，它表示服务器生成该响应时的时间戳。

• Connection

该请求头用于控制当前请求/响应完成后网络连接是否保持打开状态，常见取值为 keep-alive 或 close。

这些通用请求头确保 HTTP 请求与 HTTP 响应消息能够以一致的方式管理缓存和连接行为等基本方面。

请求头

请求头是客户端（浏览器或其他 HTTP 客户端）随 HTTP 请求发送的字段，用于提供关于其需求或自身信息的更多细节，向服务器说明请求的上下文。以下是一些常见的请求头字段：

• Host

该请求头用于指定请求发送目标服务器的主机（域名或 IP），并可选择性地指定端口号，例如 Host: example.com。几乎所有 HTTP/1.1 请求中都必须包含 Host 请求头。

• User-Agent

该请求头用于标识发起请求的客户端软件，通常包含应用名称、版本号、操作系统等信息。例如，浏览器的 User-Agent 字符串可能是 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/117.0.0.1 Safari/537.36"。

• Accept

Accept 请求头按优先顺序告知服务器客户端可以处理的内容类型，例如：Accept: text/html, application/xhtml+xml, application/xml;q=0.9, /;q=0.8，表示“优先选择 HTML 或 XHTML，但必要时也可以接受 XML 或其他任意类型”。

• Accept-Language

该请求头指定响应内容的首选语言，以便服务器选择合适的区域设置，例如：Accept-Language: en-US,en;q=0.9,fr;q=0.8 表示用户首选美式英语，但在一定程度上也能接受通用英语或法语。

• Authorization

Authorization 请求头包含用于向服务器验证客户端身份的凭证，客户端借助它证明自己的身份或访问受保护资源的权限，常见于需要登录的网站或 API。例如，Authorization: Basic dXNlcjpwYXNzd29yZA== 以 base64 编码方式携带用户名和密码，用于 HTTP Basic 认证；而 Authorization: Bearer <token> 则携带用于 API 认证的 OAuth 或 JWT 令牌。

• Referer

（没错，这个单词在规范中就是故意拼错的，有时也会写成“Referrer”。）该请求头表示将请求引导至服务器的来源页面 URL。换句话说，如果您在 A 页面点击链接跳转到 B 页面，那么请求 B 页面时就会携带 Referer: <URL of Page A>。

以上只是众多请求头中的一小部分，其他常见的还包括：Cookie（向服务器发送 Cookie）、Accept-Encoding（声明客户端支持的压缩格式，如 gzip 或 br）、DNT（禁止跟踪偏好设置）、If-Modified-Since / If-None-Match（用于基于缓存的条件请求，询问服务器当前请求的页面是否已发生变化），以及 X-Requested-With（AJAX 调用通常将其设为 XMLHttpRequest）。

每个请求头都有其特定作用，帮助服务器理解请求上下文并满足客户端的需求。

响应头

响应头由服务器随 HTTP 响应一起发送给客户端，用于提供有关服务器响应、数据负载或服务器自身的附加信息。简而言之，响应头与状态码、消息体一同告知客户端应如何解读数据以及接下来该做什么。常见的响应头包括：

• Server

Server 响应头用于标识处理该请求的服务器所运行的软件及其版本（例如 Server: Apache/2.4.54 (Ubuntu) 或 Server: nginx/1.21.3）

• Set-Cookie

该响应头用于服务器向用户代理下发 Cookie，Cookie 是服务器希望客户端存储并在后续请求中回传的键值数据，例如：Set-Cookie: sessionId=abc123; Path=/; HttpOnly。

• Location

Location 响应头用于将客户端重定向至另一个 URL，通常出现在表示重定向的 3xx 状态码响应中，或用于新建资源的场景。例如，若客户端请求的页面已迁移，服务器可能返回 HTTP/1.1 301 Moved Permanently，并附带 Location: https://www.new-site.com/newpage。

• Access-Control-Allow-Origin

该响应头是跨源资源共享（CORS）协议的一部分，用于指明哪些源（域名）可以访问该资源。例如，Access-Control-Allow-Origin: * 表示任意源都可以访问，而 Access-Control-Allow-Origin: https://example.com 则仅允许来自该域名的代码访问响应内容。

• Retry-After

该响应头告知客户端在再次发起请求前应等待多长时间，通常出现在表示临时性状态的响应中，例如 503 Service Unavailable 或 429 Too Many Requests

这些响应头（以及 Content-Encoding、Cache-Control、Expires、Pragma、Content-Disposition 等其他响应头）为响应提供了关键的上下文信息，可以指示客户端采取进一步操作（如重定向、稍后重试），提供数据相关信息（类型、长度、语言），或处理状态信息（Cookie）。

接下来，我们将深入了解响应中常见的两类特殊请求头：表示头和安全头。

表示头

表示头用于描述所传输资源或数据负载的特性，尤其是在响应中，用来告知客户端消息体内容的相关信息，例如类型、大小或编码方式。常见的表示头包括：

• Content-Type

表示消息体中资源的媒体类型，告知客户端应如何解读响应（或请求）负载中的字节数据。

• Content-Length

以字节为单位指定消息体的大小，例如 Content-Length: 3472 表示消息体长度为 3472 字节。

• Content-Encoding

表示消息体采用了哪种内容编码（压缩方式），常见取值有 gzip、br（Brotli）或 deflate。

• Content-Language

描述内容所面向受众使用的自然语言

• Last-Modified

服务器认为该资源最后一次发生更改的日期和时间

• ETag

一个用于标识资源特定版本的不透明标识符。ETag 代表“实体标签”，通常是内容的哈希值或指纹，例如：ETag: "33a64df551425fcc55e4d42a148795d9f25f89d8"

表示头确保客户端准确了解自己所获取（或发送）的内容，从而就缓存和处理方式做出合理决策。

例如，浏览器可以通过 Content-Type 判断应如何展示内容、预计接收多少数据，还可以通过 Last-Modified/ETag 判断后续请求能否使用缓存版本。

安全头

安全头是一类响应头，用于指示浏览器启用特定的安全机制或限制，通过控制浏览器行为帮助网站抵御各类威胁。以下是一些关键的安全相关 HTTP 响应头：

• Strict-Transport-Security (HSTS)

该响应头告知浏览器，在指定时长内应仅通过 HTTPS 访问该网站。

• X-Frame-Options

该响应头通过控制您的内容是否可以被嵌入到其他网站的 iframe 中，防止点击劫持攻击。

• Content-Security-Policy (CSP)

这是一个功能强大的响应头，用于指定页面中的内容（脚本、图片、样式等）可以从哪些来源加载。

• X-Content-Type-Options

该响应头用于阻止 MIME 类型嗅探，通常设置为 X-Content-Type-Options: nosniff

• Referrer-Policy

该响应头控制从您的网站跳转到其他网站或在页面间跳转时应发送多少来源信息

只要配置得当，这些安全头能够大幅提升 Web 应用抵御常见攻击的能力，且实现简单、浏览器支持广泛。

作为最佳实践，网站管理员应定期检查并更新这些响应头（例如随着网站变化调整 CSP 规则、续期 HSTS 等），以保持安全配置的时效性。实际上，许多扫描工具（以及 SEO、安全检测工具）都会检查这些响应头是否存在，并以此作为网站安全配置是否完善的信号之一。

数据抓取中的 HTTP 请求头与代理

在数据抓取场景下，HTTP 请求头尤为重要，搭配代理使用时更需谨慎处理。使用自动化脚本或机器人抓取网站时，您希望发出的 HTTP 请求尽可能接近真实用户的请求，这正是请求头发挥作用的地方：合理设置请求头可以让您的请求看起来更合法，从而避免被检测或拦截。

搭配代理使用的关键请求头

如果您的抓取流量通过 HTTP 代理或一系列代理服务器转发，应确保某些请求头存在且设置正确：

• User-Agent

这是数据抓取中最关键的请求头。许多网站会直接拦截没有 User-Agent 或 User-Agent 明显属于机器人的请求。设置一个真实可信的 User-Agent 字符串（例如模拟常见操作系统上的 Chrome 或 Firefox 浏览器），可以让您的抓取程序更好地融入正常流量。

• Referer

携带 Referer 请求头有时能让您的请求显得更自然。例如，如果 X 页面通常是从该网站的 Y 页面跳转而来的，那么在抓取 X 页面时将 Referer 设为 Y，可能有助于降低被怀疑的概率。

• Accept-Language

为了模拟真实浏览器，您可以发送 Accept-Language 请求头（例如 en-US,en;q=0.9）。虽然这并非严格必需，但真实浏览器都会发送该请求头，而且它还可能影响网站返回的内容（例如本地化内容）。

• Cookie

如果在抓取过程中需要登录或维持会话，就会涉及 Cookie 的处理：服务器在此前的响应中通过 Set-Cookie 设置 Cookie 后，您的抓取程序应在后续请求中通过 Cookie 请求头将其一并发送回去。

• Proxy-Authorization

使用付费代理服务或任何需要身份验证的代理服务器时，您可能需要在请求中附带 Proxy-Authorization: Basic <credentials>。该请求头仅供代理服务器读取（不会转发给目标网站），用于向代理服务器验证您的身份。

• Connection

使用某些代理时，您可能会注意到额外的逐跳请求头，例如 Connection: keep-alive 或代理专用的连接指令。一般来说，抓取时不建议过多干预这些设置，使用默认的 keep-alive 即可获得更好的性能（代理可以复用与您之间、乃至与目标站点之间的连接）。

合理设置这些请求头有助于避免被拦截。例如，设置恰当的 Accept 请求头可以避免触发明显的机器人过滤规则，从而防止请求被立即拦截或封禁；同样，按预期携带 Cookie 和 Referer 也能让您的抓取模式更接近正常的浏览会话。

数据抓取最佳实践

结合请求头与代理进行数据抓取时，可参考以下最佳实践：

• 轮换并随机化请求头

切勿在所有请求中连续数月使用完全相同的User-Agent字符串——机器人常因固定不变或过时的用户代理而被识别。请使用一批真实的 User-Agent 字符串并定期轮换，同时尽量在合理、真实的范围内变化 Accept-Language 等其他可选请求头。

• 请求头的一致性

请确保发送的各项请求头彼此吻合：例如，如果 User-Agent 声称是 Windows 系统上的 Chrome 浏览器，就不应同时发送 Accept-Language: fr-CA（加拿大法语），因为一般美国 Windows 版 Chrome 用户不会使用该语言设置。请求体（payload）与请求头之间保持一致是关键。此外，若伪装成浏览器，应包含浏览器通常会发送的常见请求头（如 Accept、Accept-Encoding 等），而不仅仅是 User-Agent。

• 警惕代理信息泄露

配置不当的代理服务器可能会添加 Via 或 X-Forwarded-For 等请求头，从而暴露您正在使用代理、甚至泄露您的真实 IP。理想情况下，应选择不会添加此类请求头的代理，或通过 HTTPS 连接代理服务器，使这些请求头对目标站点不可见。如果您能自行控制代理配置（例如在 Python 或 Node.js 中使用 requests 库），请确保代理真正做到匿名。

• 遵守 robots 协议与速率限制

即使请求头设置得当，如果抓取速度过快或访问禁止访问的区域，依然可能被封锁。部分网站会设置基于请求头的诱捕机制（honeypot），例如检查在该阶段真实用户通常是否会带有某个 Cookie 或请求头。应尽量模拟真实会话：按需加载图片、CSS（至少通过 Accept 请求头进行伪装），遵守返回的 Retry-After 指示，并避免通过代理向网站发起过多并发请求。

• 先在不使用代理的情况下测试

有时问题出在代理服务器而非请求头配置本身。如果请求未能正常工作，可先不使用代理直接测试，确认请求头是否正确，然后再接入代理，这样便可判断是代理移除还是篡改了请求头。例如，部分免费代理可能会移除或重写 User-Agent 请求头，因此在正式的数据抓取中应避免使用此类代理。

通过精心设置 HTTP 请求头并搭配优质代理，可以更可靠地抓取数据，并更轻松地绕过网站采用的 IP 封锁或指纹识别技术。本质上，请求头与代理相结合，可以让您在目标网站看来如同普通用户正常浏览网页。

查看 HTTP 请求头的工具

了解如何查看 HTTP 请求头，能让处理请求头的工作轻松许多。以下几种工具可以帮助您查看和调试请求与响应的请求头：

• 浏览器开发者工具

现代浏览器（Chrome、Firefox、Edge、Safari）均内置开发者工具。在其中的 Network 面板里，可以查看浏览器发出的每个请求，并检查其请求头和响应头。例如在 Chrome 中，按 F12（或右键点击选择“检查”），进入 Network 面板，重新加载页面，再点击某个具体资源即可查看。

• cURL 使用指南（命令行）

作为终端发送 HTTP 请求的多功能工具，cURL 命令可以通过多种方式帮助您查看请求头。

• Postman 与 API 客户端工具

Postman 是一种带有图形界面、广受欢迎的 API 测试工具，可以创建 HTTP 请求、添加任意请求头、发送请求，并查看响应的请求头和响应体，在开发和测试 Web API 时非常实用。

• 在线请求头检测工具

有些在线服务只需输入 URL，即可获取并显示该页面的请求头，例如 web-sniffer、httpstatus.io，以及各类会列出响应请求头（有时还会标注安全相关请求头是否存在）的 SEO 分析工具。

• 代理抓包工具（进阶）

Fiddler、Wireshark、OWASP ZAP 等工具可以拦截并显示 HTTP 流量，其中包括请求头信息。

使用 HTTP 请求头的推荐做法

最后，以下是在应用程序或服务器中使用 HTTP 请求头时的一些推荐做法：

• 避免暴露敏感数据

避免将机密信息放入请求头中：请求头有时会被记录或暴露。例如，除非是 Authorization 这类标准方案的一部分，否则不建议将密码或敏感令牌直接作为请求头发送。即使在 Authorization 请求头中，也应尽量使用安全的令牌（如 Bearer 令牌或 API 密钥），而非直接使用原始凭据。

• 尽量使用标准化请求头

在自行创建自定义请求头之前，先检查是否已有标准请求头能满足需求。HTTP 规范与 IANA 注册表中列出了大量请求头，使用标准请求头能带来更好的兼容性，因为客户端与中介都清楚应如何处理它们。

• 定期更新安全相关请求头

安全相关请求头（如前文提到的 HSTS、CSP 等）应定期检查。例如，如果您的网站现已全面支持 HTTPS，可启用 HSTS 并将其 max-age 设置为较大的值。

• 遵循 RFC 指南与规范

这一点看似显而易见，但许多问题正是源于不符合规范的请求头。请遵循 HTTP 标准来格式化请求头的值（例如日期格式、列表分隔符等），并只使用允许的字符。

另外，别忘了查看我们关于HTTPX vs Requests vs AIOHTTP的文章。