Walmart 爬取代理基准测试：为何美国代理失效，什么方案真正有效

用通用美国代理抓取 Walmart 的失败率远比大多数教程承认的要高，即便这些 IP 被标榜为"精英"或住宅代理。问题的根源并不真正在于代理质量，而在于请求的分布方式、轮换方式和随时间的恢复方式，以及 Walmart 的反机器人系统如何在地区层面而非国家层面来评分流量。一个美国 IP 不再是通行证。

为了用数字说话，我们进行了一次对照基准测试：用通用美国代理池向 Walmart 公开产品和搜索页面发送 1000 个请求，再通过 Crawlbase Crawling API 向同一目标发送 1000 个请求。这里的所有内容都是我们在该测试中实际测量的数字，而非普遍常量，整个测试可从公开仓库复现，你可以针对自己的代理重新运行。前提说明：本文只涉及公开产品和价格页面。请遵守 Walmart 的服务条款、robots.txt 以及合理的请求速率，切勿触及账户或个人数据。

基准测试结果汇总

在进行任何分析之前，先看核心结果。三行数据讲述了大部分故事。

这就是全部故事。本文余下部分解释原因，以及是什么弥合了这一差距。

为何通用美国代理在 Walmart 上失效

大多数代理建议仍然假设美国 IP 足以抓取美国零售商。这一假设在接触 Walmart 时已站不住脚。现代反机器人系统不只看单一信号，它们会同时对多个维度给请求打分：

• IP 信誉。 出口地址是否有自动化或滥用流量的历史。
• 行为一致性。 请求模式看起来像真人还是循环程序。
• 会话复用。 Cookie 和会话的行为是否与真实浏览器一致。
• 地区流量集中度。 是否有少数几个位置突然产生大量流量。
• 请求频率。 单个地址或地址范围访问站点的速度。
• 基础设施指纹识别。 TLS、请求头顺序及其他暴露脚本身份的低层信号。

由于所有这些因素叠加在一起，来自同一国家的两个代理表现可以截然不同。在我们的测试运行中，一些 IP 短暂有效后迅速降级，另一些在第一次请求就失败，还有相当一部分返回 HTTP 200 却实际上提供了 CAPTCHA 或挑战页面，而非可用的 Walmart HTML。某些代理组比其他组失效快得多，这指向的是本地化信誉评分，而非简单的国家级过滤。

这就是为什么基准测试评分的是响应质量而非状态码。一个小型封锁检测器扫描每个正文中的反机器人标记，如果发现任何标记则将请求计为失败：

markers = [
    "robot or human",
    "verify you are a human",
    "access denied",
    "captcha",
    "blocked",
]

blocked = any(m in html.lower() for m in markers)

按正文而非状态码过滤，才得出了真实的 39.1%，而非你单纯信任 200 状态码所能得到的虚高数字。如果你曾花时间解码硬目标的响应码，关于代理状态错误码的分析文章解释了为何 403 和"软" 200 挑战需要不同的处理方式。

基准测试设置

测试使用两个 Python 脚本，针对相同的 Walmart URL。第一个脚本通过通用美国代理池运行（包括精英、匿名、透明和数据中心端点的混合），每次请求随机轮换，使用类浏览器的请求头，刻意禁用重试，并使用上述封锁检测器。第二个脚本通过 Crawlbase Crawling API 对相同目标运行。目标不是为了得出一个营销数字，而是在真实 Walmart 条件下测量现实的提取可靠性，这就是为什么响应验证和延迟追踪被嵌入到两个脚本层中。

一个请求只有在返回 HTTP 200、非空 HTML、可用内容且无反机器人标记时才计为成功。脚本追踪了成功率、响应时间、失败类型、CAPTCHA 页面、403、空 HTML 以及部分或损坏的内容。测试同时覆盖产品页和搜索页，两个脚本使用同一组 URL，确保对比是苹果对苹果。

完整测试结果

原始代理列表与托管爬虫编排之间的差距很快就显现出来了。通用代理在重复请求中表现不稳定：一些立即失败，另一些在几次良好响应后降级，许多返回了机器人页面尽管状态码是 200。Crawlbase 在相同目标上保持稳定，平均延迟更低，尽管它在内部处理了重试和路由工作。

