HTTP 请求头与响应头实战：User-Agent、Referer、Cookie、Content-Type

为什么 HTTP 头字段决定了爬虫成败？

很多同学会遇到这种情况：浏览器访问正常，脚本请求却失败。 最常见原因不是 URL 写错，而是 HTTP 头信息不完整或不一致。

在爬虫场景里，头字段可以理解为"请求的上下文身份信息"。服务端经常根据这些信息做鉴权、风控和内容分发。

HTTP 请求头要看哪 3 个？

User-Agent 是什么？声明客户端身份有什么用？

User-Agent 用于告诉服务端"我是哪个浏览器/设备发起的请求"。 许多站点会根据它做基础策略判断，缺失或异常可能直接触发拦截。

实战建议：

1. 先复用浏览器真实 User-Agent。
2. 批量采集时保持同一会话内稳定，避免频繁切换。
3. 如果返回异常页，优先检查 User-Agent 是否丢失。

Referer 是什么？为什么重要？

Referer 表示当前请求来自哪个页面。 部分接口会要求"必须从特定页面跳转而来"，否则直接拒绝。

实战建议：

1. 先在浏览器抓包确认真实 Referer。
2. 请求链路中涉及详情页、播放页、下载页时重点检查。
3. 出现 403 时，把 Referer 放到首批排查项。

Cookie 是什么？为什么要携带登录态？

Cookie 是会话状态的核心载体。 登录后拿到的数据，脚本如果不带对应 Cookie，大概率会变成未登录视图或直接报错。

实战建议：

1. 把 Cookie 视为"会话钥匙"，注意时效和刷新。
2. 优先使用会话对象自动管理 Cookie，而不是手写拼接。
3. 当响应提示未授权时，先检查 Cookie 是否过期或缺字段。

响应头为什么要先看 Content-Type？

Content-Type 告诉你响应体是什么格式。 例如：

1. text/html; charset=utf-8：HTML 页面
2. application/json：JSON 数据
3. image/webp：图片资源

它对爬虫的价值主要有两点：

1. 判断当前拿到的是"真实业务数据"还是"跳转页/错误页"。
2. 判断解码方式，避免乱码或解析失败。

为什么不能只看状态码，还要看响应头？

很多请求返回 200，但实际上拿到的是登录页 HTML，而不是目标 JSON。 这时候如果不看 Content-Type，你会误以为接口成功，后续解析才报错。

正确做法是：

1. 先看状态码
2. 再看 Content-Type
3. 最后根据类型选择解析策略（HTML 解析或 JSON 解析）

如何用请求头与响应头联动排错？

当你遇到"浏览器有数据，脚本没数据"时，按顺序检查：

1. URL、请求方法是否一致。
2. 请求参数（query/body）是否一致。
3. User-Agent 是否缺失或异常。
4. Referer 是否符合来源要求。
5. Cookie 是否有效且完整。
6. 响应状态码是否异常（尤其 401/403/429）。
7. Content-Type 是否符合预期。

这 7 步能覆盖大部分接口复现失败场景。

浏览器开发者工具怎么用来排查爬虫请求？

建议固定在 Network 面板做三件事：

1. 找到目标请求（先看 document，再定位 xhr/fetch）。
2. 查看 Headers，记录关键请求头和响应头。
3. 对照脚本请求逐项比对，不一致就先改一致。

只要你养成"先抓包，再写代码，再比对"的习惯，排错成本会明显下降。

总结

HTTP 头字段不是细枝末节，而是爬虫请求能否通过服务端校验的基础。 把 User-Agent、Referer、Cookie、Content-Type 这四项吃透，接口复现成功率会有非常明显的提升。