当你在浏览器中输入网址、点击链接或提交表单时，背后都在发生一场 “无声的对话”—— 你的设备（客户端）与目标网站的服务器之间，通过HTTP 协议传递信息。而这场对话的 “开场白”，就是HTTP 请求头：它像一份 “通信说明书”，包含了客户端的关键信息，帮助服务器理解请求、返回正确的内容。

在众多 HTTP 请求头字段中，User-Agent、Cookie、Referer是最核心、最常用的三个 —— 它们分别解决了 “服务器识别客户端”“保持用户状态”“追踪请求来源” 三大问题。今天我们就用通俗的语言，拆解这三个字段的作用、原理和实际场景。

一、User-Agent：告诉服务器 “我是谁”

1. 什么是 User-Agent？

User-Agent（简称 UA）是客户端发给服务器的 “身份名片”，核心作用是告诉服务器 “我是什么设备、用什么浏览器访问你”。

每次发起 HTTP 请求时，浏览器 / APP 会自动在请求头中添加 User-Agent 字段，格式通常是一串包含 “设备类型 + 操作系统 + 浏览器 / 应用名称 + 版本” 的字符串。比如：

• 电脑 Chrome 浏览器的 UA：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36
• 手机 Safari 浏览器的 UA：Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1
• 爬虫程序的 UA（如 Python Requests）：python-requests/2.31.0

2. User-Agent 有什么用？

服务器拿到 UA 后，主要做三件事：

• 适配内容：区分移动端 / PC 端页面这是最常见的用途。比如你用手机访问某网站时，服务器通过 UA 识别到 “这是移动设备”，就会返回适配手机屏幕的 “移动端页面”（字体更大、按钮更宽）；如果是电脑访问，就返回 “PC 端页面”。典型例子：淘宝、京东等电商网站，手机和电脑打开的界面布局完全不同，核心就是 UA 在 “指路”。

• 统计分析：了解用户设备分布网站后台（如百度统计、Google Analytics）会收集所有请求的 UA，分析 “多少用户用 Chrome、多少用 Safari”“多少用安卓、多少用 iOS”，帮助产品团队优化适配策略（比如发现安卓用户占比高，就优先解决安卓端的兼容性问题）。

• 识别爬虫：防止恶意爬取数据正常用户的 UA 是浏览器 / APP 的标识，而爬虫程序的 UA 往往带有 “python-requests”“Scrapy” 等关键词。服务器可以通过 UA 初步判断请求是否来自爬虫，进而限制频繁爬取（比如禁止特定 UA 的访问），保护网站数据安全。

不过要注意：UA 是可以伪造的 —— 比如爬虫可以把 UA 改成浏览器的格式，绕过简单的识别；有些浏览器插件也支持自定义 UA，实现 “用电脑访问移动端页面” 的需求。

二、Cookie：帮服务器 “记住你”

1. 什么是 Cookie？

Cookie 是服务器存放在客户端（浏览器 / APP）的一小段文本数据（通常不超过 4KB），核心作用是让服务器 “记住用户的状态”—— 比如你是否登录、你的偏好设置等。

很多人误以为 Cookie 是 “浏览器自带的”，其实它的生成和使用是一个 “双向协作” 的过程：

1. 第一次请求：服务器 “发 Cookie”当你第一次访问某网站时，客户端没有该网站的 Cookie，服务器处理请求后，会在 HTTP 响应头中添加Set-Cookie字段，把需要记住的信息（如会话 ID、用户 ID）传给客户端。比如登录某网站时，服务器会返回：Set-Cookie: sessionid=abc123; Path=/; HttpOnly。
2. 后续请求：客户端 “带 Cookie”客户端（浏览器）收到Set-Cookie后，会把这段数据存在本地（比如电脑的硬盘、手机的存储中）。之后再访问该网站时，浏览器会自动在 HTTP 请求头中添加Cookie字段，把之前存的信息传给服务器。比如后续请求会携带：Cookie: sessionid=abc123。

2. Cookie 有什么用？

Cookie 的核心价值是 “打破 HTTP 的无状态性”——HTTP 协议本身是 “一次性的”，服务器不会记住上一次的请求，但 Cookie 让 “持续交互” 成为可能，常见场景包括：

• 保持登录状态这是 Cookie 最常用的功能。当你登录某网站（如微信公众号平台、淘宝）时，服务器会通过Set-Cookie把 “登录凭证”（如 sessionid）传给浏览器；之后你刷新页面、访问其他子页面时，浏览器携带 Cookie，服务器验证凭证后就知道 “你已经登录了”，不用每次都输入账号密码。

