Go HTTP 代理为什么没有读取 HTTPS_PROXY

Go HTTP 客户端没有读取 HTTPS_PROXY，通常不是变量名拼错，而是请求没有走到 HTTPS 代理选择分支。net/http.ProxyFromEnvironment 会根据请求 URL 的 scheme 选择 HTTPS_PROXY 或 HTTP_PROXY，还会先看 NO_PROXY；localhost 则有直接返回不使用代理的特殊规则。

排查时先不要猜网络链路，直接把代理函数挂到同一个请求上观察返回值。只要返回的代理 URL、nil 或错误类型分清楚，问题就能从“代理没生效”收窄到具体配置边界。

结论：HTTPS 请求才会匹配 HTTPS_PROXY；如果 NO_PROXY 命中、目标是 localhost、代理值格式不合法，或者进程已经完成第一次代理配置读取，看到直连都是符合标准库规则的结果。

先确认请求确实是 HTTPS

ProxyFromEnvironment 不会把所有请求都交给 HTTPS_PROXY。请求 URL 的 scheme 是 https 时，才会匹配 HTTPS 代理变量；普通 http 请求应检查 HTTP_PROXY。变量名支持大写和小写形式，实际部署中要避免只在一个进程没有继承到的 shell 会话里设置。

下面这个最小配置保持标准库的环境变量语义。关键点是请求 URL 和代理变量要成对看，而不是只检查某一个变量是否存在。

package main

import (
    "fmt"
    "net/http"
)

func main() {
    req, err := http.NewRequest(http.MethodGet, "https://api.example.com/data", nil)
    if err != nil {
        // 请求创建失败时先结束，避免拿无效 URL 继续判断代理。
        panic(err)
    }

    proxyURL, err := http.ProxyFromEnvironment(req)
    if err != nil {
        // 代理变量存在但格式不对时，标准库会把解析错误返回出来。
        panic(err)
    }

    if proxyURL == nil {
        // nil 可能表示未配置代理，也可能是 NO_PROXY 或 localhost 规则命中。
        fmt.Println("本次请求按规则直连")
        return
    }
    fmt.Println("本次请求使用代理:", proxyURL.Redacted())
}

这里的 nil 不是“HTTPS_PROXY 一定没有读取”的证据。它只说明对当前请求没有得到可使用的代理 URL，下一步还要检查排除规则和环境读取时机。

用 ProxyFromEnvironment 把问题变成可观察结果

标准库文档定义了三种有用的判断：没有代理或应当绕过代理时返回 nil URL, nil error；代理值无法解析时返回错误；有可用代理时返回代理 URL。把这三种结果分开记录，比只看最终请求是否超时更容易定位。

func describeProxy(target string) {
    req, err := http.NewRequest(http.MethodGet, target, nil)
    if err != nil {
        // URL 本身无效时，问题还没有进入代理选择阶段。
        fmt.Printf("target=%s request-error=%v\n", target, err)
        return
    }

    proxyURL, err := http.ProxyFromEnvironment(req)
    if err != nil {
        // 解析错误应修复代理值，不要先改 Transport 的其它参数。
        fmt.Printf("target=%s proxy-parse-error=%v\n", target, err)
        return
    }
    if proxyURL == nil {
        // nil 只表示当前请求没有代理，不代表所有请求都没有代理。
        fmt.Printf("target=%s proxy=direct\n", target)
        return
    }
    fmt.Printf("target=%s proxy=%s\n", target, proxyURL.Redacted())
}

建议至少分别观察一个 https:// 和一个 http:// 目标。若前者直连、后者使用代理，常见原因是只设置了 HTTP_PROXY；若两者都直连，再进入下一节排查 NO_PROXY。

NO_PROXY 和 localhost 会让 HTTPS_PROXY 看起来失效

NO_PROXY 的作用是声明不应使用代理的主机或地址。只要目标命中排除规则，ProxyFromEnvironment 就会返回 nil。另外，Go 文档明确把主机名为 localhost（可带端口）列为特殊直连情况，因此用本地测试服务验证 HTTPS_PROXY 时，不能把 localhost 的结果当成远端服务的结果。

可以把目标主机、NO_PROXY 内容和代理函数结果放在同一条诊断日志里，但不要把代理用户名和密码原样写入日志。下面只输出经过 Redacted 处理的代理 URL。