两点值得关注。超过 40% 的通用代理请求触发了 Walmart 的机器人防护，近 20% 因代理失效或连接错误而彻底失败。而 Crawlbase 在完全相同的目标上保持近乎完美的提取率，同时平均延迟更低，尽管它在幕后完成了通用测试跳过的重试和路由工作。

为何常见建议不够充分

几乎每个 Walmart 教程都会出现三条代理建议。在基准测试中，三条建议都有所改善，但没有一条单独就够用。

"用住宅代理就行。" 住宅 IP 提高了成功率，因为它们更像消费者流量，但如果没有真正的轮换策略和地理分布，重复的行为模式仍然会触发反机器人系统。在整个测试运行过程中，重复使用相同地区的代理组会使提取质量下降。这方面的权衡在数据中心代理与住宅代理对比一文中有详细分析。

"随机轮换代理。" 随机不等于智能。通用脚本按字面意思随机选择：

proxy = random.choice(working)

这仍然会重用噪声 IP 范围，并持续将请求集中在相同地区，因此即便是健康的代理最终也开始返回封锁或部分 HTML。良好的轮换本身就是一门学问，在轮换住宅代理一文中有详细介绍。

"有美国位置就够了。" 这条建议失败最频繁。一些美国代理立即失效，另一些却能持续，尽管它们都来自同一国家。这种差异正是地区信誉评分和行为检测的特征，而非国家级过滤。选择美国出口让你进了门，但对于决定你是否能留下来的行为和信誉评分毫无作用。

真正有效的是什么：编排，而非代理数量

基准测试中最稳定的结果来自智能请求路由，而非向目标投入更多代理。流量必须动态分布在基础设施中，使其永远不会陷入重复的行为模式；重试处理比预期的重要得多。重用相同代理的朴素重试循环往往使情况更糟。真正有效的是一个能够做到以下几点的系统：

• 在地区间分配流量，而非集中于某处。
• 随着测试运行期间目标行为的变化而自适应。
• 从瞬时失败中恢复，而不是反复敲打一个失效的 IP。
• 避免一遍又一遍地重复相同的请求签名。
• 在代理池中进行智能路由，而非随机选择。

这就是管理代理列表和使用托管爬取层之间的区别。关于两者的差异以及各自何时是正确选择，回连代理与 Crawling API 对比一文有详细分析。

Crawlbase 的不同之处

关键点在于，Crawlbase 不是在暴露一个原始代理列表。它是一个托管爬取层，吸收了抓取像 Walmart 这样的硬目标通常强加给你的运营工作。你不需要自己构建代理轮换、会话管理、重试编排、地区路由和故障恢复系统，你只需将 URL 交给一个 API，那些层就会自动运作。这就是为什么基准测试可以跳过通用运行所需的自定义重试和路由逻辑，仍然达到 99.5%。同样的托管层思路适用于其他有防御的零售目标；这些模式可推广到电商网页抓取领域。

自行运行测试

基准测试完全可复现。公开仓库同时提供通用代理脚本和 Crawlbase 脚本，均指向相同的 Walmart 目标，因此你可以验证数字，而不必依赖别人的结论。

克隆仓库并进入代码目录：

git clone https://github.com/ScraperHub/us-proxies-for-web-scraping-best-residential-datacenter-options.git
cd us-proxies-for-web-scraping-best-residential-datacenter-options/code

创建虚拟环境并安装依赖：

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

用你自己的美国代理运行通用代理基准测试。--runs 参数控制每个 Walmart URL 被请求的次数，脚本验证真实提取成功率、CAPTCHA 页面、封锁响应、空 HTML 以及时序，而不只是读取状态码：

python generic_proxy_benchmark.py --proxy "174.138.168.76:8001" --runs 3

然后用你的 API 令牌运行 Crawlbase 基准测试。--runs 行为相同，验证逻辑相同，只是通过托管层路由：

