做爬虫开发 5 年多，我踩过最头疼的坑，就是爬虫被 ban。前一秒还在顺畅采集数据，下一秒就弹出 403 禁止访问，更糟的是本机 IP 被拉黑，连目标网站都无法正常打开，忙活大半天的成果全白费。

刚开始新手时，盲目修改请求头、乱用免费代理，结果越改越糟，被 ban 的频率越来越高。后来踩的坑多了才明白，避免爬虫被 ban，做好爬虫反爬工作，从来不是单靠某一个配置就能实现的，必须依靠 User-Agent、Cookie 和代理 IP 三者协同配合，少了任何一个，都容易翻车。今天就把这三者的配置逻辑和实操技巧讲清楚，分享实用的爬虫防 ban 技巧，新手也能直接套用，少走弯路。

User-Agent：给爬虫一个“合法身份”，避免暴露自身

刚开始写爬虫时，我犯过一个低级错误：直接使用 Python requests 库的默认请求头，结果爬了不到 5 分钟就被 ban 了。后来排查才发现，默认的 User-Agent 会明确显示“Python-requests/2.25.1”，相当于直接告诉网站“我是爬虫”，被拦截也就在情理之中。

User-Agent 的核心作用，就是告诉网站“我是什么设备、用什么浏览器访问”，做好 User-Agent 配置是爬虫反爬的基础步骤之一。正常用户浏览网站时，浏览器都会自动携带这个标识，而爬虫如果不设置、或一直使用同一个标识，很容易被判定为异常流量，进而被拉黑。

分享两个亲测有效的实操技巧，简单易上手：

1.  不用默认值，不随意编造：随便修改 User-Agent 的几个数字，很容易被网站识别。最稳妥的方法，是用真实浏览器访问目标网站，按 F12 打开开发者工具，在 Network 中找到任意一个请求，复制其中的 User-Agent，直接应用到爬虫中即可。

比如 Chrome 浏览器的 User-Agent：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36，这样的标识足够真实，不易被盯上。

2.  动态轮换，避免固定不变：即便使用了真实的 User-Agent，一直用同一个也会引起网站怀疑——正常用户不会全程使用同一个浏览器、同一台设备访问。

建议搭建一个 User-Agent 池，放入 5-10 个不同浏览器、不同设备（电脑、手机）的真实标识，每次请求随机选取一个。比如爬资讯类网站，可偶尔切换 Chrome 和 Edge 浏览器标识；爬移动端网站，穿插手机端 Safari 标识，更贴近正常用户的访问习惯。

小提醒：无需过于复杂，准备 5-10 个真实标识即可，重点是“随机轮换”，避免长期使用同一个。

Cookie：留下“正常浏览痕迹”，降低被怀疑的概率

解决了 User-Agent 的问题后，我又遇到了新的麻烦：更换了真实标识，爬了一会儿还是被 ban。排查后发现，我忽略了一个关键配置——Cookie。

Cookie 的作用很简单，就是记录用户的浏览痕迹：访问时间、浏览过的页面、是否登录过等信息，都会被存储在 Cookie 中，合理的 Cookie 配置能有效提升爬虫反爬效果。正常用户浏览网站时，浏览器会自动携带 Cookie，而爬虫如果不携带、或 Cookie 异常，很容易被判定为“机器访客”。

结合实操经验，Cookie 的配置核心就两点，无需复杂的加密操作，新手也能轻松掌握：

1.  首次请求获取 Cookie，后续自动携带：刚开始爬取目标网站时，先用 requests.Session()发起一次 GET 请求，让网站下发 Cookie。后续所有请求均使用这个 Session 对象发起，它会自动携带 Cookie，让网站判定为连续浏览的正常用户。

2.  定期更新 Cookie，避免过期失效：Cookie 并非永久有效，大多有明确的过期时间，过期后再携带不仅无效，还可能触发网站的安全检测。

建议每 1-2 小时重新发起一次首次请求，获取新的 Cookie 替换旧的；若目标网站反爬较严，可缩短至 30 分钟更新一次，具体可根据网站反爬强度灵活调整。

避坑提醒：不要手动修改 Cookie 内容，也不要使用他人的 Cookie，否则容易触发安全检测，直接被 ban。最好由爬虫实时获取、实时更新，既安全又省心。

代理 IP：更换“访问地址”，规避 IP 封锁

做好 User-Agent 和 Cookie 的配置后，爬虫能稳定一段时间，但如果爬取量较大、访问频率较高，依然会被 ban——因为你的真实 IP 是固定的，长期从同一个 IP 发起请求，很容易被网站识别为异常。

代理 IP 的核心作用，就是为爬虫提供不同的访问地址，让网站无法定位到你的真实 IP，从而规避 IP 封锁，代理 IP 配置是爬虫反爬中不可或缺的一环。这是避免爬虫被 ban 的核心步骤，也是我踩坑最多的地方。

分享两个代理 IP 配置的关键技巧，新手一定要记牢：

