代理 API 的价值不是“拿到很多 IP”，而是把地区、协议、会话、异常重试和节点替换做成可控的程序流程。企业接入前应先定义失败处理和观测指标。
常见的两类代理 API
获取节点型 API：调用接口返回 IP、端口、用户名/密码等信息，程序自行维护代理池。
网关型 API：程序始终连接固定网关，通过用户名参数、Header 或请求参数选择国家、地区和会话。
接入前先定义数据结构
| 字段 | 建议记录 |
|---|---|
| endpoint | 代理主机与端口 |
| protocol | http / https / socks5 |
| region | 国家、州/省、城市（如支持） |
| session_id | 粘性会话或轮换控制标识 |
| expires_at | 节点或会话有效期 |
| last_check | 最近健康检查时间 |
| status | healthy / degraded / failed |
程序流程建议
- 按业务要求申请地区和协议。
- 创建连接前校验节点是否过期。
- 请求失败时区分超时、认证失败、目标站拒绝和代理不可达。
- 对代理自身失败做有限次数重试，避免无限循环。
- 记录出口 IP、延迟、状态码和失败类型。
- 达到失败阈值后标记节点降级并申请替换。
不要把所有失败都归因于代理
目标站 403、429、5xx、DNS 错误、TLS 失败和代理连接超时属于不同问题。程序应分别记录，否则会把目标站限流误判成节点故障。
凭据和安全
代理用户名、密码或 API Token 应存放在环境变量或密钥管理系统，不要写进前端代码、公开仓库或日志。对外暴露的管理 API 应限制来源并启用最小权限。
监控指标
请求成功率
P50/P95 延迟
认证失败率
节点替换次数
地区匹配率
单位流量成本
常见问题
代理 API 要不要自己维护池？
取决于供应模式。网关型通常不需要保存大量 IP；获取节点型则建议维护状态、过期时间和健康检查。
失败后可以无限重试吗？
不建议。应限制次数、增加退避，并区分代理故障与目标站限流。