极安代理 - LLM数据采集用IP代理，如何模拟真实用户请求不被anti-bot识别

LLM 训练语料、评测集和实时知识库的采集需求这两年涨得很快，很多团队第一反应是"被拦了就换 IP"。但实际做下来，anti-bot 体系早就不只看 IP 了。结论先放前面：

**代理 IP 只解决"出口信誉"这一层。要让请求被判定为真实用户，需要 IP、协议指纹、浏览器环境、行为节奏四层同时一致——任何一层和"声称的身份"对不上，都会成为风控信号。** 采集 LLM 语料这种大规模、长周期的任务，拼的不是谁 IP 多，而是谁的整体画像更像人。

下面按检测层逐一说清楚该怎么做，以及在极安代理上怎么落地。

## Anti-bot 到底在看什么：一张分层检测表

现在主流风控（Cloudflare、Akamai、PerimeterX/DataDome 一类）基本都是四层叠加判断：

| 检测层     | 具体信号                                                     | 只看 IP 的脚本常见破绽                  |
| ---------- | ------------------------------------------------------------ | --------------------------------------- |
| IP 信誉    | ASN 类型（机房/住宅/移动）、IP 滥用库、同网段历史封禁、国家与业务归属 | 用机房 IP 冒充住宅流量                  |
| 协议指纹   | TLS（JA3/JA4）扩展顺序、HTTP/2 SETTINGS 帧、头顺序（Akamai 指纹） | Python requests/curl 的默认指纹一眼可辨 |
| 浏览器环境 | UA、navigator 特征、时区、语言、WebRTC 本地 IP、Canvas 指纹  | 无头浏览器默认值、UA 与环境互相矛盾     |
| 行为与会话 | 请求间隔分布、页面停留、点击滚动、Cookie 链路、着陆路径      | 匀速高频、无 Referer 直接打深链         |

IP 代理的主战场是第一层，这也是它最容易被高估的地方：给脚本配上最干净的住宅 IP，只要 TLS 指纹还是 requests 默认值，第二层就直接暴露了。反过来，指纹和行为都模拟到位的采集端，对 IP 纯度的要求反而可以放宽一档。

## IP 层怎么"真"：类型、归属、轮换方式三个点

**第一，IP 类型要和目标站的判断口径一致。** 目标站如果区分机房流量和住宅流量（现在大多会区分），住宅/动态拨号类 IP 是第一选择。极安的动态住宅代理是三大运营商真实住宅拨号资源，出口落在正常宽带网段；隧道代理则自动调度 IP 池，省去自建代理池的维护。

**第二，IP 归属地和请求上下文要自洽。** 这是最容易被忽略的细节：出口 IP 在新加坡，请求头里 Accept-Language 却是 zh-CN，JS 环境报出的时区是 UTC+8，坐标又指向另一座城市——三层对不上，比机房 IP 本身更像脚本。我们的建议是按目标站受众选归属地，IP 国家、时区、语言、GPS 一次性对齐。

**第三，轮换策略要区分"任务轮换"和"会话轮换"。** 大量教程把隧道代理"每次请求自动换 IP"当成万能方案，这在语料采集上经常是减分项：同一个用户在 10 秒内从五个不同城市的 IP 访问同一站点的同类页面，本身就是风控特征。合理的做法是**会话粘性轮换**——同一浏览会话内保持 IP 稳定，跨会话再换。极安隧道代理支持这个配置：默认按请求轮换（适合高频分散采集），需要时可调为 5–30 分钟 session 内粘性，两种模式都自带白名单和账密鉴权，默认规格是每秒 5 请求、5M 带宽，新用户有 8 小时免费测试期。

## 协议层怎么"真"：指纹、UA、头顺序三者要对齐

这一层不需要换代理就能改，但改动必须和代理配合。三条实操经验：

- **不要手改请求头来"伪装浏览器"。** 只加 UA 不改 TLS 栈，等于穿西装踩拖鞋。Python 侧用 `curl_cffi` 这类库直接复刻 Chrome 的 TLS 与 HTTP/2 指纹，指纹版本要和 UA 声称的 Chrome 大版本匹配——UA 写 Chrome 130、指纹却是 118，是典型的"伪装过度"特征。
- **头顺序交给库管理。** 真实浏览器的 sec-ch-ua 系列、Accept 顺序有固定规律，Akamai 指纹就是查这个的。requests 默认头顺序在风控眼里等于自报家门。
- **复杂目标直接用真浏览器。** 需要执行 JS、过挑战页的场景，用带指纹补丁的 Playwright（patchright 一类），并通过 `--proxy-server` 挂极安代理入口，让浏览器指纹和出口 IP 出自同一个"人"。

