req.RemoteAddr 经常不准是因为客户端通常经过 Nginx、CDN 或云负载均衡，它只返回最后一跳代理 IP；真实用户 IP 需通过校验可信代理后解析 X-Forwarded-For 最左非私有 IP 获取。
Go HTTP 服务中 req.RemoteAddr 为什么经常不准
因为客户端通常经过 Nginx、CDN 或云负载均衡（如阿里云 SLB、AWS ALB），req.RemoteAddr 拿到的只是最后一跳代理的 IP，不是真实用户 IP。直接用它做限流、日志或风控，会误判甚至失效。
真正能反映用户来源的字段，往往藏在请求头里，但必须配合可信代理列表校验，否则极易被伪造。
-
X-Forwarded-For是最常见字段，格式如"203.0.113.195, 203.0.113.196, 203.0.113.197"，最左边是原始客户端，越往右是越靠近服务端的代理 -
X-Real-IP是 Nginx 常用字段，只存一个 IP，但只在 Nginx 显式配置proxy_set_header X-Real-IP $remote_addr;后才可靠 - 必须限制只信任你自己的反向代理（比如 Nginx 的内网 IP），否则攻击者可手动加
X-Forwarded-For: 1.2.3.4伪造
如何安全地从 *http.Request 提取真实客户端 IP
别自己写字符串切分逻辑。用标准库 net/http 提供的 req.RemoteAddr + 可信代理白名单组合判断，是最轻量也最稳妥的方式。
关键点：先解析 req.RemoteAddr 得到直连 IP，再检查它是否属于你信任的代理网段；如果是，才从 X-Forwarded-For 取最左非私有 IP；否则直接用该 IP。
立即学习“go语言免费学习笔记（深入）”；
- 私有 IP（如
10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.1）不能作为最终结果，它们大概率是代理内网地址 - Go 标准库没有内置 IP 段判断，可用
net.ParseIP+net.IPNet.Contains手动校验，或引入轻量库如github.com/miekg/dns的 IP 工具函数（但通常不必要） - 示例逻辑片段：
func getClientIP(req *http.Request) string {
ip := strings.TrimSpace(strings.Split(req.RemoteAddr, ":")[0])
if isTrustedProxy(ip) {
if xff := req.Header.Get("X-Forwarded-For"); xff != "" {
for _, ip = range strings.Split(xff, ",") {
ip = strings.TrimSpace(ip)
if !isPrivateIP(ip) {
return ip
}
}
}
// fallback to X-Real-IP if XFF empty or all private
if realIP := req.Header.Get("X-Real-IP"); realIP != "" && !isPrivateIP(realIP) {
return realIP
}
}
if !isPrivateIP(ip) {
return ip
}
return "0.0.0.0"
}
isTrustedProxy 和 isPrivateIP 怎么写才靠谱
信任代理必须显式声明，不能靠 “是不是内网” 自动推断——有些 CDN 节点用的是公网 IP，但仍是可信代理；而某些私有云 LB 可能用的是公网 IP 段。
-
isTrustedProxy应基于配置（如环境变量或 config struct），例如：[]string{"10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.1/32"}，然后用net.ParseCIDR解析后调用IPNet.Contains -
isPrivateIP不要只比对字符串前缀（如strings.HasPrefix(ip, "10.")），要用net.ParseIP转成net.IP再匹配 CIDR，否则 IPv6 或带端口的地址会出错 - 注意：Go 的
net.ParseIP对 IPv6 地址返回长度为 16 的字节切片，对 IPv4 返回长度为 4 的；用net.ParseCIDR解析 CIDR 时，IPv6 需用双括号格式（如"::1/128"），但实际中X-Forwarded-For几乎不用 IPv6 列表（除非你主动开启）
用第三方中间件（如 gorilla/handlers）要注意什么
gorilla/handlers.ProxyHeaders 确实能自动处理 X-Forwarded-For，但它默认信任所有来源的 X-Forwarded-For 头——只要请求带了这个头，就无条件覆盖 req.RemoteAddr。这在生产环境非常危险。
- 必须配合
handlers.ForwardedAllowIP显式设置可信代理网段，例如：handlers.ForwardedAllowIP("10.0.0.0/8") - 如果用了多层代理（如 CDN → Nginx → Go），要确保每层都正确传递并追加
X-Forwarded-For，且中间任何一层都不能重写或截断 - Cloudflare 等 CDN 还会提供
Cf-Connecting-Ip头，但它只在启用“真实 IP 插件”且未被其他代理覆盖时有效；优先级应低于经校验的X-Forwarded-For，且同样需验证来源是否可信
真实线上环境里，IP 来源链路越长，校验逻辑越得收紧——少一个 isPrivateIP 判断，就可能把内网运维机的 IP 当作用户 IP 记进审计日志。
