requests.get请求部分网站超时，headers在AWS Lambda失效排查

AI 小北

2026-8-29

配置请求头仅能解决部分因请求特征被识别为爬虫导致的无响应问题，无法覆盖所有超时场景。

你本地仅配置User-Agent就能请求成功，是因为Costco的基础反爬规则会直接拦截requests库默认携带的python-requests/版本号UA，而你本地使用的家庭宽带IP不在平台的高风险IP池中，仅靠UA就能通过第一层校验。

为什么部署到AWS Lambda后同样代码失效

Lambda环境下请求无响应，和请求头缺失的关联度其实不高，核心原因通常有两个：

AWS Lambda的公网出口IP属于公开的云服务IP段，早就被Costco这类电商站点划入高风险IP池，这类IP发起的请求只要带一点爬虫特征，甚至不会走完整的请求校验流程，直接被防火墙丢包，表现就是完全不返回响应、直到触发超时，连4xx/5xx状态码都不会返回。
你本地请求时的TLS握手指纹（JA3/JA4）和Lambda环境下requests库的TLS指纹不一致，就算UA和其他头完全匹配，指纹不符合真实浏览器特征也会被直接拦截。

你提到请求Google可以正常响应，这不能作为请求配置正确的依据——不同站点的反爬策略阈值差异极大，搜索引擎对云IP爬虫的容忍度远高于零售电商站点。

定位具体拦截原因的实操步骤

按从易到难的顺序排查，不要一开始就盲目堆砌请求头：

先确认常规请求头的差异
本地打开你配置UA对应的Firefox 101版本浏览器，开启开发者工具的网络面板，清空记录后访问Costco首页，找到第一个对https://www.costco.com的文档请求，把除了Host、Content-Length这类requests会自动生成的字段之外的请求头全部复制到你的代码里，重点补全Accept、Accept-Language、Accept-Encoding、Connection、Upgrade-Insecure-Requests这几个基础字段，先测试一次。
不要随便从网上抄年代久远的请求头，尤其是Sec-Fetch-*系列的字段，值和当前浏览器版本不匹配反而会触发更严格的校验。
排查IP层拦截
如果补全所有常规头之后还是超时，给请求加一个和你本地网络同区域的住宅代理配置，重新发起请求。如果加代理之后立刻能拿到正常响应，就说明根本原因是Lambda的出口IP被风控，这种场景下你改再多请求头都没有意义。
代理配置的示例代码：
```
proxies = {
    "https": "http://你的住宅代理地址:端口"
}
page = requests.get("https://www.costco.com", headers=headers, proxies=proxies, timeout=15)
```
排查TLS指纹校验
如果换了住宅代理还是超时，问题就出在TLS指纹上：requests依赖Python标准库的ssl模块完成TLS握手，生成的JA3指纹和真实Firefox浏览器的指纹差异非常明显，现在多数有强反爬的站点都会校验这个特征。
这种场景下不用再折腾requests的配置，直接替换成curl_cffi库，它可以直接模拟真实浏览器的TLS指纹，不需要手动调整加密套件配置，示例代码：
```
from curl_cffi import requests

page = requests.get(
    "https://www.costco.com",
    headers=headers,
    proxies=proxies, # 如果需要代理就加，不需要就去掉
    impersonate="ff101", # 直接模拟Firefox 101的全量请求特征，包括TLS指纹
    timeout=15
)
```

补充说明

你遇到的“无任何响应直接超时”的现象，90%以上的概率不是缺某个请求头字段，而是IP被拦截或者TLS指纹不匹配——这两种场景下站点的防火墙会直接丢弃请求数据包，不会返回任何响应内容。

内容的提问来源于stack exchange，提问作者OSUDamian