极安代理 - LangChain/LlamaIndex的RAG系统对接什么代理IP好？

最近有人问我，LangChain和LlamaIndex做RAG时，到底应该接动态代理、静态代理，还是直接上隧道代理？

我的判断是：**先别急着按代理类型选，先看RAG项目到底在请求什么。**

如果知识库里的内容来自本地PDF、企业数据库、对象存储或者内部接口，通常不需要代理IP。代理也不会让向量检索更准，更不能解决切片不合理、正文抽取不完整等问题。

真正需要考虑代理的，是RAG系统要定时抓取官网、文档站、资讯页等公开网页的情况。尤其是任务跑一段时间后开始出现403、429、请求超时，或者同一个地址偶尔只能拿到空页面，这时才需要把代理接入网页采集端。

## 别把所有网络请求都塞进同一个代理

我见过一种配置方式：直接设置全局`HTTP_PROXY`和`HTTPS_PROXY`，然后让网页采集、Embedding接口和大模型API全部走同一个代理。

开发阶段看起来省事，正式运行后却很难排查。

网页采集可能需要更换出口IP，而Embedding和大模型接口更看重低延迟、稳定连接和固定出口。如果两类请求共用一套动态代理，模型调用突然变慢时，很难马上判断是服务商接口波动，还是代理节点发生了变化。

因此，我更建议把网络出口拆开：

- 网页Loader单独配置采集代理；
- Embedding和大模型API使用稳定网络出口；
- 内部数据库、向量库和对象存储按原有内网链路访问。

这样做不是为了让架构看起来更复杂，而是出了问题后能快速定位：到底是网页没抓下来，还是后续处理失败。

## LangChain怎么接代理比较顺手？

LangChain的`WebBaseLoader`本身提供了`proxies`、`requests_per_second`、`session`和`requests_kwargs`等参数。采集普通静态网页时，可以把代理直接放在Loader中：

```python
import os
from langchain_community.document_loaders import WebBaseLoader

proxy_url = os.environ["RAG_PROXY_URL"]

loader = WebBaseLoader(
    web_paths=[
        "https://example.com/docs/a",
        "https://example.com/docs/b",
    ],
    proxies={
        "http": proxy_url,
        "https": proxy_url,
    },
    requests_per_second=2,
    continue_on_failure=True,
    requests_kwargs={
        "timeout": 20,
    },
)

documents = loader.load()
```

带账密认证的代理地址通常写成：

```text
http://用户名:密码@代理主机:端口
```

这里有个容易误判的地方：如果请求状态是200，但返回的正文很少，不一定是代理质量有问题。

不少文档站的主要内容需要JavaScript运行后才会出现。普通Loader拿到的只是初始HTML，这时继续更换代理通常没有意义，应该改用Playwright一类浏览器Loader。

我一般会先看响应状态、页面长度和关键正文是否存在，再决定是换代理还是换加载方式。只盯着“请求成功”这一个指标，很容易把解析问题当成IP问题。

## LlamaIndex要先看具体使用了哪个Reader

LlamaIndex的数据连接器比较多，不同Reader底层可能使用`requests`、`httpx`、浏览器或者第三方抓取服务，所以代理配置方式不一定相同。

对于能够读取系统代理环境变量的Reader，可以先这样配置：

```python
import os

os.environ["HTTP_PROXY"] = os.environ["RAG_PROXY_URL"]
os.environ["HTTPS_PROXY"] = os.environ["RAG_PROXY_URL"]

from llama_index.readers.web import SimpleWebPageReader

documents = SimpleWebPageReader(
    html_to_text=True
).load_data([
    "https://example.com/docs"
])
```

但这段代码不能直接套到所有Reader上。有些组件会关闭环境变量读取，有些异步客户端需要显式传入代理，还有些第三方Reader已经在服务端处理网页抓取。

正式接入前，最好确认当前Reader底层使用什么HTTP客户端，以及是否启用了`trust_env`。如果项目里的数据源比较多，我更倾向于在LangChain或LlamaIndex外面单独封装一个采集服务，先完成请求、重试、解析和去重，再把干净文本交给RAG框架。

这样以后更换Loader、向量库甚至RAG框架时，不需要重写整套代理逻辑。

## 公开文档采集，不一定要用住宅代理

假设任务只是每天更新几十个公开技术文档页面，我不会一开始就上大规模动态住宅代理。

先用稳定的HTTP代理或数据中心代理跑一轮，观察真实目标页面的成功率和延迟。如果页面能够持续正常访问，就没有必要为了追求“IP数量多”增加成本和调度复杂度。

这类任务真正需要关注的是：同一域名连续请求是否稳定、HTTPS连接是否正常、超时后能否换节点，以及长时间运行时成功率会不会明显下降。

代理池有多少IP只是资源规模，**这些IP在具体目标站上能不能稳定返回有效正文，才是RAG采集真正关心的结果。**

## 多网站定时更新，隧道代理通常更省事

当知识库要覆盖多个网站，而且每天都要增量更新时，我更倾向于使用隧道代理。

程序端只配置固定的代理入口，出口节点由代理服务调度。对于LangChain和LlamaIndex来说，Loader中的代理地址不需要频繁变化，也不用自己处理IP什么时候过期。

