同样的代理，浏览器里设好就能用，可一旦把请求搬进命令行脚本，连不上、超时、证书报错经常一起冒出来。多数时候不是代理坏了，而是命令行工具理解代理的方式，和浏览器完全不同。
脚本走代理，最常见的是这四个坑
浏览器从系统设置读取代理，脚本则依赖自己的一套环境变量和参数。两者对”哪些流量走代理、证书怎么验、超时多长”的默认判断都不一样，理解这点，排查就快得多。
坑一：环境变量根本没生效
多数命令行工具认的是 HTTP_PROXY、HTTPS_PROXY 这类环境变量，而不是图形界面里的系统代理。在系统设置里开了代理，终端里的脚本不一定继承得到；反过来，在终端里 export 的变量也只对当前会话有效。先 echo 一下变量确认有没有值，再用 curl -v 看请求是否真的经过了代理出口，两步就能定位。
坑二：localhost 也被塞进了代理
不少脚本默认对一切地址都走代理，包括 127.0.0.1、localhost 这类本机地址。本地服务、数据库、内部接口的请求被强行绕到代理出口，自然连不上。常规做法是设置 NO_PROXY，把本机和内网网段排除在外，让本地流量直连。
| 坑 | 典型现象 | 检查点 |
|---|---|---|
| 环境变量未生效 | 请求直接走本地出口 | echo $HTTP_PROXY / curl -v |
| 本机地址也走代理 | 连本地服务超时 | NO_PROXY 是否覆盖本机网段 |
| 自签名证书报错 | 握手阶段直接拒绝 | 证书信任链是否配置 |
| 默认超时太短 | 请求时好时坏、批量超时 | 连接/读取超时参数 |
坑三、坑四：证书与超时是隐性变量
企业内网或调试环境常用自签名证书，脚本默认校验失败会直接拒绝连接。这通常不是代理的问题，而是证书信任链的问题，正规做法是让脚本信任对应 CA，而不是粗暴关闭校验。另外，命令行工具和库的默认超时往往比浏览器短，代理链路多一跳、握手更耗时，显式设置连接超时与读取超时，能明显减少”时好时坏”的假象。
- 先确认环境变量：HTTP_PROXY / HTTPS_PROXY 有值、格式正确
- 再看直连排除：NO_PROXY 覆盖本机与内网网段
- 然后处理证书：自签名场景配置 CA 信任，而非关校验
- 最后调超时：按代理链路延迟设置合理的连接与读取超时
- 习惯一：脚本里显式写代理参数，不依赖隐式环境
- 习惯二：排查时先直连对照，再走代理对照
- 习惯三：报错先看出口出口在哪一环，不急着换服务
脚本报错时，代理通常是第一个被怀疑的对象，但更常是第一个被冤枉的对象。
与 IP 代理的关系：命令行与脚本是代理的重要使用场景，环境变量、证书、超时这三类配置直接决定脚本能否稳定经由代理出口工作；选择文档完善、支持多协议接入的代理服务，配合规范的脚本配置，才能让自动化任务稳定运行。所有使用都应遵循平台规则与法律法规，用于正当业务目的。