← 全部文章
应用案例 1 分钟阅读

大规模聚合房地产房源

房地产门户网站使用不同的反机器人技术栈、布局和地理位置。以下介绍如何在大规模聚合房源的同时，避免维护六个不同的爬虫程序。

real-estateweb-scrapingproxy-rotationanti-botdata-aggregation

面临的挑战

你的团队发布了一款房源产品。它正常运行了三周。然后 Zillow 更改了 DOM，Rightmove 收紧了机器人检测，你的爬虫在一个周末内就在六个数据源中的四个上失效了。

房地产聚合面临着价格监控和 SERP 跟踪所没有的特定问题。你不是从一个干净的 API 中提取结构化数据。你需要拼接来自各个门户网站的房源信息，而这些网站各自使用不同的反机器人技术栈、不同的布局、不同的地理位置和不同的更新节奏。美国的 Zillow，提供 MLS 数据的 Redfin，英国的 Rightmove，澳大利亚的 realestate.com.au，德国的 Immobilienscout24。每个门户网站都是一个独立的工程项目。

根据 Scrapfly 在 2026 年的研究，顶级的房地产门户网站会检查连接层面的签名，并拒绝与浏览器级别握手特征不匹配的客户端。他们的 Rightmove 指南 详细介绍了嵌入在 JavaScript 变量中的 JSON 数据，其结构每几个月就会发生变化。Redfin 将房产数据分散在几十个 DOM 节点中，因此一次布局微调就可能导致一半的字段同时丢失。区域性门户网站还会根据访问者所在的国家或地区提供不同的内容，这意味着位于美国的爬虫在 realestate.com.au 上抓取不到任何有用的信息。

结果是：你的房源新鲜度在不知不觉中下降。三分之一的房产信息在 48 小时内过时。你的用户看到的是上周的价格。你的销售团队开始遇到阻力，客服工单在周一激增，因为门户网站的布局通常在周末发生变化。

解决方案

大规模聚合房源不是一个抓取问题。它是一个伪装成抓取问题的可靠性问题。为什么你的爬虫总是失效 涵盖了一般情况。房地产行业放大了其中的每一个环节。

任何能很好处理此问题的平台都需要四样东西协同工作。第一，与真实浏览器匹配的 request 签名 (不仅仅是看起来像浏览器的 User-Agent 字符串，而是 Zillow 和 Rightmove 用来区分机器人和人类的实际网络层细节)。第二，在每个目标市场中具有地理准确性的住宅 IP，因为德国的聚合器不能向 Immobilienscout24 发送美国数据中心的流量并期望得到有用的 response。第三，基于主机的 proxy 路由，因为在 Zillow 上有效的策略在 realestate.com.au 上会失效。第四，对于将所有内容推送到客户端的门户网站，需要将浏览器渲染作为后备方案。

通过 FourA 的 proxy 产品向 Rightmove 发起的示例 request 大致如下：

curl -X POST https://api.foura.ai/api/proxy/ \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 5,
    "timeout_ms": 45000,
    "request": {
      "method": "GET",
      "url": "https://www.rightmove.co.uk/properties/123456",
      "unblocker": true,
      "followRedirects": 5,
      "validate": {
        "status": {"accept": [200]},
        "data": {"fail": ["blocked", "access denied"]}
      }
    }
  }'

unblocker 标志会注入完整的浏览器 header 集合以及匹配的网络层签名。maxTries: 5 告诉 proxy 管理器在最多五个 IP 之间轮换，直到其中一个成功。验证规则可捕获静默拦截：返回软拦截页面而不是房源数据的 200 response。因此，你的成功率反映了实际起作用的内容，而不是 HTTP 状态所声称的内容。

通过 JavaScript 提供所有内容的门户网站 (Redfin 就是一个明显的例子) 需要真实的浏览器渲染。我们的浏览器产品使用完整的浏览器实例来处理这些情况，而不是在首次连接时就被标记的轻量级模拟器。在 2026 年，机器人检测转向了行为分析，任何非真实浏览器的工具都越来越容易被发现。

成果

当房地产聚合器从自定义抓取技术栈切换到 API 优先的方法时会发生什么？我们在实际运营中看到的模式如下 (基于行业基准的说明性场景)：

  • 活跃市场的房源新鲜度从“48小时内更新”提高到“2小时内更新”
  • 爬虫维护的工程时间减少了 70%。只需一名轮值工程师，而不需要专门的团队
  • 门户网站覆盖范围从 6 个站点扩展到 20 多个，而基础设施并未按比例增加
  • 一旦验证规则捕获到软拦截，受保护门户网站上的静默拦截率将降至 3% 以下

使用我们平台的团队呈现出一种模式：一旦共享了可靠性层，添加新市场就变成了配置更改，而不是一个冲刺周期。有趣的问题从“为什么又坏了”变成了“我们接下来应该添加哪个门户网站”。

诚实的局限性：需要登录会话的房地产门户网站 (一些 MLS 系统，某些仅限中介查看的视图) 需要在 request 基础设施之上进行账户管理。这是一个我们无法解决的独立问题，你不应信任任何声称能解决该问题但未解释如何实现的人。

关键要点

房地产是少数几个过时数据不仅仅是个麻烦的行业之一。它是产品的失败。时尚网站上一周前的价格只是轻微的尴尬。在热门市场中，一周前的房源意味着你的用户刚刚询问了一套周二就已售出的房子。

但是，在此领域获胜的团队并不是拥有最多数据源的团队。而是那些不再为每个新门户网站重建相同的 proxy 和反机器人管道的团队。一旦共享了该层，有趣的工作就开始了：数据质量、新鲜度 SLA、跨门户去重、价格趋势分析。这才是产品。底层的一切都应该顺畅运行。