如果改用API提取式短效代理，就需要在程序里继续管理IP有效期、失效剔除、并发分配和重新提取。任务量不大时还能应付，异步任务一多，IP刚分配就过期、多个协程重复使用失效IP之类的问题很快会出现。

当然，如果团队本来就有成熟的IP池和健康检查服务，通过极安代理API提取短效代理会更灵活；如果只是想尽快把RAG采集任务跑稳定，固定入口的隧道代理通常更容易维护。

## 有登录和分页时，不要每次请求都换IP

我排查过一类比较典型的问题：第一页能够正常读取，翻到第二页却重新跳回登录页面。

Cookie一直保存在同一个Session里，看起来没有丢。最后才发现，两次请求虽然共用了Cookie，出口IP却发生了变化，目标站没有把它们识别为同一个连续会话。

这类任务不适合“每次请求自动换IP”，而应该让同一个账号、域名或采集任务在一段时间内使用同一出口。可以选择静态代理、长效代理，或者支持粘性会话的动态代理。

比较稳妥的调度方式是：

> 一个采集任务绑定一个Session和一个出口IP，分页完成或任务结束后再释放。

所以，代理轮换并不是越快越好。普通公开页面可以按失败次数或任务批次轮换；涉及Cookie、CSRF Token、登录状态和连续分页时，出口稳定通常比IP数量更重要。

## 地域化页面要让代理地区跟采集目标一致

有些网站会根据访问地区返回不同的语言、价格、库存或内容版本。

如果要给海外用户建立知识库，却使用国内出口采集，最终入库内容可能和用户真正看到的页面不一致。后续不管怎么调召回参数，大模型回答的仍然是错误地区的数据。

这时要根据业务目标选择对应国家或城市的代理资源，并把地区信息写入文档元数据。例如：

```python
metadata = {
    "source": url,
    "market": "US",
    "language": "en",
    "collected_at": collected_at,
}
```

后续检索时就可以按市场或语言过滤，而不是把多个地区版本混在一个索引里。

## 我会怎么测试一套RAG采集代理？

正式购买前，我通常不会只打开IP检测网站，看出口地址变了就结束测试。

更有效的做法，是从真实知识源里选20至50个代表性URL，其中既要有普通详情页，也要有分页、重定向和动态页面。然后让任务连续运行一段时间，记录：

- 200、403、429和超时分别出现多少次；
- 请求成功后，正文是否真的提取出来；
- P50和P95响应时间是否稳定；
- 同一会话中出口IP是否意外变化；
- 失败重试后，是代理恢复了，还是页面依旧为空；
- 单次更新消耗了多少流量。

比如100个URL都返回200，但其中30个页面正文长度不到200个字符，这套链路仍然不能算70%之外全部成功。对于RAG来说，“拿到HTTP响应”和“拿到可以入库的有效文档”是两件事。

采集日志里至少应保留目标域名、代理节点、响应状态、耗时、重试次数和正文长度。否则某天知识库更新量突然少了一半，很难快速分清是代理失效、网站改版，还是解析规则出了问题。

## LangChain/LlamaIndex到底选哪种代理IP？

如果只是少量公开页面，可以先测试稳定的数据中心代理，不必过度轮换。

如果要长期采集多个网站，又不想自己维护IP池，优先考虑隧道代理：程序连接固定入口，出口由后端调度。

如果团队已经有IP池、健康检查和任务调度能力，可以使用API提取式短效代理，自己控制节点分配和更换时机。

如果任务涉及登录、分页和连续会话，应选择静态代理、长效代理或支持粘性会话的动态代理，不要设置成每次请求换出口。

如果内容存在国家或城市差异，则需要选择对应地区的代理，并在入库时保留地区元数据。

对刚开始搭建Web RAG的团队，我的建议是：**先用固定隧道入口跑一批真实目标网站，再根据失败日志决定是否需要住宅资源、地域节点或更复杂的IP池。**

先验证任务，再扩大资源，通常比一开始采购大量IP、写一套复杂轮换系统更省时间。极安代理可以根据目标网站、并发规模和会话要求提供不同接入方式，但最终选择仍应以真实URL的持续测试结果为准。

## 常见问题

**Q：LangChain配置代理后，为什么还是抓不到正文？**

先确认页面是否依赖JavaScript。如果返回的是初始空壳HTML，应更换浏览器Loader或网页解析方案。代理只能改变请求出口，不能替代页面渲染。

**Q：RAG采集时应该多久换一次IP？**

没有统一间隔。无状态公开页面可以按任务批次或失败次数轮换；登录、分页和连续抓取应在同一任务内保持出口稳定。

**Q：为什么请求成功率很高，入库文档却很少？**

HTTP请求成功不代表正文有效。还需要检查重定向、页面长度、编码、正文选择器、去重规则和异常处理。

**Q：极安代理应该选短效代理还是隧道代理？**

不想自己维护IP池，可以优先测试隧道代理；已经具备节点提取、健康检查和并发调度能力，可以使用短效代理。两种方案都应先用真实目标URL测试，不建议只根据IP数量决定。