动态住宅 IP 与静态住宅 IP（ISP）的区别：什么时候该用固定出口

核心差异只有一句话

两者都归属住宅 / ISP 网段，匿名度处在同一水平。唯一的本质区别是：动态住宅的出口会变，静态住宅的出口固定不变。

由此推导出所有适用边界。

一个对照表

维度	动态住宅 IP	静态住宅 IP（ISP）
出口是否变化	按会话或请求轮换	长期固定
归属网络	家庭宽带为主	ISP 直接分配
池子规模	极大	较小，按区域分配
计费方式	通常按流量	通常按 IP 数 / 时长
登录态保持	难，IP 变化触发验证	容易
适合的任务	公开数据大规模采集	账号与环境管理

为什么”出口固定”对登录态这么关键

大部分平台的风控会给每个账号维护一个环境画像，出口 IP 是其中权重很高的一个维度。如果账号今天从上海的 IP 登录，明天从洛杉矶的 IP 登录，后天又从法兰克福，系统会判定为异常登录，触发二次验证甚至直接风控。

动态住宅代理的问题正在这里：它设计上就是为了让出口不断变化，这和”账号需要稳定的网络身份”这个需求是矛盾的。你当然可以通过粘性会话把出口维持一段时间，但会话有效期通常以分钟计，撑不过一个长期运营的账号。

静态住宅 IP 解决的正是这个矛盾：出口注册在某个固定区域，长期不变，账号的登录环境因此保持稳定。

反过来也别用错

最常见的浪费是用静态住宅 IP 去做海量公开页面采集。这类任务不需要固定出口，却要为”固定”这个特性付费，成本可能是动态住宅的数倍。

判断标准很简单：

• 需要登录、且登录态要长期维持 → 静态住宅
• 只是读取公开页面 → 动态住宅或数据中心

落地方式：一个账号一个 IP

静态住宅 IP 的正确用法是把它当作账号基础设施来管理，而不是当作通用出口。落地时有四点需要固定下来：

1. 一个账号对应一个 IP，不要多个账号共用一个出口。共用会被关联，是最容易被命中的风控模式。
2. IP 的地区要与账号注册地、语言、时区一致。用美国 IP 配中文界面和亚洲时区，是不必要的风险。
3. 做好台账。记录每个 IP 的分配区域、启用时间、绑定的账号。IP 出现问题时能快速定位影响范围。
4. 不要在同一个 IP 上频繁切换账号。需要切换时，先确保上一个账号的会话已完全退出（清 Cookie 和本地存储）。

配合浏览器持久化上下文使用，环境一致性最好：

# 一个账号 = 一个固定出口 IP + 一个独立的浏览器 profile 目录
context = pw.chromium.launch_persistent_context(
    user_data_dir=f"./profiles/{account_id}",     # 独立的 cookie / localStorage
    proxy={
        "server": "http://gateway.example.com:8080",
        "username": f"用户名-session-{account_id}",  # 每个账号绑定的粘性会话
        "password": "密码",
    },
    locale="en-US",
    timezone_id="America/Los_Angeles",
)

关键在于 user_data_dir 和粘性会话 ID 都按账号隔离。这样即使代理侧会话失效，本地环境也不会和其他账号混在一起。

成本结构上的取舍

静态住宅按 IP 数量计费，所以成本与账号数量线性相关；动态住宅按流量计费，成本与抓取量相关。这意味着：

• 账号数量少但抓取量大 → 静态住宅 + 动态住宅组合，账号走静态、采集走动态
• 账号数量多 → 静态住宅的成本会快速上升，需要评估是否每个账号都需要独立固定 IP

多数项目的最优解是两个都用：静态住宅专门负责账号环境，动态住宅负责所有数据读取。这两类流量在成本上的比例通常是 1:20 甚至更悬殊，分开计费能省下不少。

小结

动态与静态住宅代理不是”好”和”更好”的关系，而是服务两类不同需求：读取数据用动态，维持身份用静态。混用这两类需求，无论选哪一个都会有一部分预算被浪费。