爬虫开发者第一次撞上 SPA（Single Page Application），通常是这种场景：浏览器里点一个分类标签，列表刷出来了；用 requests 拉同一个 URL，HTML 里只有 <div id="root"></div> 和一坨打包后的 JS，看不到任何业务数据。切到列表第二页、第三页，URL 末尾的 query 甚至都不变，抓取链路直接断了。
问题不在抓取工具本身，而在 SPA 的渲染模型：数据不是随 HTML 一起返回的，是页面加载后由 JS 再发起异步请求拿到的，而“页面跳转”在 SPA 里根本不是真正的页面跳转。要稳定抓到这种数据，必须先理解路由切换背后到底发生了什么，再决定走哪条抓取路径。本文拆解这套机制，给出可落地的策略，并解决工程落地时绕不开的一个核心问题——路由切换后会话与代理 IP 的一致性。
一、SPA 路由跳转的本质：客户端路由 + 异步数据请求
服务端渲染（SSR）时代，一个 URL 对应一段完整 HTML，requests.get(url) 拿到 HTML，BeautifulSoup 解析 DOM，业务数据直接在标签里。爬虫的逻辑简单到能一句话概括。
SPA 把这套模型拆了：
- HTML 只是个壳。服务端返回的 HTML 通常只有一个挂载节点（如
<div id="app"></div>）和打包后的 JS bundle。真正的 DOM 由 JS 在浏览器里渲染生成。 - 路由是客户端行为。点击导航、切换 Tab、翻页，这些“跳转”由前端路由库（Vue Router、React Router 等）拦截，根据 URL 变化（hash 或 History API）在前端切组件，不会向服务端重新请求整个 HTML 文档。
- 数据靠异步请求拿。路由切到新视图时，组件挂载或路由守卫触发，前端用 XHR、Fetch 或 WebSocket 向后端 API 发请求，拿到 JSON 后再渲染到 DOM。
直接后果：DOM 上没有静态数据可解析，传统 HTML 解析路径失效。你看到的“页面变了”，是 JS 改了 DOM；你抓到的 HTML，永远是那个空壳。
更隐蔽的难点在于路由切换的时机。SPA 路由切换是异步的：URL 先变，组件再挂载，数据请求再发出，响应回来后 DOM 才更新。抓取时如果只盯着 URL 变化或 DOM 出现某个元素，往往会在数据还没就绪时就动手，拿到空数据或半截数据。判断“数据真正加载完成”的时机，本身就是 SPA 抓取的一个核心问题。
二、SPA 数据抓取的五大核心难点
把 SPA 抓取拆开，真正费劲的是这五件事：
- 路由切换时机不可预测。前端框架决定何时切路由、何时发请求，没有统一的“加载完成”事件。你监听 DOM 变化，可能抓到的是骨架屏；你监听网络请求完成，可能漏掉组件二次触发的请求。
- 动态接口定位困难。业务数据来自哪个接口？接口路径往往是
/api/v2/xxx/list这种被 webpack 压缩、混淆过的，参数还可能携带签名、时间戳、加密 token。光找到接口还不够，还要逆向出参数怎么构造。 - 鉴权与会话保持。SPA 普遍依赖登录态，会话标识通过 Cookie、Authorization 头、或请求体里的 token 维持。一次请求拿不到数据，往往不是接口错了，而是会话没带对。
- 反爬与限制。目标站点会做行为检查：检测鼠标轨迹、校验浏览器指纹（Canvas、WebGL、UA-CH）、限制同 IP 请求频率、要求 JS 执行特定逻辑生成签名。直接复现接口有时会被指纹校验拦下。
- IP 一致性要求——这是最容易被忽视的坑。SPA 在路由切换后通常复用同一个浏览器会话，登录态、Cookie、token 都绑在这个会话上。如果你的代理 IP 在路由切换过程中频繁变化，目标站点的风控系统会把“同一会话来自不同 IP”判为异常，轻则触发验证码，重则直接封会话。SPA 的抓取对 IP 稳定性有天然要求，不是随机换 IP 越多越好。
三、数据抓取策略的分层选择
面对 SPA，不要一上来就开浏览器。策略要按“成本由低到高、覆盖由窄到宽”分层选择。
策略一：直接复现接口（效率最高，但有前提）
- 思路：用浏览器 DevTools 或抓包工具（Charles、mitmproxy）打开目标页面，切到 Network 面板，触发路由切换，观察真正返回业务数据的那个请求。找到后，直接用
requests或httpx复现这个接口，拿 JSON。 - 优点：快、轻量、并发度高。一个接口请求几十毫秒，比开浏览器快两个数量级，资源开销低。
- 前提和代价：必须搞定鉴权（Cookie、Authorization、CSRF token 缺一不可）；接口如果带签名，得逆向签名算法。指纹校验强的站点，纯接口复现会被风控拦下，这时只能退回策略二。
策略二：浏览器自动化渲染（覆盖最广，成本最高）
当接口签名逆向不动、风控要求真实浏览器指纹、或页面数据由 WebSocket 推送时，回到浏览器自动化：用 Playwright 或 Selenium 启动真实浏览器，触发路由切换，等待数据加载完成后，再从 DOM 或拦截到的网络响应里取数据。
关键是等什么、怎么等：
waitForResponse(url_or_predicate)：等到匹配某个接口的响应返回。最精准，适合你已经知道目标接口 URL pattern 的场景。例如：page.wait_for_response("**/api/list**")。waitForSelector(selector)：等到某个 DOM 元素出现。适合你不确定接口、但知道数据渲染到哪个元素的场景。注意要等到真正有内容的元素，别等到骨架屏。networkidle：等到 500ms 内没有网络请求。粗粒度兜底，能保证页面“安静下来”，但某些长连接（WebSocket、轮询）会让它一直等不到 idle。
四、关键工程问题：路由切换后的会话与 IP 一致性
这是 SPA 抓取工程化时绕不开的硬骨头，也是策略二（浏览器自动化）最容易踩坑的地方。
SPA 的会话模型是长会话：用户打开页面，登录后拿到 token/Cookie，整个浏览过程（包括所有路由切换、所有异步请求）都复用这个会话。从风控视角看，“一个正常用户”应该是：同一个浏览器指纹、同一个会话标识、同一个出口 IP，从头到尾不变。
如果你的代理在每个请求上都换 IP（典型的动态转发行为），风控系统看到的就是：同一个 Cookie、同一个 session token，但 IP 一直在跳。这在真实用户行为里几乎不可能出现，被判定为机器人或账号被盗的概率极高，轻则弹验证码，重则封 session、封账号。
所以 SPA 抓取的代理选型，核心不是 IP 多，而是同一会话内 IP 要稳。这一点直接决定了你应该用哪种代理调度模式。
五 & 六、代理服务的调度模式场景演练
以常见高性能网络爬虫代理为例，针对不同场景对号入座选择调度模式：
| 抓取场景 | 适用代理模式 | 技术特征与实现原理 |
|---|---|---|
| 场景一：浏览器自动化抓 SPA（策略二） | 固定转发模式 | 在固定时间窗口（如1-3分钟）内保持同一个出口代理 IP 不变，兼容 Playwright/Selenium 的长会话，模拟真人生命周期。 |
| 场景二：有状态接口复现（接口依赖/分页/多步操作） | Proxy-Tunnel 自主切换 | 通过请求头携带自定义标识（如 Proxy-Tunnel: 随机数）控制。相同标识的请求走同一 IP，绑定业务会话粘性。 |
| 场景三：大规模无状态批量采集（策略一） | 动态转发模式 | 每次请求随机分配 IP，适合高频多线程并发抓取独立接口数据。（绝对不适用于浏览器自动化） |
HTTPS 下的 KeepAlive 行为与 IP 切换机理
HTTPS 下代理 IP 是否切换，受连接复用影响。代理服务器的核心通用规则如下：
- HTTPS 默认开启 KeepAlive：同一 TCP 会话（连接池里的同一个连接）内代理 IP 保持不变。
- 想保持同 IP：设置
Connection: Keep-Alive和Proxy-Connection: Keep-Alive编，主动复用同一连接。 - 想强制每请求换 IP：设置
Connection: Close和Proxy-Connection: Close，关闭连接复用，强迫建立新 TCP 会话。
七、完整工程可运行示例：Playwright + Proxy-Tunnel 抓取实战
下面给出一个贴近真实工程的示例：用 Playwright 启动浏览器，通过特定的 Proxy-Tunnel 模式访问一个 SPA，登录后切换路由，等待数据接口响应并精准抓取。
import random
import json
from playwright.sync_api import sync_playwright
# 亿牛云代理参数配置（请替换为实际订单参数）
PROXY_HOST = "代理域名" # 例如 xxx.16yun.cn
PROXY_PORT = "端口" # 例如 端口号
PROXY_USER = "你的用户名"
PROXY_PASS = "你的密码"
# 用一个固定的随机数作为 Proxy-Tunnel，保证整组请求流走同一出口 IP
# 不同会话 / 不同并发用户应更换不同的随机数
TUNNEL_ID = str(random.randint(100000, 999999))
def build_proxy_auth_header(tunnel_id):
# 构造发给代理的额外请求头。相同 Tunnel 值在访问目标网站时保持同 IP 粘性
return {
"Proxy-Tunnel": tunnel_id,
}
def crawl_spa():
with sync_playwright() as p:
# 配置代理：用户名密码认证走 Playwright 原生能力，避免手动塞头导致匿名失效
proxy_opts = {
"server": f"http://{PROXY_HOST}:{PROXY_PORT}",
"username": PROXY_USER,
"password": PROXY_PASS,
}
browser = p.chromium.launch(
headless=False, # 调试阶段可见界面
proxy=proxy_opts,
)
context = browser.new_context(
user_agent=(
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0.0.0 Safari/537.36"
),
# 注入 Tunnel 标识头，绑定整个生命周期的 IP 一致性
extra_http_headers=build_proxy_auth_header(TUNNEL_ID),
)
page = context.new_page()
print("[1] 正在打开 SPA 入口页面...")
page.goto("[https://example.com/](https://example.com/)", wait_until="domcontentloaded")
print("[2] 正在模拟执行登录流...")
page.fill("#username", "your_account")
page.fill("#password", "your_password")
page.click("#login-btn")
# 核心：精准等待登录接口响应完成
page.wait_for_response("**/api/login**")
print("[3] 触发客户端路由切换（点击导航）...")
page.click("text=订单列表")
print("[4] 精准拦截异步业务数据接口，绕过 DOM 渲染窗口期...")
# 精准匹配订单接口 URL Pattern
response = page.wait_for_response("**/api/orders/list**")
data = response.json()
print("【成功】抓到第一页订单数据：", json.dumps(data, ensure_ascii=False)[:300])
print("[5] 执行翻页操作（同一会话，Tunnel 保持，IP 保持一致）...")
page.click("text=下一页")
resp2 = page.wait_for_response("**/api/orders/list**")
data2 = resp2.json()
print("【成功】抓到第二页订单数据：", json.dumps(data2, ensure_ascii=False)[:300])
browser.close()
if __name__ == "__main__":
crawl_spa()
