curl代理环境变量不生效：先查变量名，再看覆盖顺序

把代理地址写进 HTTP_PROXY 或 HTTPS_PROXY 后，curl 仍然直连，通常不是代理服务立刻失效，而是变量名、大小写、NO_PROXY 排除规则或命令行参数覆盖了环境配置。按优先级逐层检查，比反复重启终端更快。

先确认 curl 实际读取的变量

常见变量包括 http_proxy、https_proxy 和 all_proxy，也有环境会同时设置大写版本。先在当前 shell 中只检查是否存在，不要把完整凭据写入日志：

env | grep -iE '^(http|https|all|no)_proxy='

HTTP 目标通常看 http_proxy，HTTPS 目标通常看 https_proxy；如果只设置了其中一个，另一个协议的请求可能仍然直连。SOCKS5 代理应使用 all_proxy=socks5h://host:port，让域名解析也走代理。

设置变量时，变量只对当前进程及其子进程生效：

export HTTPS_PROXY='http://proxy.example.com:8080'
export HTTP_PROXY="$HTTPS_PROXY"

若是在脚本、IDE 或服务管理器中执行 curl，它们未必继承你交互式终端里的变量。必须在实际启动 curl 的那个进程环境中检查。

大小写和工具版本不要混为一谈

不同系统和工具对大写代理变量的处理不完全一致，尤其要注意 HTTP_PROXY。为避免环境差异，生产脚本可以统一设置小写变量，并在启动阶段打印经过脱敏的变量来源。不要直接输出包含用户名和密码的完整代理 URL。

还要确认执行的确实是预期版本的 curl：

command -v curl
curl --version

容器、虚拟环境和系统 shell 可能指向不同的 curl 二进制。即使变量在宿主机存在，容器内命令也可能完全看不到。

NO_PROXY 可能把目标排除了

如果 NO_PROXY 或 no_proxy 匹配目标域名、主机名、IP 或端口，curl 会按规则绕过代理。先临时清空它做对照：

NO_PROXY= no_proxy= curl -v https://api.example.com/health

这条命令只影响本次进程，不会修改长期环境。排除规则应尽量写窄，例如只放内网域名和健康检查地址，不要为了“修好代理”把整个域名后缀加入白名单。IPv4、IPv6、短主机名和带端口写法也可能导致匹配结果不同。

命令行参数会覆盖环境变量

curl --proxy、--noproxy 和配置文件中的设置，都可能改变环境变量最终效果。用 -v 观察连接是否经过代理，但注意调试输出可能包含认证头和目标地址：

curl -v --proxy "$HTTPS_PROXY" https://api.example.com/health

如果显式 --proxy 能成功，而只依赖环境变量失败，问题集中在变量继承、大小写或 NO_PROXY。如果显式参数也失败，再检查代理协议、端口、认证和网络连通性。代理握手成功后收到 401、403 或 429，说明请求已经到达下一层，不应继续只改环境变量。

用最小脚本固定排查顺序

建议将排查拆成四步：确认变量存在、确认目标未被 NO_PROXY 排除、用 curl -v 验证代理握手、最后再加回业务请求头和参数。每步只改变一个因素，并记录响应码、总耗时和是否出现代理认证错误。

代理环境变量只改变请求路径，不会自动授予目标接口权限。请仅在已获授权的系统中使用代理，并保护好用户名、密码和接口令牌；确认链路稳定后，再把配置放入服务启动文件或部署系统中。