请求失败时先确定失败发生在哪一层，再决定修复什么。本篇集中处理共有错误，各工具篇只保留该工具特有问题。
- 1. 执行了吗？没有则查工具权限
- 2. API 接受了吗？密钥、余额与参数
- 3. 目标返回什么？状态、类型与页面
- 4. 停止或继续修复后再授权一次
按症状定位
| 症状 | 先做什么 | 不要做什么 |
|---|---|---|
| 未实际执行 | 先确认工具/终端有运行记录 | 不要把代码文本当作成功 |
| 读不到 Key | 核对实际进程及变量存在性 | 不打印变量值 |
| APIKEY_INVALID / INSUFFICIENT_BALANCE | 修复密钥或余额后再授权一次 | 不靠换 IP 解决 |
| PROXY_ERROR / PROXY_NON_STICKY | 检查协议、鉴权、有效期与出口稳定性 | 不同时改多个变量 |
| 超时或网络错误 | 区分本地到 API、代理到目标与业务耗时 | 不盲目重放有副作用请求 |
| HTTP 200 但字段不对 | 检查 x-cb-status、Content-Type、登录/挑战页 | 不让模型补齐虚构数据 |
反馈问题时保留这些信息
- 发生时间与时区，工具名及版本，真正执行请求的环境。
- 脱敏后的目标、接口版本、HTTP 状态、x-cb-status 和实际返回的 code/message。
- 实际返回的请求 ID；没有就说明没有，不编造替代值。
- 已尝试步骤和最终现象。移除 Key、Cookie、Authorization、代理密码和敏感查询参数。
常见问题
系统代理与 x-cb-proxy 一样吗？
不同。前者控制运行器到 API 的连接，后者选择 API 到目标的代理；不要把两段网络混为一谈。
所有 403 都要换 V2 吗？
不能这样判断。先区分 API 错误、目标权限、登录要求和受支持的挑战，再按文档选版本。
可以重试登录、付款或下单吗？
超时不说明业务没执行。先核对业务状态和幂等设计，不按普通 GET 的方式重放。