curl 没有代理环境变量，请求仍被默认配置送往代理

curl 命令没有 --proxy，当前进程环境里也找不到代理地址，请求却仍发往代理，甚至收到代理生成的错误页。这时还要检查 curl 自动读取的默认配置文件；代理不只来自环境变量。

以下针对 curl 命令行工具在 Linux 等非 Windows 环境中的默认配置读取。是否真的由配置文件造成，需要比较同一可执行文件、同一用户下的请求，不能把所有意外代理都归因于 ~/.curlrc。

先用首个参数 -q 隔离默认配置

在允许直连的测试目标上，对比普通调用与禁用默认配置的调用：

curl --verbose --output /dev/null 'https://api.example.com/health'
curl -q --verbose --output /dev/null 'https://api.example.com/health'

URL 是占位地址，应替换为无修改作用、无敏感参数且获准用于诊断的端点。详细日志可能暴露代理认证、请求头或内部地址；在受控终端查看，不要直接粘贴完整日志到公共渠道。

-q 必须是 curl 收到的第一个参数。curl --verbose -q ... 不满足这一条件，不能用它证明默认配置没有影响。别名、shell 函数或包装程序可能在你写的参数之前追加选项，先确认实际运行的程序与完整调用方式。

如果普通调用连接代理，而以首参 -q 调用后路径改变，这说明自动加载的配置参与了差异。它还可能包含 URL、认证、证书和输出设置，因此两次业务响应不同不一定只由代理造成；接下来仍要定位具体配置行。

如果两次仍走同一代理，继续检查继承的代理环境变量、显式 --proxy、包装脚本与显式配置参数。-q 不清空环境，也不能关闭网络设备实施的透明代理。

不只查看 HOME 下的一份文件

当前 curl 在非 Windows 环境会依次考虑这些位置：

$CURL_HOME/.curlrc
$XDG_CONFIG_HOME/curlrc
$HOME/.curlrc

XDG_CONFIG_HOME 这一候选位置从 curl 7.73.0 起支持；相应变量未设置时，不能把它展开成根目录下的文件来查。后面还有通过系统账户信息查找主目录的路径。先用 curl --version 确认实际版本，并以执行 curl 的用户与环境为准。

例如默认文件中有：

proxy = "http://proxy.example.com:3128"

即使 shell 环境没有代理变量，这条配置仍可设置显式代理。检查文件时也要留意它是否继续通过 config 读取另一份文件，以及是否附带认证、CA 文件或输出目的地；不要只搜索一个文件名就宣布排除。

服务账户、sudo、CI 与交互终端可能有不同的 HOME、CURL_HOME 或 XDG_CONFIG_HOME。个人终端里改好一份 .curlrc，不等于后台任务也读取它。核对路径即可，不必把所有用户的配置内容集中打印出来。

显式 -K 不会替你关闭默认配置

--config（-K）指定一份配置文件时，默认配置仍可能先被读取。如果任务必须只采用受控的显式配置，可以把禁读默认配置放在最前面：

curl -q --config /path/to/job.curlrc

这条命令仍会读取指定的 job.curlrc，也仍可能受环境变量影响。它不是“忽略全部配置”，更不保证直连；指定文件本身还可以设置代理。路径必须替换为原任务受控配置，保留原有 TLS 验证和认证要求。

对于已确认不再需要的默认代理设置，先备份配置，再只修正对应行。不要直接删除整份文件：其中可能还有组织要求的 CA、客户端证书或其他任务需要的设置。若仅一个任务需要独立行为，使用明确的任务配置通常比改动所有 curl 调用的默认值更容易控制。

同时核对直连与仍需代理的请求

修正后，用相同诊断目标核对实际连接地址，并确认返回的是目标服务的预期内容。若变成 DNS 失败或连接超时，说明直连路径还需要正确的解析与路由，不能据此恢复一个错误代理或关闭 TLS 校验。

还要验证原本必须经过代理的任务没有被影响。企业要求的访问代理不能靠 -q 或空代理参数绕过；诊断前应确认目标和路径都在允许范围内。

单次首参 -q 不修改磁盘配置，调用结束后也不会改变其他进程。修改过默认文件时，回退恢复原版本；若曾把含凭据的详细日志对外发送，恢复文件并不能撤销那次暴露，应按凭据管理流程处理。