网页抓取代理怎么选：机房、住宅、ISP 与移动代理实测选型指南

网页抓取代理怎么选：先选工作负载，再选代理类型

没有一种代理类型在所有网页抓取任务里都是“最佳”。真正需要比较的是：在你的目标站点、目标地区、会话模型和采集频率下，哪一种路由能以可接受的成本稳定产出可用数据。

机房代理、住宅代理、ISP 代理和移动代理的网络来源、可用地域、会话稳定性和计费方式通常不同，但这些差异并不能直接推出某一种代理一定更快、一定更难被识别或一定更适合某个网站。目标站点可以同时根据 IP、账号、Cookie、请求行为、浏览器状态和服务端策略做访问控制。

因此，选型时不要从“哪种代理最隐身”开始，而应从以下问题开始：

1. 你采集的是公开或已获授权的数据吗？
2. 结果是否必须来自特定国家、地区或城市？
3. 一个任务是否需要跨多个请求保持 Cookie、登录态或购物车状态？
4. 失败时，你能否区分代理认证、网络错误、限流、目标站拒绝和解析错误？
5. 供应商按 IP、端口、并发还是流量计费？
6. 最终应该优化的是请求成功率，还是每个可用结果的成本？

如果你已经确定需要住宅路由，可以继续阅读 网页抓取住宅代理；如果真正的问题是轮换时机，则参考 代理轮换策略。

四类代理的工程差异

这里故意没有填写“信任分”“被封概率”或固定延迟。它们不是可跨供应商、跨目标站稳定复用的行业常数。更可靠的做法是在你的真实目标上做小规模 pilot。

什么时候先测试机房代理

如果任务不依赖消费者网络位置，而且目标对你的访问方式没有额外限制，机房代理通常值得作为低复杂度基线测试。

典型场景包括：

• 你有权访问的内部或合作方站点；
• 对外开放、速率限制明确的公共接口；
• 静态页面或公开目录的低频采集；
• 需要高吞吐，但不要求消费者网络地域视角的任务。

不要因为一次 403 就得出“机房 IP 被封”的结论。403 只表示服务器理解请求但拒绝执行；实际原因可能与登录态、访问策略、请求路径、WAF、安全规则或其他条件有关。

什么时候住宅代理更有价值

住宅代理的核心价值不是“不可检测”，而是提供消费者 ISP 网络来源和地域路由能力。当业务结果确实受到访问地区影响时，这一点会很重要，例如：

• 地区化商品价格或库存验证；
• 本地 SERP 或广告展示 QA；
• 地域化页面、货币、语言或配送状态检查；
• 目标明确允许的市场研究与公开数据采集。

但“代理返回某城市 IP”并不等于应用层结果一定属于该城市。IP 地理定位本身存在误差，尤其城市级结果需要结合页面语言、货币、配送区域、SERP location 或业务字段再次验证。MaxMind 的官方说明也明确指出 IP geolocation 不能保证 100% 准确，且蜂窝、宽带、IPv4/IPv6 与 ISP 实践都会影响精度。

如果你的任务依赖地域，请至少同时保存：

{
  "requested_country": "US",
  "requested_region": "NY",
  "requested_city": "New York",
  "observed_exit_ip": "203.0.113.10",
  "geo_provider_country": "US",
  "page_currency": "USD",
  "page_locale": "en-US",
  "business_region_signal": "New York",
  "usable": true
}

其中 IP 和城市只是示例值。真正决定记录能否进入业务报表的，应是你的任务级质量规则，而不是单一 GeoIP 字段。

什么时候选择 ISP 或长驻路由

如果一个工作流需要较长时间保持同一出口身份，例如多页表单、分页流程、账号内 QA 或购物流程测试，频繁换 IP 反而可能破坏状态一致性。

此时应优先验证：

• 单个 session 能否稳定维持到任务结束；
• 供应商如何定义 sticky session；
• session 到期后是否会无提示换出口；
• 同一账号是否会跨多个出口并发；
• 失败恢复后是否应该复用原 session。

“每个请求换一个新 IP”不是通用最佳实践。对无状态、相互独立的请求，轮换可能有价值；对需要 Cookie、登录态、购物车或多步导航的流程，应该在业务任务边界内保持稳定。更完整的决策方式见 代理轮换策略。

移动代理不是“终极隐身”

移动网络确实具有不同于固定宽带和数据中心网络的地址分配与共享特征，但这不能推出“网站不会封移动 IP”或“移动代理天然能够绕过验证码”。访问控制还可能依赖账号、设备状态、Cookie、请求模式、浏览器执行环境和目标站政策。

只有在任务本身需要移动运营商网络视角时，移动代理才应该进入候选集，例如移动网络内容差异测试或经过授权的移动业务 QA。否则，应先通过 pilot 证明它相比住宅或 ISP 路由能提高可用结果率，并且增加的成本是合理的。

用真实 pilot 选代理，而不是看营销标签

建议为每一种候选路由使用同一批目标、同一时间窗口、同一解析器和相同并发运行测试。

最小测试矩阵

