HTTPS 不是把 URL 改成 https 就结束
Go 调用外部 API 很方便，一个 http.Client 就能请求 HTTPS 服务。标准库默认会验证服务端证书，这对大多数场景是正确的。但在真实开发中，你可能遇到自签名证书、内网服务、测试环境证书过期、域名不匹配等问题。最危险的解决方式是随手写 InsecureSkipVerify: true，让证书验证完全失效。
安全入门最重要的不是记住复杂 TLS 参数，而是建立最小信任边界：默认验证证书，明确超时，理解证书错误，不要为了调通测试环境牺牲生产安全。
这篇文章讲 Go HTTP 客户端里几个最常见的 TLS 和安全配置。
默认客户端会验证证书
client := &http.Client{
Timeout: 5 * time.Second,
}
resp, err := client.Get("https://example.com")
if err != nil {
return err
}
defer resp.Body.Close()
默认情况下，Go 会使用系统根证书池验证服务端证书。如果证书过期、域名不匹配、证书链不可信，请求会失败。这是好事。失败说明客户端不能确认对方就是它声称的服务。
错误不要简单吞掉：
resp, err := client.Get(url)
if err != nil {
return fmt.Errorf("call %s: %w", url, err)
}
带上 URL 或服务名，排查时更清楚。
不要滥用 InsecureSkipVerify
你可能在网上看到：
transport := &http.Transport{
TLSClientConfig: &tls.Config{
InsecureSkipVerify: true,
},
}
client := &http.Client{Transport: transport}
这会跳过证书验证。它可能让测试环境“立刻能通”，但也让中间人攻击变得更容易。生产代码里不要这样做。
如果只是本地临时调试，至少要把它限制在本地配置，并避免提交：
if cfg.InsecureTLS {
return nil, fmt.Errorf("insecure tls is not allowed in production")
}
更好的方式是让测试环境使用可信证书，或者把内部 CA 加入信任池。
使用自定义根证书
如果内网服务使用公司内部 CA，可以加载 CA 文件：
func NewClientWithCA(caPath string) (*http.Client, error) {
caCert, err := os.ReadFile(caPath)
if err != nil {
return nil, fmt.Errorf("read ca file: %w", err)
}
pool, err := x509.SystemCertPool()
if err != nil {
return nil, fmt.Errorf("load system cert pool: %w", err)
}
if pool == nil {
pool = x509.NewCertPool()
}
if ok := pool.AppendCertsFromPEM(caCert); !ok {
return nil, fmt.Errorf("append ca cert failed")
}
transport := &http.Transport{
TLSClientConfig: &tls.Config{
RootCAs: pool,
MinVersion: tls.VersionTLS12,
},
}
return &http.Client{
Timeout: 5 * time.Second,
Transport: transport,
}, nil
}
这样仍然验证证书，只是额外信任你的内部 CA。比跳过验证安全得多。
设置请求超时
TLS 安全之外，可靠性也很重要：
client := &http.Client{
Timeout: 5 * time.Second,
}
每个请求也可以带 context：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return err
}
resp, err := client.Do(req)
没有超时的 HTTP 客户端可能在网络异常时长时间挂住。安全和可靠性经常是一起考虑的：你既要确认对方可信，也要限制自己等待多久。
证书错误不要只看表面
证书错误通常有具体原因。比如域名不匹配，可能说明你请求了 IP 地址，但证书签发给域名；证书过期，可能说明服务端部署流程有问题；根证书不可信，可能说明内网 CA 没配置，也可能说明请求被拦截。
排查时先打印带上下文的错误：
resp, err := client.Get(url)
if err != nil {
return fmt.Errorf("https request to %s failed: %w", url, err)
}
defer resp.Body.Close()
不要第一反应就是关闭验证。关闭验证会让所有证书问题都消失，也让安全边界一起消失。更好的处理顺序是：确认 URL 是否使用正确域名，确认证书是否有效，确认根 CA 是否被信任，最后才考虑是否需要为测试环境添加单独配置。
如果确实要在本地开发允许不安全 TLS，也应该把配置命名得非常刺眼：
if cfg.AllowInsecureTLS && cfg.Env == "production" {
return fmt.Errorf("ALLOW_INSECURE_TLS is forbidden in production")
}
让危险选项难以误用，是工程安全的一部分。
小结
Go 默认 HTTPS 客户端会验证服务端证书，这是安全边界的一部分。不要为了省事在生产代码里使用 InsecureSkipVerify: true。内网自签证书应该通过自定义根证书池解决，而不是跳过验证。
同时，HTTP 客户端要设置超时，错误要带上下文。调用外部服务时，调通只是第一步；可信、可控、可排查才是可靠客户端代码的目标。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。