网页抓取住宅代理：轮换、Sticky 会话、验证与排错

住宅代理适合需要地理路由、会话控制或更大出口池的网页抓取任务，但它不是绕过反爬或安全控制的保证。生产环境更重要的是：先证明请求确实经过预期出口，再验证页面结果、错误类型和成本，最后才逐步扩量。

本文给出一套可复现的上线流程：从 curl 验证代理，到区分轮换与 Sticky 会话，再到 Playwright 配置、错误分类、地理验证和停止条件。示例中的主机名、账号和会话格式都是占位值；具体凭据格式以你的代理供应商控制台为准。

如果你正在评估 BytesFlows，可先查看住宅代理产品页，但本文不会把产品页上的成功率、延迟或覆盖数字当成独立测试结果。

先判断住宅代理是否真的适合你的任务

住宅代理的核心能力是让请求通过住宅网络出口转发。它会改变目标网站看到的网络出口 IP，但不会自动改变浏览器指纹、账号状态、Cookie、TLS 行为或业务层身份。

更适合优先测试住宅代理的场景包括：

需要按国家或城市观察本地化内容；
需要较大的出口池来分散采集任务；
多步骤流程要求在一段时间内维持同一网络出口；
已经确认目标对不同网络类型返回明显不同结果，并且你有权限执行该自动化任务。

如果目标是低频公开页面、官方 API 已能满足需求，或者任务不依赖地理结果，直接请求、API 或机房代理通常更简单，也更容易控制成本。

合规边界：只采集你有权访问和处理的数据。遵守目标站点服务条款、robots/官方自动化政策、隐私要求和适用法律。遇到明确拒绝、登录限制、验证码、安全挑战或持续 403/429 时，应先确认授权与请求策略，而不是无限增加重试或代理轮换。

第一步：证明请求确实经过代理

不要一开始就拿复杂目标站做测试。先使用一个返回出口 IP 的诊断端点，确认“代理链路本身”工作正常。

bash

export PROXY_URL='http://USERNAME:PASSWORD@PROXY_HOST:PORT'

curl --fail-with-body \
  --silent --show-error \
  --max-time 20 \
  --proxy "$PROXY_URL" \
  https://api.ipify.org?format=json

验证时至少记录：

是否成功建立代理连接；
返回的出口 IP 是否与直连不同；
多次请求时 IP 是否按预期保持或变化；
失败发生在代理认证、网络连接还是目标站响应阶段。

--max-time 20 只是示例保护值，不是推荐 SLA。生产环境应根据目标站基线、队列超时和重试预算自行设置。

第二步：区分 Rotating 和 Sticky 的任务所有权

Rotating 与 Sticky 不是“哪个更高级”的问题，而是状态由谁拥有。

模式	更适合	主要风险
Rotating	独立页面、无状态任务、广覆盖采集	同一业务流程中出口变化可能破坏连续性
Sticky	多步骤流程、短期会话、需要出口连续性的任务	单出口承担过多请求，且供应商会话 TTL 可能到期

Sticky 的 session id、用户名拼接方式和 TTL 不是互联网标准，不同供应商格式不同。不要把某个供应商的账号字符串复制成通用协议规则。

用 curl 验证会话行为

如果供应商提供 Sticky 凭据，可以固定同一个会话标识连续请求，并比较出口 IP：

bash

for i in 1 2 3; do
  curl --fail-with-body \
    --silent --show-error \
    --max-time 20 \
    --proxy "$STICKY_PROXY_URL" \
    https://api.ipify.org?format=json
  echo
  sleep 2
done

预期结果取决于供应商策略。三次 IP 相同只能证明这一次实验窗口内保持一致，不能证明未来一定持续同样时长。

第三步：同时验证网络地理位置和页面结果

只查一次 IP 数据库不足以证明业务层 GEO 正确。建议分两层验证：

网络层：记录出口 IP、国家/地区/城市与 ASN；
应用层：检查目标页面实际返回的币种、语言、库存、搜索结果或其他本地化字段。

IP geolocation 天生存在误差。MaxMind 官方文档明确说明地理位置是近似结果，并建议结合 accuracy_radius 理解城市级坐标。因此不同 GeoIP 数据库给出不同城市并不自动代表代理路由错误。

把验证结果保存成结构化记录更容易排错：

json

{
  "requested_country": "US",
  "exit_ip": "203.0.113.10",
  "geo_country": "US",
  "geo_city": "Chicago",
  "page_currency": "USD",
  "http_status": 200,
  "usable": true
}

上面的 IP 是文档示例地址，不代表真实代理出口。

第四步：在 Playwright 中按 BrowserContext 隔离代理会话

Playwright 官方支持为 BrowserContext 配置代理。Context 也会隔离 Cookie 等浏览器会话数据，因此很适合把“业务会话”和“代理会话”放在同一个生命周期里管理。

javascript

import { chromium } from 'playwright';

const server = process.env.PROXY_SERVER;
const username = process.env.PROXY_USERNAME;
const password = process.env.PROXY_PASSWORD;

if (!server || !username || !password) {
  throw new Error('Missing PROXY_SERVER / PROXY_USERNAME / PROXY_PASSWORD');
}

const browser = await chromium.launch();
let context;