HTTP 429 Too Many Requests 也不能简单等同于“这个 IP 被限流”。RFC 6585 明确没有规定服务器必须按 IP 识别用户或计算请求，限流也可能与认证凭据、Cookie、资源或其他状态有关。因此，看到 429 时应先尊重 Retry-After（如果存在）、降低请求速率并检查任务身份，而不是无限换 IP 重试。

一个可复用的评分模型

不要硬编码供应商排名。把权重留给实际业务：

from dataclasses import dataclass

@dataclass
class RouteMetrics:
    usable_rate: float
    p95_seconds: float
    geo_error_rate: float
    retry_ratio: float
    cost_per_usable_record: float


def validate(m: RouteMetrics) -> None:
    bounded = [m.usable_rate, m.geo_error_rate, m.retry_ratio]
    if any(value < 0 or value > 1 for value in bounded):
        raise ValueError("rate values must be between 0 and 1")
    if m.p95_seconds <= 0 or m.cost_per_usable_record < 0:
        raise ValueError("latency must be positive and cost cannot be negative")


def score(m: RouteMetrics) -> float:
    validate(m)

    # 示例权重，不是行业基准。请按你的 SLA 和预算调整。
    return (
        0.45 * m.usable_rate
        - 0.20 * m.geo_error_rate
        - 0.15 * m.retry_ratio
        - 0.10 * min(m.p95_seconds / 30.0, 1.0)
        - 0.10 * min(m.cost_per_usable_record / 0.05, 1.0)
    )

这里的 30.0 和 0.05 只是演示归一化方法的示例值，不是 BytesFlows benchmark，也不是推荐阈值。生产环境应使用自己的 SLA 和真实成本替换。

Playwright 中如何验证代理路由

Playwright 当前官方 API 支持 HTTP 和 SOCKS 代理，并支持 HTTP proxy 的 username / password。下面的示例使用环境变量，避免把凭据直接写进代码仓库。

import asyncio
import os
from playwright.async_api import async_playwright


def require_env(name: str) -> str:
    value = os.getenv(name)
    if not value:
        raise RuntimeError(f"Missing required environment variable: {name}")
    return value


async def main() -> None:
    proxy_server = require_env("PROXY_SERVER")
    proxy_username = require_env("PROXY_USERNAME")
    proxy_password = require_env("PROXY_PASSWORD")

    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = None
        try:
            context = await browser.new_context(
                proxy={
                    "server": proxy_server,
                    "username": proxy_username,
                    "password": proxy_password,
                }
            )
            page = await context.new_page()
            await page.goto("https://example.com", wait_until="domcontentloaded", timeout=30_000)
            print(await page.title())
        finally:
            if context is not None:
                await context.close()
            await browser.close()


if __name__ == "__main__":
    asyncio.run(main())

PROXY_SERVER、用户名格式、国家/城市参数和 session 参数都是供应商特定配置。不要把任何供应商的用户名语法当作通用代理协议标准。

实际测试时应另外访问你有权使用的出口检测端点，记录出口 IP 与地域，再访问真实目标验证业务结果。不要把测试凭据、完整代理 URL、HAR、trace 或截图中的密码上传到日志或工单。

故障分类：先找失败层，再决定是否换路由

RFC 9110 对 407 的定义是代理要求客户端进行认证，并要求响应包含适用于该代理的 Proxy-Authenticate challenge。它与目标站的 401、403 或 429 不属于同一故障层。

采购前检查清单

FAQ

网页抓取一定需要住宅代理吗？

不需要。如果直连或机房代理能在授权范围内稳定返回正确数据，就没有理由仅为了“更像真人”而增加住宅代理成本。住宅路由最有价值的情况通常是任务确实需要消费者网络来源、地域视角或供应商提供的住宅 session 能力。

每个请求都应该换 IP 吗？

不应该。独立、无状态请求可以测试轮换；涉及 Cookie、分页、多步骤流程或登录态时，应在任务边界内保持稳定 session。轮换频率必须通过真实失败率和成本验证。

移动代理一定比住宅代理成功率更高吗？

没有可普遍验证的结论。成功率取决于目标、地区、运营商、会话、请求行为以及供应商实现。只有 A/B pilot 能回答你的工作负载是否值得增加移动路由成本。

IP 显示在目标城市，结果就一定是当地内容吗？

不一定。IP 地理定位存在误差，应用还可能结合 Cookie、账号、语言、GPS、配送地址等信号。城市级任务必须验证页面本身的业务地域信号。

最终应该看哪个指标？

优先看可用结果率和每个可用结果成本，然后结合 p95 完成时间、地域错误率、重试流量和会话稳定性。单独比较“IP 数量”或“平均延迟”通常不足以做生产选型。

结论

网页抓取代理选型不是“机房 < 住宅 < 移动”的等级升级路线。正确顺序是：定义业务结果 → 建立失败分类 → 用真实目标做小规模 pilot → 验证地域和 session → 计算每个可用结果成本 → 再决定扩大哪一种路由。

如果你的 pilot 已经证明需要消费者 ISP 路由，可以继续查看 网页抓取住宅代理；如果正在优化轮换与 sticky session，则参考 代理轮换策略。