HTTPS重定向后仍能获取真实客户端IP，关键在于代理链路中X-Real-IP、X-Forwarded-For和X-Forwarded-Proto等头的完整透传与后端可信解析；前端Nginx需显式设置这些头，后端须启用realip模块并配置可信源，应用层主动读取HTTP_X_REAL_IP而非REMOTE_ADDR。
HTTPS 重定向后仍能拿到真实客户端 IP，关键不是重定向本身，而是整个代理链路中 IP 头的传递与后端可信解析是否连贯。重定向（比如 HTTP → HTTPS）只是状态码跳转，不影响后续请求的头信息；真正决定 IP 是否丢失的，是 Nginx 作为反向代理时是否透传、后端是否信任并正确读取这些头。
前端 Nginx 必须透传原始 IP 和协议信息
即使做了 301 跳转，只要用户最终访问的是 HTTPS 地址，Nginx 就仍是 SSL 终结点。此时必须在 location 块中显式设置以下头，确保后端既知道用户真实 IP，也清楚原始请求是 HTTPS：
-
proxy_set_header X-Real-IP $remote_addr;—— 直接传递直连 Nginx 的客户端 IP（若前有 CDN，需配合$http_x_forwarded_for） -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;—— 追加当前请求 IP 到已有链路末尾，保留多级代理路径 -
proxy_set_header X-Forwarded-Proto $scheme;—— 动态传https或http，避免后端因误判协议触发重定向循环 -
proxy_set_header Host $host;—— 确保后端生成跳转链接时用的是用户实际访问的域名，而非内部地址
后端服务需启用并信任这些头
Nginx 传了头，后端不认等于白传。不同框架处理方式不同，但核心逻辑一致：
-
Spring Boot：需配置
server.forward-headers-strategy=framework，并设trusted-proxies为 Nginx 出口 IP 段（如192.168.10.0/24） -
Django：启用
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，并配置USE_X_FORWARDED_HOST和USE_X_FORWARDED_PORT -
WordPress：在
wp-config.php中添加$_SERVER['HTTPS'] = 'on';和$_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https';，同时确认WP_HOME和WP_SITEURL使用 HTTPS 协议
避免常见断点：CDN 或多层代理场景
如果流量经过 Cloudflare、阿里云 SLB 等中间层，它们通常会自带 X-Forwarded-For 和 X-Forwarded-Proto，但不能直接信任。建议：
- 优先读取已有的
X-Forwarded-Proto：用proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - 兜底 fallback 到
$scheme：配合map指令，防止 CDN 未传该头时协议误判 - 限制可信代理段：后端只信任来自 Nginx 出口 IP 的头，拒绝其他来源伪造，避免 IP 欺骗
验证是否生效的简单方法
不用重启服务，只需临时加一条日志或调试输出：
- 在 Nginx access log 中加入
$http_x_forwarded_for和$http_x_real_ip字段，对比$remote_addr - 后端打印
request.getHeader("X-Real-IP")和request.getRemoteAddr()，看二者是否一致且非内网地址 - 用 curl 模拟带
X-Forwarded-For的请求：curl -H "X-Forwarded-For: 203.0.113.5" https://your-domain.com/test，检查后端是否返回该 IP