func checkTarget(target string) error {
    req, err := http.NewRequest(http.MethodGet, target, nil)
    if err != nil {
        // 先确认目标 URL 可解析，避免把 URL 问题误判为代理问题。
        return err
    }
    proxyURL, err := http.ProxyFromEnvironment(req)
    if err != nil {
        // 代理地址的格式错误应当单独暴露给调用方。
        return err
    }
    if proxyURL == nil {
        // 这里可能是 NO_PROXY，也可能是 localhost 或没有配置代理。
        fmt.Println("目标按当前环境规则直连:", req.URL.Host)
        return nil
    }
    fmt.Println("目标将使用代理:", proxyURL.Redacted())
    return nil
}

排查时可暂时把一个确定的远端测试域名从 NO_PROXY 中移除，再重新启动进程观察；不要通过关闭 TLS 校验或把代理逻辑改成全局硬编码来掩盖排除规则。

环境变量的首次读取会影响进程内结果

当前 Go 标准库实现会在第一次需要代理配置时，通过一次性初始化读取环境并构造代理函数。也就是说，进程已经完成过一次代理查询后，再调用 os.Setenv 修改 HTTPS_PROXY，不应期待同一进程里的后续请求立即换代理。最稳妥的做法是在进程启动前注入环境变量，或者在程序启动阶段完成配置，再开始发请求。

func newClientFromEnvironment() *http.Client {
    // 在第一次代理查询前设置环境，生产环境更推荐由进程启动器注入。
    _ = os.Setenv("HTTPS_PROXY", "http://proxy.example:8080")
    _ = os.Setenv("NO_PROXY", "localhost,127.0.0.1")

    transport := &http.Transport{
        // 显式复用标准库代理函数，不为每个请求新建 Transport。
        Proxy: http.ProxyFromEnvironment,
    }
    return &http.Client{Transport: transport}
}

示例里的 os.Setenv 只用于说明初始化时机；服务程序应检查它的返回错误，并避免在请求已经开始后动态修改全局环境。Transport 应长期复用，既能保持连接复用，也能让代理决策保持一致。

把修复收敛为显式、可诊断的 Transport

如果业务确实需要从环境读取代理，显式创建一个长期复用的 Transport 即可；不要因为一次直连就把代理函数替换成不可观察的自定义逻辑。若业务策略不是环境变量，而是固定的代理 URL，也可以用 http.ProxyURL 返回固定代理，但这已经改变了“按请求 scheme 读取环境”的语义，应在配置文档中写清。

func buildClient() *http.Client {
    transport := &http.Transport{
        // 让每个请求继续按 HTTPS_PROXY、HTTP_PROXY 和 NO_PROXY 选择。
        Proxy: http.ProxyFromEnvironment,
        // 连接参数按业务设置；不要为每次请求创建新的 Transport。
        MaxIdleConnsPerHost: 8,
    }
    return &http.Client{Transport: transport}
}

最后按这个顺序收口

1. 确认目标 URL 是 https，再检查 HTTPS_PROXY。
2. 直接调用 ProxyFromEnvironment，区分代理 URL、nil 与错误。
3. 检查 NO_PROXY 和 localhost 特殊规则。
4. 确认环境变量在当前进程第一次代理查询前已经存在。
5. 复用一个显式配置的 Transport，让诊断结果与真实请求使用同一代理函数。

这样处理后，HTTPS_PROXY 没有生效就不再是一个模糊的网络现象，而是可以定位到 scheme、排除规则、代理值格式或进程生命周期中的一个边界。

相关问题

为什么设置了 HTTPS_PROXY，HTTP 请求还是直连？

因为 HTTP 请求按 scheme 优先匹配 HTTP_PROXY。需要同时检查请求 URL 和对应变量。

NO_PROXY 为空字符串会不会禁用所有代理？

空的排除列表本身不会让所有请求直连；仍应结合代理变量、目标主机和返回的代理 URL 判断。

能不能每次修改环境变量后重新创建 Client？

重新创建 Client 不等于重置标准库内部的一次性代理配置。更可靠的方式是让环境在进程启动前就确定，或使用明确的自定义代理函数承担动态配置。