网页抓取总被识别封禁？HTTP标头正确的配置加代理IP

网页抓取的本质就是模拟真实用户的浏览行为，HTTP请求标头是浏览器每次访问网站时自动带上的“身份信息包”，服务器靠它判断来访者到底是真人还是脚本。标头配置有破绽，再加上IP质量拉胯，是绝大多数抓取被封的根因。

搞网页抓取的都知道，服务器不是随随便便就封你的——它会综合判断请求标头和IP行为模式。一个正常的浏览器发出的请求，标头信息是成套对齐的；而脚本发出的请求，标头往往东拼西凑，一眼就能被认出来。如果你用的是质量差的代理IP，比如一个IP短时间内发出几千条请求，标头还千篇一律，那就等于举着牌子喊“我是爬虫”。

要想把抓取做得稳，你得搞明白五类核心标头各自的作用，以及它们跟代理IP之间怎么打配合。下面咱们一个一个拆开说。

网页抓取必须配置哪五种HTTP标头？

一、User-Agent（UA）——你的“浏览器身份证”

User-Agent是服务器第一个看的标头。它告诉对方你用的是啥浏览器、啥操作系统、啥渲染引擎。举个例子，一个正常的Chrome浏览器发出的UA长这样：

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

很多新手直接用Python默认的UA，比如 python-requests/2.31.0，服务器一看就知道这不是真人，立刻给你来个403。所以UA库得维护好，定期更新，而且要和后面的标头信息对得上号——你UA说自己是Chrome，结果Accept-Language暴露了你是脚本，那就露馅了。

二、Cookie——你的“通行令牌”

Cookie是服务器写在你“脑门”上的记号。很多网站你不带Cookie连门都进不去，带了Cookie也得讲究——同一个Cookie短时间内换不同IP频繁请求，服务器马上警觉：正常人不可能前一秒在北京，后一秒跑到广州再下一秒又回到北京。

这里就涉及到代理IP的选择了。如果你用的是隧道代理IP，每次请求自动换IP，那Cookie就得跟着换，或者干脆每次新开一个会话。反之，如果用的是长效静态IP，同一个IP搭配同一个Cookie维持长会话，行为模式就更贴近真人——就像你坐在家里刷了一下午网页一样自然。

三、Referer——你的“来路说明”

Referer告诉服务器你从哪个页面跳过来的。举个例子，你抓取某个商品详情页，Referer如果写的是该网站首页或者搜索结果页，看起来就很正常；如果Referer是空的，或者写着一个完全不搭边的网址，服务器一眼就看出不对劲。

很多反爬机制会检查Referer链条是否合理，所以抓取的时候最好模拟真实的浏览路径：先访问列表页，再把列表页URL作为Referer去请求详情页。

四、Accept-Language——你的“语言偏好”

这个标头看着不起眼，但很多网站会用它来辅助判断请求来源是否合理。比如你抓取的是一个中文网站，Accept-Language写的却是 en-US,en;q=0.9，这就有点说不通。虽然不一定会直接导致封禁，但在风控系统的综合评分里会给你加一笔“可疑分”。

顺带一提，移动代理IP在这个场景下有个天然优势：移动网络的IP本身就在运营商的NAT后面，成千上万个用户共用一个出口IP，语言偏好、UA五花八门都是正常的，服务器对这类IP的容忍度本来就高一些。

五、Accept与Accept-Encoding——你的“能力声明”

这两个标头告诉服务器你能接收什么格式的响应，以及支持什么压缩方式。一般浏览器都会带上 text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 这么一长串。如果你只写了 / 或者干脆没写，服务器就知道你不是浏览器。

下面用一张表把这五个标头的作用和常见踩坑点整理清楚：

代理IP搭配标头怎么设置才能降低被封概率？

标头配置到位了，代理IP选型也得跟上，二者是绑在一根绳上的蚂蚱。下面分几种典型场景来说。

场景一：大批量数据采集

这种场景请求量大、频率高，最怕的就是IP被标记。如果你用不限量代理IP，池子里IP数量够多，每个请求换一个IP，理论上很美好。但很多人忽略了一点：IP换了，标头没跟着变，几十万个请求用的都是同一个UA，服务器一统计UA去重数只有1，照样给你封得死死的。

正确做法是：IP池和UA池配合轮换，每个IP搭配一组不同的标头组合。门槛高一点的做法，还可以让每个IP的标头组合保持一段时间不变，模拟真实用户在同一IP下持续浏览的行为模式。

场景二：需要维持登录态的采集

很多网站你得登录了才能看数据，这种场景下Cookie是关键。如果用每次请求换IP的代理方式，Cookie和IP频繁对不上号，网站很可能要求你重新登录，甚至直接封号。

