因为ctx.ClientIP()默认只信任127.0.0.1，未配置SetTrustedProxies时无法校验X-Forwarded-For有效性，会返回代理内网IP而非真实客户端IP。
为什么 ctx.ClientIP() 拿不到真实客户端IP
直接调用 ctx.ClientIP() 在大多数生产环境里返回的是反向代理（比如 Nginx、Cloudflare）的 IP，而不是用户真实 IP。Gin 默认只看 X-Forwarded-For，但没做可信跳数校验，容易被伪造。
正确做法是结合 RemoteAddr 和可信代理列表做逐跳解析。需要先配置 Gin 的 TrustedProxies：
router := gin.New()
router.SetTrustedProxies([]string{"127.0.0.1", "10.0.0.0/8"}) // 根据实际代理网段填
- 必须显式设置，否则
ClientIP()不验证X-Forwarded-For有效性 - 填错会导致所有请求都 fallback 到
RemoteAddr，比如填成0.0.0.0/0就完全失去防护意义 - Cloudflare 用户要加它的 IP 段（如
"173.245.48.0/20"），且确保 Nginx 已透传X-Forwarded-For和X-Real-IP
用 net/http 原生限流器还是选第三方库
别自己用 time.Ticker + map 做计数——并发写 map panic、没过期清理、不支持分布式，三者必中其一。
推荐两个轻量方案：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
golang.org/x/time/rate：适合单机、规则简单（如“每秒最多 5 次”）。注意它按时间窗口滑动，不是固定周期清零 -
github.com/ulule/limiter/v3：支持内存/Redis 后端、多策略（fixed window、sliding log）、可组合键（IP + path）。默认用memory时性能足够，升级 Redis 只需换存储驱动
示例（Limiter + Gin 中间件）：
store := memory.NewStore()
rate, _ := rate.NewRateFromFormatted("10-M") // 10次/分钟
limiter := limiter.New(store, rate)
middleware := limiter.Middleware(func(ctx context.Context) string {
return ctx.Value("client_ip").(string) // 提前从 ctx 取好 IP
})
IP 提取后要不要做标准化处理
IPv6 地址带冒号、缩写（::1）、端口（[::1]:12345）都会导致同一 IP 被当成多个 key。不处理等于限流失效。
- 用
net.ParseIP()解析后再调.To16()统一转为 16 字节格式（IPv4 补高位零，IPv6 不变） - 丢弃端口号：对
RemoteAddr做strings.Split(addr, ":")[0]，但仅限未经过代理的情况；经代理后应以X-Forwarded-For最左 IP 为准 - 特别注意 IPv4 映射的 IPv6 格式（
::ffff:192.168.1.1），要用ip.To4() != nil判断是否该转回 IPv4 字符串再哈希
高频误报时怎么快速定位是规则问题还是代理配置问题
加一行日志比改代码快：
ip := ctx.ClientIP()
realIP := ctx.GetHeader("X-Forwarded-For")
gin.DefaultWriter.Write([]byte(fmt.Sprintf("IP=%s, XFF=%s, Remote=%s\n", ip, realIP, ctx.Request.RemoteAddr)))
- 如果
X-Forwarded-For是空，说明上游代理没透传，查 Nginx 配置里的proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 如果
ClientIP()和X-Forwarded-For最左 IP 不一致，说明TrustedProxies没覆盖到某一级代理 - 如果日志里出现大量
127.0.0.1或内网 IP，基本确定代理链末端没设对X-Real-IP
真实环境里，IP 来源链路越长，中间环节出错概率越高。宁可多打两行日志，也别靠猜。
