Go net/http 怎样读取客户端真实请求地址

我第一次把 Go 服务放到反向代理后面时，日志里的地址从用户公网地址变成了代理内网地址。后来排查发现，“真实请求地址”并不是 http.Request 里一个永远可靠的字段：直连时看 RemoteAddr，经过代理时还要看转发头，但前提是这条代理链确实在自己的信任范围内。

官方文档：https://pkg.go.dev/net/http

转发字段规范：https://www.rfc-editor.org/rfc/rfc7239

最短结论：r.RemoteAddr 表示 Go 服务直接看到的 TCP 对端，通常是 IP:port；只有在确认请求来自可信反向代理时，才读取 X-Forwarded-For 或 Forwarded 作为客户端地址候选。未经信任的请求头不能直接用于鉴权、封禁或审计定论。

先分清 RemoteAddr 和转发头

在标准库 HTTP server 调用 handler 前，Go 会把 Request.RemoteAddr 设置成发送请求的网络地址，文档描述的常见格式是 IP:port。它回答的是“谁和当前 Go 进程建立了这条连接”，不是“最初的浏览器或客户端是谁”。

因此可以先把现象按部署方式分组：客户端直连 Go 时，RemoteAddr 通常就是客户端连接地址；客户端先访问 Nginx、云负载均衡或网关时，RemoteAddr 通常只剩最后一个代理节点。后者不是 Go 读错了，而是 TCP 连接的对端发生了变化。

先用 net.SplitHostPort 解析直接对端

不要用字符串切分冒号来取 IP。IPv6 地址本身包含多个冒号，应该交给 net.SplitHostPort；如果上游没有带端口，也保留原始值作为降级结果。这个小函数适合记录“Go 直接看到的地址”，不假设它就是最终用户地址。

package main

import (
    "net"
    "net/http"
)

// directPeerIP 只解析 Go 服务看到的 TCP 对端，不读取任何转发头。
func directPeerIP(r *http.Request) string {
    if r == nil || r.RemoteAddr == "" {
        return ""
    }

    // SplitHostPort 同时兼容 IPv4:port 和 [IPv6]:port。
    host, _, err := net.SplitHostPort(r.RemoteAddr)
    if err == nil {
        return host
    }

    // 某些测试请求或自定义 Server 可能只填了地址，保留原值便于排查。
    return r.RemoteAddr
}

我会把这个结果标成 direct_peer_ip，而不是直接命名为 client_ip。命名本身就是一道防错提示：后续看到代理头时，团队不会误以为这个字段已经代表最终客户端。

为什么不能无条件相信 X-Forwarded-For

X-Forwarded-For 是工程实践中很常见的请求头，但它不是 Go net/http 自动认证过的身份字段。客户端可以自己发送同名头；如果请求可以绕过代理直接到达 Go 服务，攻击者就可能伪造一个看似合理的地址。

所以，读取转发头前要先回答一个部署问题：哪些网络入口可以连接 Go 服务？如果只有固定的边缘代理网段可以访问，才有条件把来自这些代理的转发头纳入日志。若 Go 服务对公网开放，最稳妥的默认值仍是 RemoteAddr，并把转发头作为未验证的附加信息。

在明确代理信任边界后读取地址候选

下面的示例把“是否信任当前对端”作为调用方传入的判断结果。示例选择 X-Forwarded-For 最左侧的非空值作为候选，是常见代理链约定；实际项目必须与自己的网关配置保持一致。函数返回地址来源，方便日志同时记录判断依据。

package main

import (
    "net"
    "net/http"
    "strings"
)

// requestAddress 返回地址候选及其来源；trustedProxy 必须由部署边界决定。
func requestAddress(r *http.Request, trustedProxy bool) (string, string) {
    if r == nil {
        return "", "empty-request"
    }

    // 只有确认当前 TCP 对端是受信代理时，才使用代理提供的地址链。
    if trustedProxy {
        for _, item := range strings.Split(r.Header.Get("X-Forwarded-For"), ",") {
            candidate := strings.TrimSpace(item)
            if candidate != "" {
                return candidate, "x-forwarded-for"
            }
        }

        // Forwarded 是标准化表达之一；这里只保留头值，复杂语法交给专门解析器。
        if forwarded := strings.TrimSpace(r.Header.Get("Forwarded")); forwarded != "" {
            return forwarded, "forwarded"
        }
    }

    // 未经过可信代理，或转发头为空时，回退到 Go 直接看到的对端。
    peer := r.RemoteAddr
    if host, _, err := net.SplitHostPort(peer); err == nil {
        peer = host
    }
    return peer, "remote-addr"
}

这里故意没有把 Forwarded 头直接拆成某个 for= 参数。它可能包含多个元素、引号和 IPv6 方括号；如果业务必须精确读取标准字段，应选用明确支持该语法的解析方案，并先定义允许的代理格式。日志用途可以保留原始头，但不要把原始头当作已经验证的 IP。

把“地址读取”和“安全判断”分成两层

地址读取解决的是观测问题：请求日志、访问统计、问题排查需要一个可追溯的地址候选。安全判断解决的是策略问题：限流、封禁、审计归因或访问控制需要确认这个候选是否来自可信链路。两者混在一个 getClientIP 函数里，后续很容易把日志便利误用成安全依据。

日志里同时记录地址和来源

我更建议日志写成 address、address_source、remote_addr 三个字段，而不是只留一个“客户端 IP”。这样看到异常时，能判断是代理链变化、头部缺失，还是请求绕过了预期入口。记录时也要考虑隐私和保留周期，地址日志不应无限期保留。

func handler(w http.ResponseWriter, r *http.Request) {
    // trustedProxy 应来自已确认的网络入口判断，不由客户端参数决定。
    address, source := requestAddress(r, trustedProxyFor(r.RemoteAddr))

    // 同时记录来源，避免把转发头候选误读为已经认证的身份。
    log.Printf("address=%q source=%q remote_addr=%q", address, source, r.RemoteAddr)
    w.WriteHeader(http.StatusNoContent)
}

上面只演示字段设计，没有把地址拿去做权限决策。真正的 trustedProxyFor 应该基于固定配置、网络边界或网关已完成的身份传递，不应该依据 X-Forwarded-For 自己判断“我来自代理”。

常见问题

RemoteAddr 是不是一定就是用户公网 IP？

不是。它是 Go HTTP server 看到的直接网络对端；经过反向代理时，通常是最后一个代理的地址。

能不能直接取 X-Real-IP？

可以把它作为某些代理约定的候选头，但信任前提和 X-Forwarded-For 一样：请求必须不能绕过可信代理，且头部格式由网关统一管理。

为什么 IPv6 不能用 strings.Split(addr, ":")？

IPv6 地址本身包含多个冒号，简单切分无法区分地址和端口。使用 net.SplitHostPort，并兼容没有端口的降级情况。

读取到的地址可以直接用于封禁吗？

不要直接使用未经验证的转发头做封禁或鉴权。先固定可信代理边界，再统一解析、限流和审计策略。

总结

Go 的 net/http 已经给出了可靠的直接对端入口：Request.RemoteAddr。当服务部署在代理后面时，所谓“客户端真实地址”变成了一个带部署前提的问题：先确认当前对端是否可信，再选择转发头候选，并始终保留来源和回退值。这样既能让日志恢复可读性，也不会把一个可伪造的请求头误当成安全事实。