python crawlbase_benchmark.py --token "YOUR_CRAWLBASE_TOKEN" --runs 3

Crawlbase 脚本在底层就是一个对 API 的单次 GET 请求：目标 URL、你的令牌，以及一个将请求固定到美国出口的国家参数。

curl --location 'https://api.crawlbase.com?url=https%3A%2F%2Fwww.walmart.com%2Fip%2FHP-14-Athlon-4-256-Blue%2F18634911593&token=YOUR_CRAWLBASE_TOKEN&country=US'

两个脚本输出可比较的指标（成功率、失败率、时序、CAPTCHA 页面、封锁 HTML、空 HTML 以及真实提取成功率），因此你可以在自己的机器上将通用代理与托管方案的结果并排对比。

为何每次成功的实际成本才是真正的衡量标准

便宜代理在原始价格表上胜出，在真实成本表上却输了。请求失败就需要重试，重试消耗带宽，工程师花费大量时间替换失效代理和调试封锁，而不是在交付价值。真正重要的数字是每次成功请求的有效成本，因为便宜代理在一半请求失败时会迅速变得昂贵。

这里的有效成本包含了重试开销、提取失败次数和开发者维护时间。原始代理成本在表格顶部看起来更便宜，但将这些成本计入后，在表格底部反而更贵。另外请注意，Crawlbase 的数字反映的是约 1000 次请求的第一价格档；随着规模扩大，每次请求的成本会下降，因此在生产规模下，差距会进一步向 Crawlbase 倾斜。

常见问题

我可以用通用美国代理抓取 Walmart 吗？

可以，但可靠性差且不可预测。在我们的基准测试中，通用美国代理只有 39.1% 的时间返回了有效的 Walmart HTML；其余的是机器人挑战页面、403、空正文或连接失效。通用代理可以用于少量临时请求，但大规模稳定提取需要适当的路由、重试处理和地区分发。

住宅代理是否足以抓取 Walmart？

单靠住宅代理是不够的。住宅 IP 能提高成功率，因为它们更像消费者流量，但 Walmart 还会随时间评估行为模式、请求频率、会话一致性和地区集中度。在测试中，类住宅代理往往一开始有效，但在来自相同地区的重复请求后逐渐降级，因此请求的分发和轮换方式与代理类型同样重要。

为何 Walmart 在使用美国代理时仍返回 403？

因为 Walmart 评估的维度远不止国家级地理位置。一个代理可能物理上位于美国，但由于 IP 信誉差或流量模式重复，仍然看起来可疑。基准测试中也出现了大量实际上是机器人挑战页面的 HTTP 200 响应，这就是为什么必须检查响应正文，而不只是状态码。

Crawlbase 只是一个代理服务吗？

不是。Crawlbase 是托管爬取层，而非静态代理列表。它不是把 IP 交给你自己管理，而是在一个端点后面处理请求路由、重试编排、轮换、会话处理、地区感知分发、JavaScript 渲染和封锁检测，因此你与一个 API 交互，基础设施工作在后台完成。

抓取 Walmart 合法吗？

本指南仅限于公开产品和价格页面。抓取公开数据通常是可辩护的，但你仍应遵守 Walmart 的服务条款、robots.txt 以及合理的请求速率，切勿收集账户或个人数据。如果项目需要超出公开页面的内容，正确的途径是数据协议，而非变通方法。

如何防止我的 Walmart 爬虫被封锁？

保持每个地区的请求速率较低，发送真实的浏览器请求头，通过验证响应正文中的封锁标记来判断封锁情况（而非依赖状态码），并使用智能轮换而非随机选择。更全面的应对方案见如何在不被封锁的情况下抓取网站，而将轮换、重试和封锁检测交给托管层可以消除大部分维护工作。

IK

Ian Kalvin

技术支持工程师 · Crawlbase

Crawlbase 技术支持工程师，从生产环境抓取与代理配置中真正出问题的第一线写作。

NZ

Neil Zamora

高级架构师 · Crawlbase

Crawlbase 高级架构师，专注大规模爬取背后的系统：代理轮换、反机器人韧性，以及隐藏这些复杂性的 API。