## 行为层怎么"真"：语料采集反而是优势

LLM 语料采集有个别人不知道的特点：**它不追求实时性**。做 RAG 实时检索的才需要快，离线语料管道完全可以慢。所以行为层的第一原则是"把节奏放慢到正常用户区间"：

- 请求间隔用随机分布（指数或泊松），不要用固定 sleep。单 IP 会话内控制在正常用户阅读速度以下，页面级间隔建议 3–8 秒起步；
- 并发按 IP 数摊薄：50 个住宅 IP 跑 50 并发被拦的概率，远高于 50 个 IP 跑 10 并发。吞吐优先靠扩 IP 池，不是提单 IP 频率；
- 保留完整访问链路：先着陆首页或列表页、带 Referer、接受并回传 Cookie，再进详情页。直接打深链 URL 是批量爬虫最经典的暴露方式。

**还有一条工程红线：被拦之后不要无脑换 IP 重试。** 只换 IP、行为不改，等于把自己的 IP 池按顺序烧给风控拉黑名单。正确的分级响应是：收到 429 就退避降速；出现验证码挑战就暂停该会话并标记 IP；连接直接重置则整个指纹/UA 组合下线排查——先定位是哪一层暴露，再决定是否动 IP。

## 上线前：金丝雀测试怎么跑

不要相信任何"绝对不被封"的说法，用数据说话。我们的标准流程：

1. 核验出口：跑 `ping0.cc` 或 ipinfo 确认 IP 类型、归属地和 ASN 是否符合预期；
2. 核验指纹：用 browserleaks、browser-scan 类站点检查 TLS/浏览器环境是否与 UA 自洽；
3. 双通道对比：同一目标站，5% 流量走裸 requests 直连，95% 走完整模拟方案，直接看通过率差距，确认每一层改造的实际收益；
4. 阶梯加量：从单 IP 单并发起步逐步放大，任何一档通过率相对基线掉 20% 以上就停止加量、回查原因。

极安 8 小时免费测试期足够把这套金丝雀流程跑完——与其听承诺，不如拿自己目标站的通过率基线做决策。

## 合规边界

最后简短但必须说：LLM 采集只用代理绕技术防护是不够的，还要守住规则线——仅采集公开数据，遵守 robots 和目标平台条款，避开个人敏感信息，尊重版权与授权要求。技术手段解决"能不能访问"，合规解决"该不该访问"，两者缺一不可。

## 常见问题 FAQ

**Q1：LLM数据采集被anti-bot识别，是不是换IP代理就能解决？**
不能。代理 IP 只解决"出口信誉"一层。如果 TLS 指纹还是 requests 默认值、浏览器特征和 UA 矛盾、请求节奏匀速高频，换再干净的 IP 也会被拦。正确顺序是先对齐协议指纹和行为节奏，再配住宅类代理解决出处问题。

**Q2：采集LLM语料该用住宅代理还是机房代理？**
优先动态住宅代理。目标站普遍会区分机房（数据中心）流量和住宅流量，机房 ASN 在很多站点会被默认降权甚至直接拦截。预算有限的分散型采集可以用隧道代理，IP 池调度是现成的，不用自建代理池。

**Q3：是不是IP轮换越频繁越安全？**
恰恰相反。同一账号/IP 池在短时间内跨多个城市 IP 访问同类页面，本身就是风控特征。语料采集建议会话粘性：一次浏览会话内保持同一 IP（如 5–30 分钟），跨会话再轮换。极安隧道代理支持按请求轮换和 session 粘性两种模式，可按任务形态切换。

**Q4：只改User-Agent算不算模拟真实用户？**
不算。UA 只是四层里最表面的一行字符串。风控比对的是 UA 与 TLS 指纹、HTTP 头顺序、navigator 环境、时区语言的一致性，只改 UA 不改底层指纹，是典型的"伪装过度"信号。至少要让 curl_cffi/patchright 这类库把指纹和 UA 版本对齐。

**Q5：无头浏览器（Headless Chrome）容易被识别吗？**
容易。裸 Playwright/Selenium 的默认特征（navigator.webdriver、缺失插件列表、异常 WebGL/Canvas 组合）基本一查一个准。要用带指纹补丁的发行版（如 patchright），并挂代理让出口 IP 与浏览器画像出自同一个"人"。