Go 用 IP 连接 HTTPS 为什么会证书域名不匹配

Go 程序把 HTTPS 地址从 https://api.example.com 改成 https://203.0.113.10，最常见的结果不是 TCP 连接失败，而是证书校验报“证书对该主机无效”。原因在于：IP 只是网络连接目标，证书校验还需要一个名称；如果这个名称是 IP，证书的 IP SAN（Subject Alternative Name）里也必须有同一个 IP。

要连指定 IP、但仍按域名验证 HTTPS，做法是让拨号地址和 TLS 的 ServerName 分开：网络层连 IP，TLS 层使用证书上的域名，保持默认证书校验开启。

Go 用 IP 连接 HTTPS 时到底比对了什么

HTTPS 请求至少有三层名称容易被混淆。net.Dial关心“连哪台机器”；TLS 握手关心“服务端为哪个名称提供证书”；HTTP 请求头的 Host 则属于应用层路由。它们可以相同，也可以在特殊部署中不同。

当 URL 主机名就是 IP 时，默认配置会把这个 IP 当作校验目标。x509.Certificate.VerifyHostname对 IP 检查证书的 IPAddresses，对域名检查 DNSNames，旧证书只写 Common Name 也不能再当作可靠补救。于是“证书链可信”与“名称匹配”是两次不同判断。

用 net.Dial + tls.Client 看清两个主机名

如果网络策略要求固定连某个 IP，但证书签发给域名，可以先用 net.Dialer连接 IP，再把这条连接交给 TLS 客户端，并明确设置 ServerName。下面的示例仍使用系统根证书池，未关闭默认校验。

package main

import (
    "crypto/tls"
    "fmt"
    "net"
    "time"
)

func dialHTTPSByIP() error {
    // 网络层固定连接 IP，避免 DNS 解析到不希望使用的地址。
    dialer := &net.Dialer{Timeout: 5 * time.Second}
    rawConn, err := dialer.Dial("tcp", "203.0.113.10:443")
    if err != nil {
        return fmt.Errorf("连接 IP 失败: %w", err)
    }

    // TLS 层按证书域名校验，并为虚拟主机发送对应的 SNI。
    config := &tls.Config{ServerName: "api.example.com"}
    conn := tls.Client(rawConn, config)
    if err := conn.Handshake(); err != nil {
        _ = rawConn.Close() // 握手失败也要释放底层连接。
        return fmt.Errorf("TLS 握手失败: %w", err)
    }
    defer conn.Close()

    fmt.Println("TLS 服务端:", conn.ConnectionState().ServerName)
    return nil
}

这里的两个值故意不同：203.0.113.10:443是去向，api.example.com是 TLS 名称。若证书 SAN 包含 api.example.com，且系统信任链完整，握手就有机会通过；若把 ServerName也填成 IP，则证书必须把该 IP 写进 IPAddresses。

注意底层连接的所有权：成功后由 tls.Conn负责关闭；握手失败时示例显式关闭原始连接。实际发 HTTP 请求时，还要根据服务端路由需要设置请求的 Host，它不会替代 TLS 的证书校验。

证书和网络配置的排查清单

遇到“证书域名不匹配”时，先看错误中出现的实际校验名，再按下面顺序对照，别一上来就改成跳过校验。

1. 确认拨号地址：程序实际连接的是哪个 IP 和端口，是否经过代理、负载均衡或服务网格。
2. 确认 ServerName：它是否是证书上的域名，而不是误填的 IP、端口或完整 URL。
3. 确认证书 SAN：域名看 DNSNames，IP 看 IPAddresses；通配符只覆盖合法的最左侧域名标签。
4. 确认服务端选证书：多租户 HTTPS 依赖 SNI，ServerName错误时可能拿到默认站点证书。
5. 最后区分 HTTP Host：它解决应用层路由，不会让一张不匹配的证书变得匹配。

如果证书本来就应该服务这个固定 IP，正确修复是重新签发包含该 IP 的证书，并让客户端按 IP 校验。如果证书属于稳定域名，推荐保留域名作为 ServerName，仅在拨号层固定 IP。两种方案都比关闭校验更容易审计。

常见问题

把 InsecureSkipVerify 设为 true 能解决吗？

它会接受任意服务端证书和其中的主机名，确实可能让握手继续，但也失去默认的中间人防护。除非是测试或同时实现了严谨的自定义校验，否则不应在生产使用。

只设置 HTTP 的 Host 头可以吗？

不可以。HTTP 请求发生在 TLS 握手之后，Host 只能影响应用层路由；证书名称必须在握手阶段由 ServerName和证书 SAN 解决。

证书 Common Name 写对了为什么仍失败？

现代 Go 的主机名校验以 SAN 为准，Common Name 被忽略。请检查证书的 DNS SAN 或 IP SAN，并确认服务端发送的是正确的叶子证书。

排查这类问题时可以记住一句话：IP 决定“连到哪里”，ServerName决定“按谁验证”，证书 SAN 决定“谁被允许”。把三者分别核对，通常不需要牺牲 HTTPS 的安全校验。