验证码识别失败主因是目标网站反爬机制,需动态构造请求参数、严格匹配请求头与cookie、正确上传图片及codetype,并确保验证码获取与提交间状态一致、时效合规、ip行为正常。

验证码识别失败时,requests 返回的 200 响应里却没图
很多爬虫卡在这一步:发请求拿到响应,response.status_code == 200,但 response.content 是空的、乱码、或返回了“请启用 JS”之类提示。这不是打码平台的问题,是目标网站做了反爬——比如用 JavaScript 动态生成验证码 URL,或校验 Referer/UA/cookie 是否匹配登录态。
实操建议:
- 用浏览器开发者工具(Network → Img)抓到真实验证码图片的请求 URL,注意它是否带时间戳、随机参数(如
/captcha?t=1712345678901),这类参数必须每次动态构造 - 检查请求头:
Referer必须和上一页一致,User-Agent要和你模拟登录时用的一致,且 cookie 必须包含有效的 sessionid - 如果图片地址是 base64 内嵌在 HTML 里的(比如
data:image/png;base64,...),别直接当 URL 请求,要先提取 base64 字符串再解码为 bytes
调用打码平台 API 时,post 提交的字段名和格式容易错
主流平台(如超级鹰、打码兔、云打码)都要求 POST 图片二进制数据,但字段名不统一:image、pic、file 都可能出现;有的还要额外传 codetype(如 1902 表示 4 位纯数字),漏了就直接返回“参数错误”。
实操建议:
- 用
files={'image': ('captcha.png', image_bytes, 'image/png')}方式上传,别用data传 raw bytes,否则服务端收不到文件 -
codetype不是随便填的,得查平台文档对应表;例如超级鹰的1902是“4位字母数字”,而9004是“中文+英文+数字”,选错识别率断崖下跌 - 别忽略返回的
err_no字段:值为0才代表成功,-10001是账号余额不足,-10004是图片格式不支持(比如传了 WebP 却只认 PNG/JPG)
识别结果拿到后,submit 表单时被服务器拒绝
常见现象是:打码平台返回了正确字符串(比如 "Ab3x"),但 POST 登录表单时服务器返回 "验证码错误" 或 403。问题往往不在识别本身,而在「验证码和提交动作之间状态脱节」。
实操建议:
- 验证码有生命周期,从下载到提交一般不能超过 60 秒;如果中间加了人工确认、调试断点、或识别耗时过长(某些平台平均 2~5 秒),很可能已失效
- 确保提交请求的 cookie 和获取验证码时完全一致,尤其注意
PHPSESSID、JSESSIONID等会话标识是否被 requests.Session() 自动维护住 - 有些网站把验证码 ID(如
captcha_id=abc123)藏在隐藏字段里,提交时必须一并带上,否则服务端无法关联识别结果
本地测试能过,上线后批量识别成功率暴跌
本地跑 10 次全对,部署到服务器或用代理池后,识别率掉到 30% —— 大概率是 IP 或行为特征触发了平台风控。打码平台本身会对高频、同 UA、同 IP 的识别请求限流或降权。
实操建议:
- 每个打码账号每天有调用上限(如超级鹰免费版 100 次/天),超限后返回的
err_no是-9999,不是网络错误,别重试 - 避免短时间密集请求:两次调用间隔至少 1.5 秒,用
time.sleep(1.5)控制节奏,比加线程锁更稳妥 - 如果用代理 IP,确保代理能正常加载图片(有些代理不支持二进制传输),可先用
curl -x http://your-proxy -F "image=@captcha.png" https://api.xxx.com/invoke手动验证通路
真正麻烦的从来不是“怎么调 API”,而是验证码背后那套动态生成、绑定会话、限时校验、IP 关联的机制。漏掉其中一环,识别结果再准也没用。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!











