自动化脚本使用代理时如何记录 IP、地区和失败原因？
自动化脚本使用代理时，应同时记录出口 IP、地区、状态码、耗时和异常类型。本文给出日志字段、JSON 示例、验证步骤及 407、403、429 和超时的归因方法。
自动化脚本不能只记录“成功”或“失败”。至少要把目标 URL、代理 IP 类型、出口 IP、出口地区、协议、状态码、耗时、重试次数和异常类型写入同一条代理日志，才能区分接入错误、网络异常、地区识别偏差和目标站拒绝。开始放量前，先用 IP 检测页与真实目标页面完成一轮小样本验证。
自动化脚本至少要记录哪些代理字段
| 字段 | 作用 | 示例 |
|---|---|---|
| timestamp | 对照失败时间和流量波动 | 2026-09-07T10:30:00+08:00 |
| target_url | 确认失败是否只出现在某个站点 | https://example.com/page |
| proxy_type | 区分动态住宅、静态住宅或机房代理 IP | dynamic_residential |
| protocol | 核对 HTTP、HTTPS 或 SOCKS5 接入 | http |
| exit_ip | 判断请求是否经过代理及是否发生切换 | masked |
| country / city | 检查出口地区和业务目标是否一致 | 以检测结果为准 |
| status_code | 区分认证、限流和目标站错误 | 200、403、407、429、5xx |
| latency_ms | 判断超时或高延迟 | 毫秒值 |
| error_type | 统一失败分类 | auth、timeout、blocked、network |
| retry_count | 判断重试是否放大失败 | 0、1、2 |
| session_id | 关联同一会话内的多次请求 | 使用脱敏标识 |
日志中不要写入真实代理密码、token、Cookie 或完整账号信息。需要关联账号时，使用不可逆的脱敏标识。
为什么要用结构化日志记录请求
JSON 或 CSV 比纯文本错误信息更容易筛选和汇总。一条 JSON 日志可以采用下面的结构：
~~~json
{
"timestamp": "2026-09-07T10:30:00+08:00",
"target_url": "https://example.com/page",
"proxy_type": "dynamic_residential",
"protocol": "http",
"exit_ip": "masked",
"country": "expected-country",
"city": "detected-city",
"status_code": 429,
"latency_ms": 1820,
"error_type": "rate_limited",
"retry_count": 1,
"session_id": "job-001"
}
~~~
同一批任务要固定字段名和错误枚举，避免一部分日志写 timeout，另一部分写“连接超时”，导致后续无法统计。
一次脱敏运行记录（Python requests、单并发、同一目标 URL）如下：
```json
{"time":"2026-09-06T16:31:08+08:00","url":"https://example.test/geo","proxy_type":"dynamic_residential","exit_ip":"198.51.100.*","country":"JP","city":"Tokyo","status":200,"latency_ms":534,"retry":0,"error":null}
{"time":"2026-09-06T16:31:14+08:00","url":"https://example.test/geo","proxy_type":"dynamic_residential","exit_ip":"198.51.100.*","country":"US","city":"California","status":0,"latency_ms":3000,"retry":1,"error":"read_timeout","trace":"ReadTimeout: HTTPSConnectionPool(...): Read timed out"}
{"time":"2026-09-06T16:31:22+08:00","url":"https://example.test/geo","proxy_type":"dynamic_residential","exit_ip":"198.51.100.***","country":"JP","city":"Tokyo","status":200,"latency_ms":612,"retry":2,"error":null}
```
第一条成功、第二条地区跳变并超时、第三条复测恢复，说明应把“地区不一致”和“读取超时”分别归因，并通过出口 IP、重试次数和堆栈关联同一会话。
一个最小的记录流程可以写成下面这样。伪代码不绑定具体语言，实际接入时只需替换请求客户端和日志组件：
~~~text
request_id = create_id()
start = now()
exit_ip = null
country = null
city = null
log(request_id, target_url, proxy_type, protocol, status="started")
try:
exit_ip, country, city = check_proxy_exit()
response = request(target_url, proxy)
log(request_id, exit_ip, country, city,
status_code=response.status, latency_ms=now()-start,
error_type=null, retry_count=retry_count)
except Exception as error:
log(request_id, exit_ip, country, city,
status_code=get_status(error), latency_ms=now()-start,
error_type=classify(error), retry_count=retry_count)
~~~
无论请求成功还是失败，都应保留同一个 request_id 的完整记录；重试时新增记录并递增 retry_count，不要覆盖第一次失败。
最小可用的日志字段
如果暂时不能记录完整链路，至少保留 request_id、target_url、proxy_type、protocol、exit_ip、expected_country、detected_country、expected_city、detected_city、status_code、latency_ms、error_type 和 retry_count。其中 expected_* 表示任务目标，detected_* 表示检测结果，二者分开保存，才能识别“代理出口正确但目标站仍未本地化”的情况。可以增加 DNS、连接和首字节耗时，敏感字段按前文字段表后的脱敏规则处理。
请求前、请求中和请求后分别记录什么
1. 请求前记录任务编号、目标 URL、代理 IP 类型、协议和会话标识。
2. 首次使用该代理信息时，访问 IP 检测页并记录出口 IP、国家和城市。
3. 发起真实业务请求，记录状态码、耗时和响应类型。
4. 捕获连接拒绝、DNS、TLS、认证和读取超时等异常。
5. 发生重试时保留原失败记录，不要只保存最后一次结果。
6. 任务结束后按目标站、状态码、出口地区和代理 IP 类型汇总。
代理主机、端口、账号、密码和协议应从对应产品后台或代理参数说明获取，不要从第三方截图推断端口或认证方式。需要接入流程时可查看获取代理帮助。
不同失败表现应该怎么分类
| 表现 | 先检查 | 下一步 |
|---|---|---|
| 出口 IP 未变化 | 代理是否启用、协议和端口是否正确 | 换 IP 检测页或客户端复测 |
| 407 | 账号密码、认证方式、协议和端口 | 用同组参数在另一客户端复测 |
| 403 | 目标站规则、Cookie、账号状态、出口地区 | 固定其他变量，只更换一个出口复测 |
| 429 | 请求频率、并发、重试策略 | 降低频率并增加退避时间 |
| 超时或连接拒绝 | 本地网络、代理端口、目标站响应 | 分别测试 IP 检测页和目标 URL |
| 地区识别不一致 | IP 库、目标站识别、语言和 Cookie | 用多个检测源及目标页面交叉验证 |
不要把所有 403、429 或验证码都标记成“代理 IP 不可用”。只有完成对照实验后，才能判断应更换代理 IP、调整会话策略，还是转查目标站和脚本逻辑。
记录到异常后应该怎么处理
例如，407 且每次请求都失败，通常先修正认证、协议或端口；代理检测成功但目标站持续 403，应固定其他变量后检查 Cookie、账号和目标站规则；429 在重试后比例上升，应降低频率并增加退避；出口地区正确但页面语言或内容不符，则要对照语言、时区、设备和 Cookie。日志的作用是缩小问题范围，不是自动证明代理 IP 一定失效。
动态和静态代理 IP 分别要记录什么
动态住宅代理 IP 可能按请求或粘性会话切换，因此日志必须记录每次请求或每个会话的出口 IP。静态住宅代理 IP 更适合长期身份和连续会话，但仍要记录掉线、出口变化和会话中断。机房代理 IP 更适合住宅属性不是硬要求、重视速度或成本的公开访问测试，是否适用要由目标站实测决定。
代理代码接入和日志排障怎么开始
前文已经分别给出日志字段、API 和接入说明；需要统一查看时，可进入代理设置帮助。
FAQ
自动化脚本最少需要记录哪些代理字段？
至少记录目标 URL、出口 IP、地区、协议、状态码、耗时、异常类型和重试次数。登录态任务还应增加脱敏会话标识，方便关联同一会话的请求。
如何确认脚本真的走了代理？
先在脚本内访问 IP 检测页，再与直连出口对比。随后用同一组代理参数访问目标 URL，分别记录出口地区和响应结果。
407、403 和 429 可以用同一种重试策略吗？
不可以。407 应先修正认证，403 要排查目标站规则和环境，429 应降低频率并设置退避；盲目重试可能放大问题。
日志可以保存代理密码和 Cookie 吗？
不建议。日志应隐藏密码、token、Cookie 和账号信息，只保留排障所需的脱敏标识。
先用少量真实请求跑通“检测出口—访问目标—记录失败—分类汇总”的闭环，再根据日志中的地区命中率、状态码比例、延迟和重试结果决定是否扩大任务规模。错误码可继续查阅代理 API 错误码和程序报错怎么查，并结合代理请求超时、失败重试和故障转移怎么设计优化重试策略；日志排查方法可参考代理日志怎么帮助排查采集失败。需要产品咨询时可前往注册或咨询全球代理服务。