Gin中实现IP段白名单/黑名单需用gin.HandlerFunc中间件配合net.ParseCIDR和net.IPNet.Contains，必须配置TrustedProxies与RemoteIPHeaders以正确解析真实客户端IP，支持IPv4/IPv6，网段列表应预解析并缓存，挂载到RouterGroup统一控制。
如何在Gin中实现IP段白名单/黑名单拦截
直接说结论：Gin本身没有“路由过滤器”概念，但可以通过gin.HandlerFunc中间件 + net.ParseIP和net.Contains实现精确的CIDR网段控制。别试图用正则匹配IP字符串，容易漏判或误判。
常见错误是把ctx.ClientIP()返回值直接做字符串前缀比较（比如strings.HasPrefix(ip, "192.168.1.")），这在IPv6、代理转发、X-Forwarded-For污染场景下完全不可靠。
- 务必调用
ctx.ClientIP()获取经Gin可信头解析后的客户端真实IP - 用
net.ParseCIDR("192.168.1.0/24")解析网段，再用_, ok := subnet.Contains(ip)判断归属 - 若需支持多网段，提前把
*net.IPNet切片缓存，避免每次请求重复解析
处理反向代理下的IP识别失效问题
当服务部署在Nginx或Cloudflare后，ctx.ClientIP()可能返回127.0.0.1或代理IP。必须配置Gin的RemoteIPHeaders和TrustedProxies。
关键点不是“加个中间件”，而是让Gin信任上游代理的X-Forwarded-For头，并明确指定哪些代理IP是可信的——否则会被人伪造头绕过限制。
立即学习“go语言免费学习笔记（深入）”；
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 启动时设置：
router.TrustedPlatform = gin.PlatformCloudflare（或gin.PlatformCustom） - 手动配置可信代理：
router.SetTrustedProxies([]string{"10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"}) - 确认
ctx.ClientIP()返回值不再为127.0.0.1，而应是原始客户端IP
按路由组应用不同网段策略
不需要给每个GET/POST单独写中间件。Gin的gin.RouterGroup天然支持中间件链，把网段校验逻辑绑定到特定分组最干净。
注意：中间件注册顺序决定执行时机。网段检查必须放在鉴权、参数绑定等后续逻辑之前，否则可能浪费资源处理非法请求。
- 定义中间件：
func IPRangeMiddleware(allowedNets []*net.IPNet) gin.HandlerFunc - 挂载到分组：
admin := router.Group("/admin", IPRangeMiddleware(adminNets)) - 拒绝时统一返回
ctx.AbortWithStatusJSON(403, gin.H{"error": "forbidden by ip policy"})，不要用return
IPv6网段兼容性与性能影响
如果业务面向公网且未禁用IPv6，net.ParseCIDR("2001:db8::/32")必须能正常工作。Gin默认支持IPv6，但部分老旧Linux内核或Docker网络配置可能导致ClientIP()无法提取v6地址。
实测发现，对单个请求做3–5次IPNet.Contains()判断几乎无开销（纳秒级），但若网段列表超100条，建议改用iprange类库做区间合并+二分查找。
- 测试IPv6可用性：
curl -g -6 http://[::1]:8080/ping，观察ctx.ClientIP()是否返回::1 - 避免在中间件里重复调用
net.ParseCIDR——它涉及字符串解析和掩码计算，应预热到全局变量 - 日志中记录被拒绝的IP时，用
ip.String()而非fmt.Sprintf("%v", ip)，后者对IPv6输出带括号格式易引发解析歧义
真正麻烦的是混合部署场景：内部服务走内网IPv4，外部用户走IPv6，而你的白名单只写了10.0.0.0/8却忘了加fd00::/8。这种遗漏不会报错，只会静默拒绝——得靠真实流量日志交叉比对才能发现。
