# 推出 Auto：适用任意目标的统一 endpoint

> URL: https://foura.ai/zh/blog/auto-endpoint
> Updated: 2026-09-27
> Index: https://foura.ai/llms.txt

## 更新内容

`/api/auto` endpoint 现在是获取任意 URL 可用 response 的最简路径。直接传入目标地址。Auto 会自动决定是通过 Single、Proxy Finder 还是 Browser 执行 request，在遇到页面验证时自动处理，并返回可供下次调用复用的 session。

单个 endpoint。支持任意目标。无需由你手动切换模式。

这就是核心逻辑。本文接下来将介绍其运作机制、计费方式以及需要注意的边界情况。

## 工作原理

Auto 底层采用阶梯式策略（成本由低到高）。每次发起 request 时，Auto 会沿阶梯逐步尝试，直到某一级别返回符合你 `validate` 规则的 response。

执行层级依次为：

1. **缓存的 session。** 如果 Auto 保留了之前调用该 host 时生成的可用 session，会优先复用该 session。这是成本最低的路径。
2. **Proxy Finder。** 轮换 proxy request。适用于主要依靠 IP 声誉防护的站点。
3. **Browser。** 完整渲染页面，执行 JavaScript，完成页面要求的验证，并收集站点发放的 cookie。

一旦某个级别请求成功，Auto 会保存找到的 session：包括所使用的 proxy id、站点下发的 cookie 以及 User-Agent。下次请求相同 host 时，Auto 会优先尝试该 session。如果仍然有效，你只需支付低成本级别的费用，无需承担高成本开销。

基础调用示例：

```bash
curl -X POST "https://api.foura.ai/api/auto" \
  -H "X-API-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'
```

截断后的 response：

```json
{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}
```

有两个字段对你后续的构建至关重要。`meta.rung` 会告诉你哪个路径最终胜出。`session` 是你可以带入 `/api/single` 调用中的三元组，用于自行重放相同的 exit。`proxy` 字段是一个不透明的 base36 ID（不含原始 IP），可安全记录到日志中，也可在系统之间安全传递。

## 影响

这里有两个关键数字。

对受保护站点的首次调用会运行 Browser 层级：渲染、解题、收集 cookie 并向你交付页面。这大约消耗 10 个 credits。一旦 Auto 为该主机缓存了可用的会话，后续调用就会直接重放：通过 Single 消耗 2 个 credits，或者在会话的 cookie 可从任意地址使用时通过 Proxy Finder 消耗 4 个 credits。因此，第二次调用的成本最高可比第一次便宜 5 倍，并且只要会话有效，之后的每一次调用都会保持这一低廉费率。我们在灰度发布期间在生产环境中测量了这一表现：无 cookie 的 exit（一旦找到）重放成本正好是每次调用 2 个 credits，而在所有 request 都经过 Proxy Finder 时，成本曾经是 10 个 credits。

第二个数字：失败的层级不会计费。如果 Auto 尝试了三个 proxy 且每个都在第四个 proxy 成功交付前返回 403，则仅对第四个 proxy 的 credits 计费。你只为交付的内容付费，而不是为搜索过程付费。

这就是核心价值所在。高成本的层级运行一次，低成本的层级在此后一直运行，而且你无需自行编写缓存逻辑。

另外两项行为也值得一提，因为它们解决了实际生产中的痛点：

**受地理限制的目标不再浪费 exit。** 当一个站点对大多数 exit 返回 451（或法律拦截插屏页面）时，Auto 会学习哪些国家确实交付了内容。在下一次调用中，它会优先从这些国家获取新的 exit，并在它们之间分配并发负载。因此，单个侥幸成功的 exit 不会被过度请求而触发 rate limit。

**Validate 在每个层级上运行。** 内容错误的页面（例如返回状态码 200 但正文为法律通知的国家限制页面）绝不会被算作命中。如果你的 `validate.data.fail` 包含 "legal reasons"，Auto 会持续尝试，直到某个层级通过验证。无论缓存层级还是其他任何层级都不例外。如果没有任何层级通过，你将获得一个包含真实原因的明确失败结果。

## 进阶功能

当你通过 Auto 跑大流量时，以下几个配置参数会发挥作用。

`timeout_ms` 是整个操作的总预算，而不是单个层级的预算。默认值为 120 秒。Auto 会对其进行分配：每个子调用获得 min(其固有超时时间, 剩余预算)，并且一旦剩余时间过短，调度阶梯就会停止启动新层级。对于交互式延迟敏感的任务，可设置为 20,000。对于容忍较长尾部延迟的批量爬取任务，保留默认值即可。

`forceProxy` 默认开启。除非你设置了 `forceProxy: false`，否则 Auto 绝不会使用 FourA 的源 IP 访问目标。需要注意的一点是：某些站点（带有 IP 信任门禁的交互式 Cloudflare）在干净的数据中心 IP 下的表现实际上优于低信任度的住宅 exit。因此，`forceProxy: false` 可能会让某些目标变得更容易处理，而不是更难。如果你在特定主机上反复遇到 challenge，尝试关闭此项是值得一试的方法。

`ignoreProxies` 是客户端规避列表。传入已知失效的 proxy id（例如来自先前在你方触发 rate limit 的 `session.proxy`），Auto 会在所有环节跳过它们：热 session 复用、出口节点检索以及对 Proxy Finder 的子调用。因此 Auto 不会重新选择你刚指定规避的出口节点。

`meta` 还支持在其基础上构建自定义仪表盘：今日触发浏览器层级的 host、单次交付的平均尝试次数、解决 challenge 的抓取与正常抓取的比例。如果某个特定 host 的消耗突然从 2 credits 飙升到 10 credits，这就是 session decay 信号，你可以在账单激增前及时处理。

组合这四项功能的示例：

```python
import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"X-API-Key": "pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])
```

关于 `validate` schema 本身，请参阅 [Validate Rules Now Decide What Counts as Success](https://foura.ai/blog/validate-decides-success) 中的早期说明。

## 后续规划

Auto 目前有两项计划中的功能。

Session 检查功能即将进入 Dashboard。目前 Auto 为每个 host 保留的 session 都存放在服务内部，当你在排查额度消耗问题时无法直接查看。我们正在构建每个 host 的 session 视图，方便你查看已缓存的 session、存活时间、剩余有效期以及每次调用的梯级历史记录。此外还会提供手动清理 session 的按钮，以便在目标站点发生变化且确认缓存失效时直接丢弃。

之后是更严格的成本控制。包括单次请求积分硬顶（单次调用绝不超过 X，若超出则直接报错失败），以及面向目标站点完全不需要浏览器梯级的团队的“仅单次”模式。这两项功能目前均处于 feature flag 控制下。

Auto 的核心在于让你无需纠结该调用哪个产品。但这并不意味着你无法了解实际执行细节。每个 response 都会返回所走的梯级和构建的 session。查看这两个字段，你就能准确获知每次调用的成本来源。