API 批量提取动态住宅代理 IP 时怎么设计重试机制？

API 批量提取动态住宅代理 IP 时，先把“提取 API 失败”和“使用已提取代理 IP 请求目标站失败”分成两条链路。提取接口的认证、参数、库存和配额错误不能靠换代理 IP 解决；连接超时、临时 5xx 和部分 429 才适合有限重试。每次重试都要有等待、随机抖动、次数上限和任务总时限。

将提取 API 与目标站请求分开处理

提取 API 返回 200 和一组代理 IP，只证明“资源获取成功”，不代表目标 URL 一定成功。业务请求出现 407，通常属于代理认证问题，不应回到提取 API 无限重试。

先用错误矩阵决定是否重试

空结果和网络失败必须分开统计。筛选条件过窄或当前资源不足时，重复同一请求不会自动产生可用结果。

提取参数和白名单流程可对照动态住宅 IP API 提取教程。

为临时错误设置指数退避、随机抖动和总时限

提取 API 的重试参数怎么设置

以下参数只针对提取 API 的临时网络错误、429 和 5xx；认证失败、参数错误、白名单不匹配或明确的业务空结果应走人工处理分支。

可以先用下面这组参数做小样本基线，再根据接口限制、任务时限和实测错误率调整：

• 最大尝试次数：4 次，包括首次请求；
• 基础等待：1 秒；
• 最大单次等待：30 秒；
• 随机抖动：0–500 毫秒；
• 单任务总时限：60 秒；
• 429：若有 Retry-After，优先采用服务端给出的等待时间。

连接超时与读取超时应分别记录和处理：前者通常发生在建立代理连接阶段，后者表示连接建立后响应迟迟未完成。两者都可以有限重试，但应使用不同的错误统计，避免把目标站响应慢误判成代理连接失败。

Python 重试代码示例

下面代码只处理提取 API 的有限重试；目标站业务请求应使用另一套错误分类。代码中的尝试次数、总时限和退避上限要与任务调度配置保持一致。

```python
import random
import time
import requests

RETRYABLE = {429, 500, 502, 503, 504}

def extract_with_retry(url, params, headers):
started = time.monotonic()
last_error = None

for attempt in range(4):
if time.monotonic() - started >= 60:
raise TimeoutError("提取任务超过总时限")

try:
response = requests.get(
url,
params=params,
headers=headers,
timeout=(5, 15),
)

if response.status_code == 200:
data = response.json()
if not data:
raise ValueError("提取结果为空，需检查筛选条件或库存")
return data

if response.status_code not in RETRYABLE:
response.raise_for_status()

retry_after = response.headers.get("Retry-After")
if retry_after and retry_after.isdigit():
wait = min(float(retry_after), 30)
else:
wait = min(1 * (2 ** attempt), 30)

except (requests.ConnectTimeout, requests.ReadTimeout, requests.ConnectionError) as exc:
last_error = exc
wait = min(1 * (2 ** attempt), 30)

if attempt == 3:
break

time.sleep(wait + random.uniform(0, 0.5))

raise RuntimeError("提取 API 达到重试上限") from last_error
```

如果响应状态是 200 但 JSON 解析失败，也应记录为响应格式异常并纳入任务停止判断，不要把它当成空结果继续放大请求量。

达到重试上限后，应将任务标记为失败或转入人工复核队列，并保留最后一次状态码、错误类型和脱敏响应摘要。认证错误和参数错误不应进入该重试循环。

生产环境如何处理 Retry-After 与延迟调度

生产环境还要完整解析 Retry-After，因为它除了秒数，也可能使用 HTTP 日期格式。不要在等待期间占用大量同步工作线程；高并发任务更适合异步调度或延迟队列。

共享限流器应按 API、账号或任务维度设置。任务达到总时限后，应进入失败队列或人工复核流程，而不是由其他工作进程继续发起重试。

幂等保护怎么设计

只读取资源的 GET 请求通常可以有限重试，但“可重试”不等于“无限重放”。会创建订单、扣减配额或改变服务端状态的请求，应使用服务端支持的幂等键或唯一业务请求 ID。

幂等键应绑定一次业务意图，例如：

```text
业务任务 ID + 提取条件摘要 + 时间窗口
```

代理 ID、当前时间戳或每次重试都变化的随机值不能提供幂等保护。服务端若不支持幂等，也不能仅靠客户端生成一个字段就保证不重复执行。

重试过程中何时更换代理 IP、何时停止

确认哪些条件后才更换代理 IP

提取 API 失败时通常先修接口调用，不讨论换代理 IP。只有业务请求已确认认证、参数和目标站状态正常，且失败稳定集中在特定出口，才更换代理 IP 复测。

停止并报警的条件

以下条件表示继续重试无法提高成功概率，或可能扩大配额消耗、重复业务操作和下游脏数据风险。

遇到以下情况应停止并报警：

1. 401/403、参数错误或白名单不匹配；
2. 资源明确为空，且放宽条件需要业务确认；
3. 达到最大尝试次数或任务总时限；
4. 一段时间内错误率持续超过业务阈值；
5. 响应格式异常，继续处理可能污染下游数据。

重试日志应记录哪些字段并如何脱敏

至少记录：请求 ID、API 端点、国家/城市/数量等非敏感参数、状态码、错误类型、尝试次数、实际等待时间、响应数量、耗时和最终状态。令牌、完整账号密码和完整代理认证串不得写入日志。

```text
request_id | endpoint | filters | status | error_type
attempt | wait_ms | result_count | elapsed_ms | final_state
```

业务请求日志另行记录目标 URL、脱敏代理标识、出口地区、状态码和业务有效结果，避免把两条链路的成功率混在一起。

用脱敏复测数据验证重试策略

以下为脱敏记录示例（接口域名、代理标识已隐去，数字不是 SLA；发布前应替换为真实日志）：批量提取 100 条、并发 5、超时 8 秒，首轮返回 92 条；对 5xx 使用 1/2/4 秒退避后补回 6 条，参数错误重试 0 次；目标请求链另测 100 次，429 占 4 次。两条链路分开统计，避免把重试放大与代理质量混淆。

429 与 Retry-After 可核对 RFC 6585，HTTP 方法语义可核对 RFC 9110；退避上限、样本量和结果属于经验设计，不是通用保证。

FAQ

认证失败适合自动重试吗？

不适合。相同认证信息不会因退避而自动变正确，应先检查令牌、账号密码、权限或白名单。

API 空结果一定代表故障吗？

不一定。筛选条件过窄、当前库存不足或配额限制都可能返回空结果，应按接口语义处理。

随机抖动有什么作用？

它能让多个任务错开重试时间，降低同一时刻再次集中请求的概率。

每次重试都要重新提取代理 IP 吗？

不一定。先判断失败发生在提取 API 还是业务请求；两条链路要使用不同的重试和停止规则。

确认参数和认证无误后，可按任务规模查看动态住宅代理 IP。