1.  动态轮换 IP，控制轮换频率：和 User-Agent 一样，代理 IP 也不能长期使用同一个，需要定期轮换。轮换频率根据网站反爬强度调整：

反爬较弱的网站（如普通资讯网），每 30-60 秒更换一次；反爬中等的网站（如普通电商平台），每 10-30 秒更换一次；反爬严格的网站（如头部电商、学术平台），每 5-10 秒更换一次，同时需随机调整请求间隔，避免机械性轮换被识别。

2.  验证 IP 有效性，及时剔除失效 IP：无论使用付费代理还是自建代理池，IP 都有失效的可能。如果用失效的 IP 发起请求，很容易被网站识别为异常，甚至连累爬虫被 ban。

建议每次请求前，先验证 IP 有效性（比如访问百度，查看是否能正常返回结果），及时剔除失效 IP，只保留可用 IP，能有效降低被 ban 的概率。

核心关键：三者协同，缺一不可

很多新手会有疑问：我单独配置了 User-Agent，也用了代理 IP，为什么还是被 ban？答案很简单：三者没有协同配合，各自为战，依然会被网站识别。

这就像一个人，即便身份信息正确、穿着得体，但言行举止异常，依然会引起他人怀疑。爬虫也是如此，只有三者协同配合，才能完美模拟正常用户行为，实现稳定爬取。

整理了一套新手友好型协同配置方案，涵盖 User-Agent 配置、Cookie 配置、代理 IP 配置，直接套用即可，稳定性拉满，轻松掌握爬虫防 ban 技巧：

1.  准备基础物料：搭建包含 5-10 个真实 User-Agent 的 UA 池（兼顾电脑端和手机端）、一个稳定的代理 IP 池（至少 50 个可用 IP），以及一个用于管理 Cookie 的 Session 对象。

2.  发起请求时协同配合：每次请求前，从 UA 池随机选取一个 User-Agent，从代理 IP 池随机选取一个可用 IP，通过 Session 对象发起请求（自动携带 Cookie）；同时设置 1-3 秒的随机请求间隔，反爬严格的网站可延长至 3-5 秒，贴合正常用户的浏览速度。

3.  实时维护更新：每 1-2 小时更新一次 Cookie，每 30 分钟检查并更新代理 IP 池（剔除失效 IP、补充新 IP），每天更新一次 UA 池，新增最新的浏览器标识，避免被网站识别出固定模板。

4.  添加安全监控：在爬虫中添加状态码判断，若出现 403、404、503 等异常状态码，立即停止当前 IP 的请求，更换新的 IP 和 UA，暂停 10-20 秒后再继续；若连续多次出现异常，直接停止爬虫排查问题，避免被进一步封禁。

常见疑问 Q&A

Q1：我只配置了代理 IP，没改 User-Agent 和 Cookie，为什么还是会被 ban？

A：爬虫反爬的核心是三者协同，单独配置任何一个都不行。只换代理 IP，User-Agent 和 Cookie 依然是异常状态，网站还是能通过请求特征识别出爬虫——就像只换了手机号，身份证和行为习惯没变，依然能被认出。建议同步做好 User-Agent 配置、Cookie 配置和代理 IP 配置，三者配合才能避免被 ban。

Q2：配置完三者后，访问频率可以随意设置吗？

A：不可以。即便做好了 User-Agent、Cookie 和代理 IP 的协同配置，若访问频率过高（比如每秒十几次请求），远超正常用户的浏览速度，依然会被网站判定为异常流量，进而被 ban。建议设置 1-3 秒的随机请求间隔，反爬严格的网站可延长至 3-5 秒，贴合真人浏览节奏。

Q3：无视 robots 协议，只爬取少量禁止采集的内容，应该不会被 ban 吧？

A：大概率会被 ban，而且还可能涉及合规问题。robots 协议是网站明确的爬取规则，即便只爬少量禁止内容，也可能触发网站的反爬机制，导致 IP 被拉黑；同时，爬取禁止采集的内容，还可能违反相关法律法规，得不偿失。建议只爬取网站公开允许的内容，严格遵守 robots 协议。

Q4：做好三者协同配置后，就一定不会被 ban 吗？

A：不一定，但能大幅降低被 ban 的概率。三者协同是最核心的爬虫防 ban 技巧，能最大程度模拟正常用户行为，但不同网站的反爬强度不同，若遇到反爬极其严格的网站，还需要结合其他反爬手段（如添加安全监控、定期更新配置）。另外，定期维护 UA 池、Cookie 和代理 IP 池，也能进一步提升爬虫的稳定性。

Q5：新手刚开始做爬虫反爬，重点要关注什么？

A：新手重点关注“协同”和“模拟真人”两个核心。先做好基础的 User-Agent 配置、Cookie 配置和代理 IP 配置，确保三者协同配合；再控制访问频率、随机轮换配置，模拟正常用户的浏览行为，不用一开始就追求复杂的加密操作，把基础配置做扎实，就能避开 80% 的坑。