try {
  context = await browser.newContext({
    proxy: {
      server,
      username,
      password,
    },
  });

  const page = await context.newPage();
  const response = await page.goto('https://example.com', {
    waitUntil: 'domcontentloaded',
    timeout: 30_000,
  });

  if (!response) {
    throw new Error('Navigation completed without an HTTP response');
  }

  console.log({
    status: response.status(),
    url: page.url(),
  });
} finally {
  await context?.close().catch(() => {});
  await browser.close();
}

30_000 毫秒同样只是示例值。不要因为代理存在就无限放大导航超时；否则任务队列会被慢请求长期占用。

官方参考：Playwright Network / HTTP Proxy↗ 与 BrowserContext↗。

407、403、429 和 timeout 要分开处理

不同错误属于不同层级，不能都归因于“IP 质量差”。

现象	优先检查	不应该直接做什么
407 Proxy Authentication Required	代理账号、密码、权限、认证格式	盲目切换目标 URL
403 Forbidden	目标权限、账号状态、请求方法、页面政策和安全控制	假定换 IP 一定能解决
429 Too Many Requests	`Retry-After`、请求速率、账号/Cookie/资源级限流	把限流简单理解为单 IP 限制
Connect/Read timeout	代理网关、出口、DNS、目标站和客户端超时分别定位	无限重试
GEO 不一致	出口 IP、GeoIP 数据源、accuracy radius、页面业务结果	仅凭一个数据库判定线路错误

RFC 9110 对 407 的定义是代理要求客户端进行认证；RFC 6585 对 429 的定义是请求过多，并明确没有规定服务端必须按 IP 来识别或计数用户。因此，轮换 IP 不是通用的 429 修复方法。

官方参考：RFC 9110↗、RFC 6585↗。

第五步：用“可用结果”而不是 200 比例衡量效果

生产采集更值得关注的是 usable result：请求不仅成功返回，而且数据满足业务校验。

可以为每个任务记录：

HTTP 状态；
是否命中登录页、验证码或挑战页；
目标字段是否存在；
GEO 是否满足任务要求；
重试次数；
下载字节数；
最终是否产生可用记录。

一个简单的成本指标是：

plain text

每个可用结果成本 = 总代理成本 / 可用结果数量

如果两种线路的 GB 单价不同，只比较“成功率”可能得出错误采购结论。应该使用同一组目标 URL、同一时间窗口、同一并发策略和相同的数据质量规则做小规模 A/B 验证。

建议的有限重试策略

重试前先判断错误是否可能是瞬时故障。可以重试的典型情况包括偶发连接失败、连接重置和部分 5xx；认证错误、权限拒绝、明确的合规停止条件通常不应该自动重试。

一个安全的默认思路是：

设置总尝试次数上限；
使用退避，而不是立即循环；
对 429 优先尊重服务端 Retry-After；
设置单任务总时间预算；
达到失败阈值后进入人工检查或隔离队列。

不要把“轮换到新 IP”作为所有异常的第一动作，否则既会增加流量成本，也会掩盖真正的认证、目标权限或应用逻辑问题。

上线检查清单

直连与代理出口 IP 已分别记录；

Rotating / Sticky 行为已经独立验证；

Sticky TTL 和账号格式来自当前供应商文档，而不是经验猜测；

GEO 同时做网络层和页面结果验证；

407、403、429、timeout 使用不同错误分类；

重试次数和总耗时有明确上限；

数据质量校验不只依赖 HTTP 200；

凭据通过环境变量或密钥管理系统加载，没有写入代码仓库；

已确认目标站点授权、服务条款、隐私和停止条件；

小流量实验通过后才增加并发或预算。

FAQ

住宅代理一定比机房代理更适合网页抓取吗？

不一定。住宅代理解决的是网络出口和路由选择问题。如果目标允许自动化访问、没有 GEO 要求，而且机房线路已经满足可用结果和成本目标，就没有必要为了“更像真人”而强制使用住宅代理。

Rotating 模式是否应该每个请求都换 IP？

不一定。轮换粒度由供应商和任务决定。独立任务可以更频繁轮换，多步骤流程则通常需要保持出口连续性。先验证实际会话语义，而不是假定“每请求必换”。

Sticky 会话能保持多久？

没有通用标准。持续时间、最大 TTL、断线后的重新绑定行为都是供应商特定能力，应以当前产品文档和实际测试为准。

429 是否代表当前 IP 被封？

不能这样判断。429 表示服务端认为请求过多，但 RFC 6585 没有限定服务端按 IP 计数；账号、Cookie、资源或整个服务都可能参与限流。

城市级代理为什么和 GeoIP 查询结果不完全一致？

IP 地理定位是估算结果，不同数据库可能使用不同数据源和更新时间。应结合 accuracy radius、多个数据源以及目标页面实际本地化结果判断，而不是把单次城市差异直接当成代理故障。

结论

网页抓取中的住宅代理应该被当作可测量的网络组件，而不是“自动绕过封禁”的黑盒。先验证出口，再验证 GEO 和业务结果；把 Rotating 与 Sticky 和业务会话绑定；将认证、限流、权限和网络错误分层处理；最后用每个可用结果的成本决定是否扩量。

如果需要测试 BytesFlows 的住宅线路，可从住宅代理产品页获取当前支持能力与配置入口。产品页上的网络规模、成功率、价格和覆盖范围属于供应商当前公开声明，实际生产效果仍应使用你自己的目标和验收标准验证。