真正安全的 ip_hash 需同时确保 ip 来源可信、后端列表稳定、头透传克制；须启用 real_ip_module 严格限制可信代理段，禁用伪造头透传，并规范 upstream 配置以防会话劫持或流量倾斜。
ip_hash 本身不提供“安全过滤”，它只是会话保持机制；所谓“安全的 ip_hash 反向代理头过滤”，本质是两件事：一是正确提取真实客户端 IP 用于哈希，二是防止恶意或伪造请求头干扰这一过程。配置不当会导致所有流量打到同一台后端，或被攻击者绕过会话绑定。
确保真实 IP 被可信还原，不被伪造头污染
必须启用 real_ip_module 并严格限制可信代理段，否则攻击者可构造 X-Forwarded-For: 1.2.3.4 强行指定哈希源，造成会话劫持或流量倾斜：
- 在
http块中明确声明可信代理网段（仅填你实际部署的 CDN、WAF 或前置 LB 内网地址）：set_real_ip_from 192.168.10.0/24;set_real_ip_from 10.200.0.0/16;
禁止写set_real_ip_from 0.0.0.0/0;
—— 这等于完全信任任意请求头，高危 - 指定头字段并启用严格模式：
real_ip_header X-Forwarded-For;<br><code>real_ip_recursive on;（启用递归解析，取最左端非可信段 IP） - 验证是否生效：在日志格式中加入
$remote_addr $http_x_forwarded_for，确认两者差异合理，且$remote_addr已变为公网用户 IP
过滤和清理不可信请求头，防伪造与信息泄露
即使 IP 还原正确，仍需阻止攻击者通过请求头注入、探测或污染后端服务：
- 清除可能被伪造的敏感头，避免透传给后端：
proxy_hide_header X-Forwarded-For;proxy_hide_header X-Real-IP;
（后端应只从 Nginx 的$remote_addr获取 IP，而非信任请求头） - 重写或删除可疑头字段，尤其禁用任意自定义头冒充身份：
proxy_set_header X-Forwarded-For "";proxy_set_header X-Real-IP "";
（若后端不依赖这些头，直接清空更安全） - 禁止传递编码或压缩类头，防范响应体篡改：
proxy_set_header Accept-Encoding "";proxy_set_header Upgrade "";proxy_set_header Connection "";
配合 upstream 稳定性与可观测性，降低误配风险
安全不只是防攻击，也包括防配置漂移导致的会话断裂或单点压垮：
- upstream 中只写 IP:PORT，不加
weight、backup、max_fails等参数（ip_hash 不兼容，启动即报错） - 故障节点用
server 10.0.1.10:8080 down;标记，而非直接删除——避免哈希重散列引发批量会话丢失 - 日志中固定记录关键字段，便于事后审计：
log_format secure_hash '$remote_addr – $upstream_addr [$time_local] "$request" $status $body_bytes_sent';
真正安全的 ip_hash，不是靠加一堆头过滤指令堆出来，而是从 IP 来源可信、后端列表稳定、头透传克制这三点同时守住。配错一步，就可能把会话保持变成会话劫持入口。
