代理IP API密码鉴权缺少pwd参数：先对齐参数名，再判断账号权限

调用代理IP API 时，接口返回“缺少参数”“认证失败”或一直拿不到可用节点，常见原因是请求只带了账号字段，却漏掉服务商要求的 pwd 参数。先确认接口契约中的参数名、传递位置和编码方式，再排查账号权限，能避免把格式问题误判成资源故障。

先确认接口要求的字段集合

不同 API 对用户名和密码的命名并不统一，可能使用 user、username、uid、pwd 或其他字段。不要把某个产品的示例直接套到另一个接口。应以当前接口文档或已授权的 SDK 定义为准，确认 pwd 是必填字段，还是仅在某种鉴权模式下使用。

同时确认参数是在查询字符串、JSON 请求体、表单还是请求头中传递。字段名写对但放错位置，服务端仍可能认为缺少参数。

如果使用青果代理的某个 API 模式，只有在该模式的官方文档明确要求 pwd 时才按此字段传递；不同接口、套餐或鉴权方式可能使用不同参数。先核对产品名称、接口版本和鉴权模式，再确认 API 密码来自对应控制台的接口凭证，而不是登录密码或其他项目的密钥。

用最小请求验证参数是否到达

先构造不带业务筛选条件的最小请求，只验证鉴权和基本响应。示意形式如下，真实值应通过受控配置注入：

curl -G 'https://api.example.com/proxy' \
  --data-urlencode "user=${PROXY_USER}" \
  --data-urlencode "pwd=${PROXY_PASSWORD}" \
  --data-urlencode 'count=1'

--data-urlencode 能减少特殊字符破坏查询参数的风险。查询字符串会出现在客户端调试记录、反向代理访问日志或浏览器历史中，因此不建议把真实密码放在 URL；优先使用服务端支持的请求体或受控 SDK。不要把真实密码直接写进命令历史、代码仓库或调试截图，也不要在日志中打印完整 URL。若接口要求 JSON，应改用受控的请求体，并确认 Content-Type 与文档一致。

区分缺参数、鉴权失败和权限不足

错误信息应按层次判断：

只有确认参数已经被服务端接收后，才值得继续检查代理池资源。否则反复更换 IP 或提高请求数量不会解决鉴权层问题。

注意 shell、环境变量和编码细节

密码含有 &、+、@ 等字符时，直接拼接 URL 可能被解析成多个参数。优先使用编码参数或 SDK 的结构化字段。环境变量也要在实际运行 API 请求的进程中存在；IDE、容器和定时任务未必继承交互式终端的变量。

如果通过代理调用 API，还要把“到 API 服务的连接”和“API 返回的代理节点”分开验证。前者失败看网络与代理入口，后者失败看参数、账号和套餐权限。不要在排查中输出完整鉴权请求；即使使用环境变量，展开后的命令参数也可能被进程查看工具、shell 跟踪或调试日志暴露。

确认修复后再恢复业务筛选

最小请求成功后，再逐项加回地区、协议、会话、数量和有效期等条件，每次只改变一个参数。记录脱敏后的请求结构、响应码和耗时，避免把临时修复误当成稳定配置。使用代理IP API 的前提是目标业务和数据访问已获授权，密码与令牌应保存在受控密钥系统中，并定期轮换。