根本原因是Gin默认不信任任何代理，c.ClientIP()会fallback到c.Request.RemoteAddr（即上一跳IP，常为127.0.0.1或内网IP）；必须显式调用SetTrustedProxies传入合法CIDR网段，否则不解析X-Forwarded-For。
为什么c.ClientIP()返回127.0.0.1或Ingress IP
根本原因不是 Gin 有 bug，而是它默认不信任任何代理——Nginx、Traefik、K8s Ingress 都算“不可信”，所以 c.ClientIP() 只会 fallback 到 c.Request.RemoteAddr，也就是上一跳的 IP（常是 127.0.0.1 或集群内网 IP）。
从 v1.7 开始，Gin 强制要求显式配置可信代理列表，否则不会解析 X-Forwarded-For。你必须调用 engine.SetTrustedProxies()，且传入的 CIDR 必须覆盖所有前置代理的真实出口 IP 段。
- 若只用一层 Nginx，且它跑在 192.168.1.10，就写
r.SetTrustedProxies([]string{"192.168.1.10/32"}) - 若走 K8s Ingress（如 Nginx Ingress Controller），查它的 Service ClusterIP 或 NodePort 节点 IP 段，比如
10.96.0.0/12或192.168.0.0/16，不能填0.0.0.0/0（极度危险） - 填错会导致
c.ClientIP()返回空，或返回中间代理 IP 而非真实客户端 IP
SetTrustedProxies 的参数必须是 CIDR，不是单个 IP 字符串
SetTrustedProxies 接收的是 []string，但每个元素必须是合法 CIDR 表达式，比如 "127.0.0.1/32"、"10.0.0.0/8"，不能传 "127.0.0.1" 或 "localhost"——后者会被 net.ParseCIDR 解析失败，整个配置静默失效。
常见错误：把 Nginx 容器名（如 nginx）或域名（如 ingress-nginx-controller）直接塞进去，结果 Gin 启动无报错，但 c.ClientIP() 始终不准。
- 验证方法：启动后打印
r.TrustedProxies，确认是解析后的*net.IPNet切片，不是空或 nil - 若用 Helm 部署 Ingress，查
kubectl get svc -n ingress-nginx的ClusterIP，再结合kubectl cluster-info看 Service CIDR - 本地开发用 Docker Compose 时，Nginx 和 Gin 在同一网络，可用
172.18.0.0/16（具体看docker network inspect输出）
router.Run() 绑定地址不写 0.0.0.0 导致反向代理连不上
Gin 默认 router.Run() 绑定 :8080，等价于 127.0.0.1:8080，这意味着只有本机进程能访问——Nginx 作为另一个容器或宿主机进程，发请求过去会直接 connection refused。
必须显式绑定 0.0.0.0:8080（或 :8080 加 net.Listen("tcp", ":8080") 自定义 listener）。
- 别写
"localhost:8080"：Go 会解析为127.0.0.1，同样对外不可达 - 若用 systemd 托管，确保
WorkingDirectory正确，否则go build产出的二进制可能找不到配置文件，启动失败但日志不明显 - 加
-ldflags="-s -w"编译，否则二进制体积大、启动慢，尤其在低配云服务器上感知明显
Nginx 透传头缺失引发的连锁故障
即使 Gin 信任了代理，如果 Nginx 没透传关键头，c.Request.Host、c.Request.TLS、c.GetHeader("X-Forwarded-Proto") 全部失真，后果包括：
- 重定向跳转到
http://127.0.0.1:8080/login而非真实域名 - Secure Cookie 不生效（因为 Gin 认为不是 HTTPS 请求）
-
c.ClientIP()仍为空（因X-Forwarded-For没传过来）
Nginx 配置里这四行不能少：
proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
注意：$proxy_add_x_forwarded_for 是追加模式，比 $remote_addr 更安全；$scheme 要和实际 TLS 终止位置一致（Nginx 终止就填 $scheme，LB 终止就得硬编码 https）。
最易忽略的一点：Gin 日志中间件里打出来的 c.ClientIP() 是最终结果，但调试时若只看 Nginx access_log，会误判问题出在 Nginx——其实 Gin 层没收到头，才是根因。