• 保存个性化偏好比如你在某视频网站设置 “默认播放清晰度为 1080P”“关闭自动播放”，这些偏好会被服务器存在 Cookie 中；下次你访问时，浏览器携带 Cookie，服务器就会按照你的偏好加载页面。

• 实现购物车功能在未登录状态下，你添加到购物车的商品，会被关联到浏览器的 Cookie 中；当你登录后，服务器会把 Cookie 中的购物车数据同步到你的账号下，避免商品丢失。

3. Cookie 的安全性？

Cookie 存储的是用户数据，因此需要注意安全：

• HttpOnly 属性：添加该属性后，Cookie 只能通过 HTTP 请求传递，无法被浏览器的 JavaScript 读取，能有效防止 “XSS 攻击”（黑客通过脚本窃取 Cookie）。
• Secure 属性：只有在 HTTPS 协议（加密通信）下，浏览器才会携带 Cookie，避免数据在传输过程中被窃取。
• SameSite 属性：限制 Cookie 只能在 “同一网站” 内使用，防止 “CSRF 攻击”（黑客伪造用户请求操作账户，如转账）。

三、Referer：告诉服务器 “我从哪来”

1. 什么是 Referer？

Referer（注意：不是 “Referrer”，这是 HTTP 协议的历史拼写错误，一直沿用至今）是客户端发给服务器的 “来源凭证”，核心作用是告诉服务器 “当前请求是从哪个页面跳转过来的”。

比如：

• 你在百度搜索 “HTTP 请求头”，点击搜索结果中的某篇文章（如知乎的文章），此时知乎服务器收到的请求头中，Referer 就是百度的搜索结果页面 URL：https://www.baidu.com/s?wd=HTTP请求头。
• 你在知乎的 A 文章中点击链接，跳转到知乎的 B 文章，此时 B 文章的请求头中，Referer 就是 A 文章的 URL。

2. Referer 有什么用？

服务器通过 Referer 可以追踪请求的 “上游来源”，主要用于三个场景：

• 防止资源盗链这是 Referer 最核心的用途。比如某图片网站（如 Unsplash）的图片资源，只希望用户在自己的网站上查看，不希望其他网站直接引用（盗链）—— 此时服务器会检查请求图片的 Referer，如果 Referer 不是自己的网站域名，就拒绝返回图片（返回 403 错误）。典型例子：很多论坛、博客如果直接引用其他网站的图片，会显示 “图片已失效”，就是因为 Referer 验证不通过。

• 分析流量来源网站后台通过 Referer 可以统计 “用户是从哪些渠道来的”：比如 “从百度搜索来的用户有多少”“从微信朋友圈来的有多少”“从其他网站跳转来的有多少”。这些数据能帮助运营团队判断 “哪个渠道的推广效果更好”（比如百度搜索来的用户转化率高，就可以加大百度推广的投入）。

• 验证请求合法性部分网站会通过 Referer 判断请求是否 “合法”。比如某银行的转账页面，只允许用户从 “银行首页→个人账户→转账页面” 的流程跳转过来（Referer 是银行的个人账户页面 URL）；如果 Referer 是其他陌生网站的 URL，服务器会认为这可能是 “伪造的转账请求”，拒绝处理，防止 CSRF 攻击。

3. 哪些情况没有 Referer？

并非所有请求都有 Referer，以下场景中，Referer 字段会为空或不传递：

• 直接在地址栏输入 URL 访问（没有 “来源页面”）；
• 通过浏览器书签、收藏夹访问；
• 从 HTTPS 协议的页面，跳转到 HTTP 协议的页面（出于安全考虑，浏览器会隐藏 Referer）；
• 部分浏览器插件或隐私模式下，会禁止传递 Referer。

总结：三个字段的核心价值

HTTP 请求头中的 User-Agent、Cookie、Referer，虽然各有分工，但共同支撑了 “客户端与服务器的高效协作”：

• User-Agent：解决 “服务器识别客户端” 的问题，让内容适配不同设备；
• Cookie：解决 “服务器记住用户” 的问题，让持续交互（如登录、个性化）成为可能；
• Referer：解决 “服务器追踪来源” 的问题，让资源保护和流量分析更高效。

理解这三个字段，不仅能帮你搞懂 “浏览器为什么能记住登录状态”“为什么手机和电脑看网站不一样” 这些日常问题，也能为后续学习前端开发、后端接口、网络安全（如 XSS、CSRF 防护）打下基础。

当然，HTTP 请求头还有很多其他字段（如Accept表示客户端能接收的内容格式、Authorization表示身份认证信息），但 User-Agent、Cookie、Referer 是最贴近用户体验、最容易理解的三个 —— 掌握它们，就相当于掌握了 HTTP 请求头的 “核心逻辑”。