★ FEATURED ARTICLE 先声明一点出于合规和行文安全考虑下面所有涉及“某大型购票平台”的例子都只作技术讨论用不点名任何真实系统。很多人一提到这类平台的脚本化请求第一反应就是“验证码好烦”但实际上真正挡人的不是那张图而是它背后一整套分层风控模型。这篇文章我从 Python 网络请求侧出发聊聊如何理解这些防护、优化自己的请求特征以及在高频调用场景下怎么做到既稳定又不过线。如果你准备做接口自动化、公开数据采集或者只是想把一个批量查询工具的稳定性提上来这篇内容应该对你有用。文中所有方法都是通用工程实践不碰验证码破解、不伪造签名、不碰任何未授权数据这一点很重要后面我会专门展开。1. 这类平台的反爬逻辑远不止“验证码”那么简单1.1 从请求进入到被拦截中间隔着几道闸门大多数人以为反爬就是“服务器端检查一下 User-Agent”其实真实流程比这个复杂得多。一次请求从网络栈进入应用通常会依次经过网络层、应用层、业务层三层防护每一层的判断维度都不一样。网络层最常见的是基于 IP 信誉的限速和封禁比如某个 IP 的请求频率超过阈值或者网段归属地异常就会直接拒绝服务。应用层则包括 TLS 指纹识别、HTTP/2 帧特征、Header 校验、Cookie 完整性检查。业务层更“可怕”它会分析你的请求时间分布、操作链路的先后顺序、甚至单次会话内的点击轨迹是否合理。所以你会发现单纯改一个 UA 根本没意义因为服务器看到的维度实在太多了。理解这个分层逻辑是后续所有优化工作的前提。防护层级常见检测维度合规优化方向网络层IP 信誉库、网段归属、请求速率合理的出口 IP 规划、访问节奏控制应用层UA、TLS 指纹、HTTP/2 设置、Header 完整性模拟真实客户端的请求上下文业务层操作链路、行为模型、验证码控制并发与频率避免批量异常操作从这张表能看出来反爬不只是一道墙更像是一个持续评估“这个访问者到底像不像真人”的评分系统。任何一环分值太低前面做再多优化也可能被一票否决。1.2 行为模型为什么“高并发快请求”必死很多技术新人喜欢用高并发来体现“性能好”但对于这类平台高并发恰恰是最大的行为特征异常。正常人不可能在同一秒内发起几十个请求更不可能以毫秒级间隔连续点击同一个按钮。平台的行为模型通常会关注三个维度相邻请求的时间间隔是否符合正态分布、操作路径是否大概率重复、单次会话内的请求总量是否超出合理范围。换句话说服务器看的不是“你这一秒发了几个请求”而是“你发请求的方式像不像一个人类用户”。我见过一个模拟购票查询服务的压力测试用 200 个线程同时请求余票查询接口前 30 秒响应都很正常然后突然之间所有请求都开始返回验证页面。原因很简单短时间内的频率尖峰触发了行为检测。后面我们把并发降到 8并把请求间隔打散成 300 到 700 毫秒的随机分布同一个 IP 连续跑了大半天也没事。所以真正有效的优化方向不是“更快”而是“更自然”。这听起来有点反直觉但实测下来就是如此。1.3 合规边界什么能调优什么坚决不能碰聊技术之前必须把边界划清楚。本文所说的“请求优化”是指在服务方允许的数据访问范围内通过调整自身客户端的连接策略、请求头、重试机制、频率控制让请求更稳定、更少误伤而不是绕过安全验证去获取未授权数据。不能碰的包括验证码识别绕过、签名参数逆向破解、账号批量注册、利用已知漏洞穿透风控以及大规模抓取平台未公开的商业数据。这些行为轻则违反服务条款重则触发法律责任完全没有必要用自己的技术生涯去赌。合规的数据采集应该具备三个前提数据是公开可访问的、请求频率控制在合理范围、目标系统有明确的 Robots 或服务协议允许这类访问。如果你不确定边界宁可先向平台方申请授权或者使用官方提供的开放接口。这套思路放在自动化测试、接口巡检、性能监控里同样成立需要的技术能力一点也不少。2. 请求优化前先把你自己的请求链改干净2.1 HTTP 质量编排UA、Header 与 Cookie 的完整性很多人用爬虫框架发请求时只设置一个 UA其他 Header 全部默认这种行为在服务器眼里非常可疑。一个正常浏览器发出的请求会附带完整的 Accept、Accept-Language、Accept-Encoding、Connection、Upgrade-Insecure-Requests以及特定页面的 Referer、Origin、Sec-Fetch-* 等字段。这些字段不是摆设服务器会综合检查它们的取值是否互相矛盾。比如你声称是 Chrome 129但 Accept-Language 用的是系统默认英语格式Sec-Fetch-Site 字段还是跨域请求的样式风控模型很快就会把分数降下来。我建议把整套 Header 配置做成一条模板每次构建请求时统一注入。另外Cookie 的同步也很关键。如果你用 requests.Session()它会把服务端 set-cookie 自动保存并后续携带但有些平台的 Cookie 依赖点击事件逐步生成单纯靠初始请求拿到的 Cookie 并不完整。这种情况下最好的办法是通过浏览器手动完成一次前端流程把最终的 Cookie 导出再放到请求配置里做会话复用。下面是一个比较干净的请求客户端骨架实测在多数场景下都能稳定工作import requests from requests.adapters import HTTPAdapter HEADERS_TEMPLATE { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 ), Accept: ( text/html,application/xhtmlxml,application/xml;q0.9, image/avif,image/webp,*/*;q0.8 ), Accept-Language: zh-CN,zh;q0.9,en;q0.8, Referer: https://example.com/query, } def build_session(cookie_str: str ) - requests.Session: session requests.Session() session.headers.update(HEADERS_TEMPLATE) if cookie_str: session.headers[Cookie] cookie_str adapter HTTPAdapter( pool_connections5, pool_maxsize10, max_retries0, ) session.mount(https://, adapter) return session注意这里max_retries设成了 0因为重试策略我想放在更上层做精细控制而不是让底层自动重试不然遇到超时会盲目地把同一个请求连续打出去反而制造紧急负载。2.2 连接池与 Session 复用减少不必要的握手开销网络请求优化的第一步不是“发得快”而是“复用得好”。如果每个请求都新建连接就会重复 TCP 三次握手和 TLS 握手不仅耗时增加服务器端也会在连接日志里看到大量短连接这种特征本身就是自动化脚本的经典标记。用 requests.Session() 的好处是它会维护 urllib3 底层的连接池同一个 host 复用 keep-alive 连接大幅减少重复握手。连接池有两个关键参数pool_connections 表示缓存的不同主机连接数pool_maxsize 表示每个主机的最大连接数。对于单机脚本这两个值设置到 5 和 10 就足够不需要盲目调大。还要留意一个细节如果你的服务端证书链很长TLS 握手的开销会非常可观。优化方式是手动指定verifyFalse并配合 urllib3 的disable_warnings但是注意这只是跳过证书校验绝不等于推荐不做证书验证。真实项目里更应该做的是把证书链固化到本地用verifycertifi.where()指向系统根证书避免每次启动都重新加载 CA 列表。2.3 DNS 与 TCP 层优化预解析、Keep-Alive 与超时控制平时很少有人在 Python requests 里想到 DNS 优化但在高并发场景下DNS 解析的 C 库阻塞会成为隐藏瓶颈。requests 默认用 socket.getaddrinfo每次连接如果没命中系统缓存都可能走一次完整解析。对于目标域名固定且 IP 变动不频繁的平台建议启动时先用socket.getaddrinfo主动解析一次把结果存进本地变量需要时直接用 IP 作为连接目标同时把 Host 头设置为原始域名。这样既能绕过多次 DNS 查询又不影响 HTTP 层的虚拟主机路由。超时控制更是血泪教训。我见过很多脚本只设置了连接超时却忘了设置 read 超时结果目标系统响应变慢时线程全部卡在 socket 读等待上并发瞬间被打满。正确的做法是在 requests.get 或 post 里同时传入timeout(connect_timeout, read_timeout)比如timeout(3.05, 10)Connect 超时设短一点Read 超时根据业务容忍度放宽到 10 秒左右。这套配置上限明确线程不会无限等待。3. 反限流实战频率控制、重试退避与并发编排3.1 令牌桶为什么固定间隔反而更危险有些工程师觉得“每秒限 1 次请求”就在代码里睡 1 秒然后稳定地每隔 1000 毫秒发一次请求。这种匀速节奏看起来很正常但一旦数据叠加到风控系统里会发现间隔的方差几乎为零这种“过于规律”的访问模式比随机间隔更容易被识别。更好的模型是令牌桶。令牌以固定速率生成桶容量代表可突发的最大请求数请求每次消耗一个令牌。这种算法允许短暂的突发又约束了长期平均速率行为上比“sleep 固定时长”要自然得多。我给你们一个简化版实现不用额外装库就是纯 Python 的装饰器import time import threading class TokenBucket: def __init__(self, capacity: float, fill_rate: float): self.capacity capacity self.fill_rate fill_rate self._tokens capacity self._timestamp time.monotonic() self._lock threading.Lock() def acquire(self, block: bool True): while True: with self._lock: now time.monotonic() elapsed now - self._timestamp self._tokens min(self.capacity, self._tokens elapsed * self.fill_rate) self._timestamp now if self._tokens 1: self._tokens - 1 return True if not block: return False wait_time (1 - self._tokens) / self.fill_rate time.sleep(wait_time)使用的时候capacity控制单次突发量fill_rate控制长期速率。比如TokenBucket(5, 0.5)表示每秒补充 0.5 个令牌也就是最多两秒发一个请求但允许一瞬间先打出 5 个。这正好模拟了真人“先用几次操作再停下来思考”的节奏。3.2 指数退避与抖动重试不是越勤越好请求失败之后要不要重试当然要但不能一股脑重试。大多数临时性失败比如 429 限流或者 503 服务暂不可用几秒后就能恢复但如果重试太频繁容易掉进“失败-重试-继续失败”的恶性循环。标准做法是指数退避即第 n 次重试的等待时间是 base * 2^n。不过纯指数退避有一个问题多个进程如果同时失败它们会在相同的时间点醒来然后同时发起重试造成“惊群效应”。解决方式是加入随机抖动jitter让每次等待时间在基线基础上加一点随机偏移。一个经验值是第一次重试等待 1 到 3 秒第二次 3 到 7 秒第三次 10 到 20 秒最多重试 3 到 4 次。超过这个次数就放弃当前请求把任务重新放回队列等待下一轮。用 tenacity 库实现特别简洁from tenacity import ( retry, stop_after_attempt, wait_random_exponential, retry_if_exception_type, ) import requests retry( stopstop_after_attempt(4), waitwait_random_exponential(multiplier1, max20), retryretry_if_exception_type(( requests.ConnectionError, requests.Timeout, )), reraiseTrue, ) def fetch(session, url, **kwargs): resp session.get(url, timeout(3.05, 10), **kwargs) if resp.status_code 429: raise requests.Timeout(rate limited) resp.raise_for_status() return resp这段代码把 429 也视作异常触发重试配合随机指数退避既保证了成功率也不会在服务端恢复瞬间形成重试风暴。3.3 并发控制线程数、带宽与响应时间之间的平衡先明确一件事并发数不是越大越好。对于 IO 密集型任务线程数过高反而会因为上下文切换和 socket 缓冲区竞争拖慢整体性能更重要的是会给目标平台造成明显压力特征。合理的并发数与目标接口的响应时间、本地带宽、目标限流阈值都有关。一个粗略的计算公式是最优并发数 ≈ 目标 QPS × 单请求耗时。例如你希望单机整体请求速率是 5 QPS接口平均耗时 0.8 秒那么并发数只要 4 就足够超过这个数就意味着会有大量请求被阻塞在队列里等待。我的建议是先用 1 个线程跑 100 次请求测量平均响应时间然后再按目标速率反推并发数。不要凭感觉去调。下面是一个基于 ThreadPoolExecutor 的并发控制样例from concurrent.futures import ThreadPoolExecutor, as_completed from collections import deque import time class RateLimitedWorker: def __init__(self, max_workers: int, bucket: TokenBucket): self.executor ThreadPoolExecutor(max_workersmax_workers) self.bucket bucket def submit(self, fn, *args, **kwargs): self.bucket.acquire() return self.executor.submit(fn, *args, **kwargs) def shutdown(self): self.executor.shutdown(waitTrue)这样每个任务在真正提交给线程池之前都要先经过令牌桶并发数限制和频率限制同时生效不会出现“线程池只有 8 个但一秒内发出几百个请求”的失控局面。3.4 实战记录一个批量查询任务从被封到稳定运行为了把上面的知识点串起来我以一次模拟购票平台余票查询的任务为例说下完整的调优过程。最初方案很简单开 50 个线程循环对查询接口发起 GET 请求每次请求之间 sleep 0.1 秒。刚跑了两分钟日志里出现大量 403再过一会儿直接返回验证页面。我第一反应是 Header 不够完整补全了 UA、Referer、Cookie 之后重新测试情况有所缓解但跑了半小时后还是被限流。第二版做了三件事请求头完整模板化、连接池复用、线程数从 50 降到 8。效果明显提升连续跑了两个小时没被验证码拦截。但整体吞吐率不理想平均每秒只完成 4 个请求和预期相差不少。第三版引入令牌桶和退避重试容量定为 6填充速率为 1.2也就是平均每秒最多 1.2 个请求峰值允许连续打 6 个。配合随机抖动延迟最终稳定运行了一整天成功率保持在 99.6% 以上。最终参数如下表配置项初始值调优后变化原因线程数508降低单机并发压力减少线程切换开销请求间隔固定 0.1s令牌桶 随机抖动模拟自然访问节奏避免规律性重试次数0最多 4 次应对瞬时限流和连接超时连接池大小无连接池5 / 10复用连接减少 TLS 握手超时仅连接超时(3.05, 10)防止线程被 read 阻塞占满仔细看会发现从“快”到“稳”的转变里真正的瓶颈不是网络带宽也不是机器性能而是对目标系统行为模型的适配。4. 高频踩坑点与排查实录4.1 从状态码和响应头里读出风控信号服务器的每次拒绝都会留下线索只是很多人在 403 出现后就蒙了。我建议先看响应头里的几个字段然后再对照状态码做判断。常见状态码含义和排查方向很固定403 通常意味着访问被拒绝可能因为 UA 可疑、Cookie 缺失或 IP 信誉度低429 明确就是请求过多需要降低频率或延长退避413 是请求体过大常见于 POST 参数太长444 比较特殊表示连接被服务端直接关闭没有返回任何具体错误信息这种情况下大概率是四层或七层的 WAF 拦截5xx 则多数是服务端自身压力或临时故障可以适当重试。状态码含义优先排查项403拒绝访问UA、Cookie、IP 信誉、签名参数429请求过于频繁频率控制、退避时间、代理池切换413请求体超大POST 参数大小、上传数据压缩444连接被强制关闭WAF 拦截、TLS 指纹、HTTP2 特征503服务暂不可用服务端压力、本地重试节奏如果响应头里带了Retry-After字段一定按照它指定的秒数去等待这是服务器给你的明确信号比任何自适应算法都准。4.2 四个容易被忽略的“隐藏指纹”除了 Header 和 IP请求还会在更底层留下指纹其中最常见的四个是 TLS 握手特征、HTTP/2 帧设置、TCP 窗口大小和连接时区/语言偏好。TLS 指纹指的是客户端在 TLS ClientHello 消息里支持的加密套件顺序、扩展列表和椭圆曲线参数组合。同一个浏览器版本、同一个 OpenSSL 版本会生成固定指纹而 requests 默认使用的 urllib3/OpenSSL 组合和浏览器差异很大服务器可以通过 JA3/JA4 指纹识别出你用的是 Python 而不是 Chrome。HTTP/2 的指纹则体现在 SETTINGS 帧、窗口大小、优先级树等参数上这些细节很难伪造但也没必要伪造。真正合规的做法是不要对抗指纹检测而是努力让自己的运行环境和登录环境保持一致比如尽量使用同一种客户端技术栈不要一会儿 Python 一会儿浏览器地混着来。TCP 窗口大小的作用类似操作系统内核参数不同会产生不同特征本地 Linux 默认窗口比 Windows 大很多。这个一般不需要调整但你要知道一旦被深度检测它不是靠设一个 Header 就能解决的。最后一个容易被忽略的是时区和语言。如果系统时区和请求 Header 里的 Accept-Language 冲突比如系统是 UTC 而 Accept-Language 全是中文在细粒度风控里也是扣分项。用容器跑脚本时记得把TZ设为 Asia/Shanghai并在代码里固定业务时区。4.3 排查工具链抓包不只看请求还要看连接特征排查这类问题mitmproxy 和 Wireshark 是两件趁手工具。mitmproxy 比较适合抓 HTTP 层请求能直接看到 Header、Cookie、请求体和响应码方便快速定位是不是 Header 配置问题。Wireshark 则能看 TCP 层握手、TLS 版本、ClientHello 细节适合判断是否被底层指纹拦截。我的操作惯例是先用 mitmproxy 把本机发出的请求完整录一遍对比浏览器正常访问时的请求差异如果两者完全一致仍然被拦再上 Wireshark 抓包看 TLS 指纹和连接建立过程。在这个过程里需要在代理里明确排除掉涉密或者敏感流量避免造成数据泄露。日志也很关键。每个请求开始前记录目标 URL、请求序号、当前线程 ID结束后输出状态码、耗时和重试次数。结构化日志能让你在限流发生之后快速复盘“哪个时间点、哪些请求导致频率上升”这是所有后续调优的前提。4.4 一次“封 IP”事故的完整复盘这个故事来自我给一个模拟项目做数据同步的真实经历。当时为了赶批量任务我把线程数从 8 改成 32并且去掉了令牌桶限速理由是“目标接口响应很快应该扛得住”。结果五分钟后突然所有请求开始返回 429紧接着变成 403最后连首页都访问不了。复盘时发现根因不是单次请求违规而是 32 个线程在极短时间内的并发峰值为 12 QPS触发了服务端的 IP 级临时封禁。服务商面板显示的封禁时长大约一小时但我实际等待了近一个半小时才恢复。之后我做了三件事第一把令牌桶从可选组件改成强制组件任何请求进入线程池前必须经过令牌桶第二加了一层本地缓存相同参数的查询结果在 5 分钟内不重复请求服务端第三调整任务分片逻辑让批量任务从“一起涌进来”变成“每隔几十秒启动一批”。改完这套机制后面再没出现过 IP 级别的封禁问题。5. 最后聊点边界和长期主义我见过一些人把精力花在研究各种图像验证码的识别模型上但说实话这条路既费时又容易翻车。技术能力应该用来建设而不是用来对抗。合规使用公开接口、尊重目标系统的服务协议、保持请求的克制和理性不仅能保护自己也能让整个数据采集生态更健康。从我个人的使用体验来看这套优化思路的价值并不局限于“爬虫”。把它用到接口自动化测试、定时任务调度、性能压测里都能显著降低误报率。比如做接口巡检时如果请求频率设计得不好很容易把“服务挂了”的假警报发给值班群反而是自己把自己折腾得够呛。如果这篇文章对你有一点帮助你之后可以在本地跑一个模拟接口设置简单的限流中间件然后按文中提到的令牌桶、指数退避、并发计算自己去压一遍。只有亲手看到 429 变成 200你才算真正理解这些细节为什么重要。调优是一场长期博弈保持谦逊学会倾听服务器的信号比任何花哨技术都管用。
阅读完成 · 觉得有帮助？