这时候独享代理IP或长效静态IP就是更合理的选择。一个IP长期独占，搭配一套稳定的标头，维持登录态可以做到几小时甚至一整天不掉。独享代理的好处是没人跟你抢带宽，IP信誉也不会被别人的抓取行为拖累。

场景三：App端数据抓取

App接口对请求格式的要求和网页端不太一样，很多App用的是HTTPS加密传输，标头里还会带上一些自定义字段，比如 X-App-Version、X-Device-ID 之类的。

这种场景下移动代理IP的契合度最高——毕竟App本身就是跑在移动网络上的，用移动代理去请求App接口，从IP类型到标头特征都对齐了，风控系统更倾向于把你当正常用户处理。

下面把四种常见代理IP在标头配置场景下的适用性对比一下：

一个实测案例：

拿同一个电商网站的商品列表页做抓取测试，目标10000条数据。方案A：用普通数据中心IP加固定UA，跑到大概1200条的时候开始出现验证码，到1800条IP直接被封。方案B：换上全网HTTP的隧道代理IP配UA轮换池，全程跑完没有触发验证码，成功率98.7%。方案C：用长效静态IP搭配固定但合理分布的标头组合，模拟正常浏览节奏（每次请求间隔2-5秒随机），同样跑完全程，成功率97.2%。

三组对比说明一个事：标头配置和代理IP质量是相辅相成的，单拎出来哪一个都不够。

新手配置HTTP标头最常犯的几个错误

第一个错误是抄了别人的标头配置就不管了。网上很多教程里的UA已经是好几年前的版本，真实用户早就升级了。你拿着Chrome 89的UA去请求一个只允许Chrome 120以上版本访问的接口，行为本身就反常。

第二个错误是标头之间互相矛盾。前面说了，UA说我是Windows上的Chrome，Accept-Language却写着 ja-JP，这就对不上。风控系统现在都会做交叉验证，矛盾越明显，可疑分越高。

第三个错误是过度追求“完美配置”。有些朋友把标头配置得比真浏览器还真，所有字段一个不落，结果反而不自然——因为真实的浏览器请求有时候也会因为网络环境、插件等因素导致标头不完整。适当“漏”掉一两个次要字段，反而跟真人更接近。

第四个错误是不清楚自己的代理IP支持哪些标头配置方式。有些代理服务只支持在请求URL里传参，不支持自定义标头；有些支持完全自定义，甚至可以模拟浏览器指纹。选代理之前先把这点搞清楚，不然买了才发现不支持你的需求，白白浪费钱。

常见问题FAQ

Q1：网页抓取时HTTP标头不配置行不行？直接用代码默认的能跑吗？

能跑，但跑不远。一些反爬比较松的小网站可能不查标头，但稍微正规一点的网站都会做UA校验。默认的Python请求标头等于自报家门，被封只是时间问题。花十分钟配一下标头，比你后来花半天解封划算得多。

Q2：隧道代理IP每次换IP的时候标头要跟着换吗？

要的。你想，同一个UA短时间内从几十个不同IP发请求，服务器那边一统计，UA去重数极低但IP去重数极高，这就是典型的代理池特征。标头和IP同步轮换是把代理的价值发挥到最大的关键操作。

Q3：长效静态IP和独享代理IP有什么区别？标头配置上有什么不同？

长效静态IP是一段时间内IP不变，独享代理IP是IP完全归你一个人用。前者侧重“时间维度”的稳定，后者侧重“独占维度”的纯净。标头配置上，长效静态IP适合固定组合长期维持同一会话；独享代理IP因为IP完全由你把控，你可以更放心地按真人行为模式来设置，不用担心被别人的抓取行为牵连。

Q4：移动代理IP对标头配置有什么特殊要求吗？

移动代理IP由于本身就在运营商的移动网络里，服务器对这类IP的标头校验相对宽松。建议把UA设成移动端的（iOS
Safari或者Android
Chrome），Accept-Language、设备分辨率等标头也尽量匹配移动端特征，这样整套下来就更像真实手机用户在访问了。

Q5：Referer标头到底要不要每个请求都带上？

看情况。如果你是按浏览路径顺序抓取的（列表页→详情页），Referer能增强真实性，建议带上。但如果是随机跳着抓的，强行填一个对不上的Referer反而更可疑，要么按真实路径构造，要么宁可留空，不要瞎填。

Q6：怎么判断我的标头配置有没有问题？

最简单的办法：用你配置好的请求去访问一个能回显请求信息的网站（比如专门检测HTTP请求的在线工具），看看服务器收到的标头信息长什么样。把回显结果跟你自己浏览器真实发出的请求对比一下，不一致的地方就是需要调的。另外，跑一小批测试数据，观察返回码——如果大量出现403或者验证码，大概率是标头和IP配置哪里出了岔子。