curl 的 --noproxy 写了端口和路径，请求仍走代理

给 curl 加了 --noproxy api.internal.example:1337/api，请求却仍发往代理；把参数改成 api.internal.example 后才直连。这是绕过列表的匹配对象写错了：--noproxy 接收主机列表，不接收需要绕过的完整 URL，也不按 URL 路径制定规则。

以下适用于 curl 命令行。--noproxy 从 7.19.4 起提供；涉及覆盖 no_proxy、NO_PROXY 环境变量的行为，以下按 7.53.0 及以后版本说明。先用 curl --version 确认实际客户端，尤其是脚本和交互终端使用了不同安装路径时。

把请求地址和绕过主机分开

假设目标是内部服务的 /api，并且网络策略允许直接访问它：

curl --noproxy 'api.internal.example' \
  'http://api.internal.example:1337/api'

端口与路径仍留在请求 URL 中。不要把 http://、:1337 或 /api 放进绕过项。

这个设置会影响该主机的代理选择，不只是它的 /api 路径或 1337 端口。若要求同一主机的其他路径仍走代理，应把请求拆成分别配置的调用，不能把 --noproxy 当成按路径分流的代理规则。

多个主机用逗号分隔：

curl --noproxy 'api.internal.example,files.internal.example' \
  'http://api.internal.example:1337/api'

主机名匹配还具有域名后缀语义。例如列表项 example.com 会匹配该域名及其子域名，不应为了修一个内部接口就随意扩大到整个公司域名。这里的参数也不是正则表达式；唯一通配符是单独的 *，代表全部主机。

确认改变的是连接路径

用无敏感参数、已获准访问的检查接口观察连接过程：

curl --verbose --noproxy 'api.internal.example' \
  --output /dev/null 'http://api.internal.example:1337/api'

查看详细输出中的目标地址和连接建立过程，核对连接的是业务端点还是显式代理。必要时对照代理访问记录。响应成功本身不能证明绕过了代理，某些代理同样能够访问目标服务。

详细日志可能包含请求头、认证信息和内部地址，应在受控终端查看，不要公开未经脱敏的完整输出。示例没有执行响应内容，只把正文丢弃；实际接口仍应选择无修改作用的请求。

如果已直接连接目标，但变成名称解析失败、连接超时或拒绝连接，应查直连所需的 DNS、路由和监听。代理能访问内部主机，不代表运行 curl 的机器也有相同的解析和网络权限。curl 的绕过参数也不能消除网络设备实施的透明代理。

不要把 --no-proxy 当成同义参数

--noproxy 与 --no-proxy 不是两种等价拼法。--proxy 是带地址参数的选项，不能靠添加 --no- 把它当布尔开关关闭。旧客户端曾出现把这种错误拼法按代理参数处理的行为，不能以一次“能访问”为依据沿用它。

只需要为当前一次调用关闭显式代理时，可以使用：

curl --proxy '' 'http://api.internal.example:1337/api'

空字符串覆盖设置代理的环境变量，作用范围是这次调用。它会影响本次调用中的全部目标，所以日常脚本只需要例外主机时，仍应使用范围明确的 --noproxy。企业要求经过审计代理的流量应保留原路径，不能用这个命令绕过组织访问规则。

在 7.53.0 及以后，显式 --noproxy 会覆盖禁用代理的环境变量；并不是把新主机自动追加到原列表。修改脚本前，检查它是否依赖其他已有例外，保留需要的主机。也应检查 .curlrc、包装脚本及后续参数是否重新设置了选项。

修正后分别验证内部目标的预期内容与连接路径，以及原本应走代理的请求仍遵守既定配置。单次命令参数退出后不会改写终端环境；若修改了脚本或配置文件，回退时恢复本次变更前的列表，无需清空整台机器的代理设置。