搞过 Amazon 爬虫的同学都知道,Amazon 的反爬机制很夸张——503、CAPTCHA 没完没了、IP 说封就封。
但商品名称、价格、评分、评论这些结构化数据又确实是做价格监控、竞品分析的核心素材。
技术选型
不同的采集规模,应对策略完全不一样:
- 轻量化 / 学习场景:Python +
requests+BeautifulSoup,自己拼 Headers 就能跑起来,适合小规模验证想法 - 高对抗 / 高匿名场景:上 Mobile Proxies(移动代理),模拟真实手机用户行为,信任度最高,但成本和延迟也跟着上来
- 企业级 / 大规模生产:使用代理 IP 池。可以看看蜻蜓代理
移动代理信任度最高,但慢且贵;
机房代理(Datacenter Proxy)快且便宜,但极易被识别为非真实流量。
身份伪装:绕过第一道防线
直接用 requests 默认配置访问 Amazon,大概率直接触发 503。最基础的伪装就是构造真实的请求头:
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.5"
}
response = requests.get(url, headers=headers)
这一步解决的是最基础的机器人检测——让你的请求看起来像个真浏览器。但这远远不够,Amazon 还会检测 TCP/IP 指纹一致性,光靠 Headers 很容易露馅。
动态代理轮换:让每次请求都"不一样"
真正有效的方案是引入住宅代理(Residential Proxy)或移动代理(Mobile Proxy),实现动态 IP 轮换,模拟来自不同地域的真实有机流量:
proxies = {
"http": f"http://{USERNAME}:{PASSWORD}@proxy.example.com:60000",
"https": f"http://{USERNAME}:{PASSWORD}@proxy.example.com:60000",
}
response = requests.get(url, headers=headers, proxies=proxies)
通过认证代理转发请求,隐藏真实源 IP,同时利用 IP 轮换机制让每次请求看起来都来自不同的真实用户。
在实际对抗 Amazon 这种级别的反爬系统时,我们在架构中接入了 蜻蜓代理,主要看中其代理节点的真实性和动态轮换的稳定性——高并发场景下 IP 封禁率确实降了不少,节点资源也比较充裕,对长时间运行的采集任务比较友好。
数据解析:精准提取目标字段
身份问题解决了,接下来就是提取数据。用 CSS 选择器精准定位 Amazon 页面的关键元素:
- 商品标题:
#productTitle - 价格:
.a-price-whole - 主图:
#landingImage - 评分星级:对应的 CSS class
生产环境的坑与对策
性能瓶颈
- 移动代理延迟较高,只适合高价值、难抓取的页面
- 大规模采集建议结合 ISP 代理,兼顾速度与匿名性
- 数据导出用 Pandas 汇总
page_data列表再批量导出 CSV,IO 效率会好很多
反爬对抗三板斧
- TCP 指纹一致性:确保指纹参数始终一致,别在这一步暴露爬虫身份
- 行为模拟:加入点击、滚动、鼠标移动等操作,模拟真实用户浏览行为
- 多维度轮换:User-Agent 轮换 + 自动 CAPTCHA 解决服务组合使用
动态渲染处理
- Amazon 部分内容依赖 JavaScript 动态渲染,纯
requests拿不到 - 这种场景需要引入 Playwright 或 Selenium 做浏览器自动化
错误处理与降级
- 实时监控 500/400 系列错误码
- 触发 503 或验证码时,立即强制轮换 IP
- 为解析器设置 fallback CSS 选择器,应对页面布局突然变化
进阶:往工程化方向走
- 云端存储:采集结果直接聚合到 S3、GCS 等对象存储,降低大规模数据传输成本。国内的话,就看看阿里云、腾讯云。
- AI 增强:将爬虫与 AI Agent 结合,可以实现更智能的数据清洗和结构化处理
本土化落地注意事项
- 合规红线:严格避免采集个人隐私数据、受版权保护的内容或需要登录才能查看的数据
转载请注明
- 蜻蜓代理 - 移动代理反爬实战 - Amazon数据采集方案
- 头条号 - 蜻蜓软件
- 微信公众号:蜻蜓软件(qingtingsoft)

