ip_hash仅保证同IP请求路由一致，无认证能力，须与Token认证协同：前者管路由，后者管身份；需配置real_ip_module还原真实IP、透传Token并校验签名与IP一致性，NAT场景推荐hash $cookie_atrust_token。

ip_hash 本身不提供认证能力，它只是把同一 IP 的请求固定发到同一台后端服务器。要真正保障安全会话，必须让它和 Token 认证协同工作——ip_hash管“路由一致性”，Token 管“身份可信性”。两者缺一不可。

基础配置：先让 ip_hash 正确生效

ip_hash 必须放在 upstream 块的第一行，且不能与 weight、backup 等参数共存：

• upstream 中至少定义两台后端服务，单节点无效
• IPv4 地址只取前三段哈希（如 192.168.1.100 和 192.168.1.200 被视为同一 IP）
• 若前端有 CDN、WAF 或代理，$remote_addr 默认是代理内网地址，需用 real_ip_module 还原真实 IP：
  set_real_ip_from 10.0.0.0/8;
  set_real_ip_from 192.168.0.0/16;
  real_ip_header X-Forwarded-For;

Token 验证必须独立完成，不能依赖 ip_hash

Token 校验逻辑必须由后端服务或专用网关执行，Nginx 只负责透传和路由：

大模型Token成本节约

大模型 Token 成本节约工具。在请求到达大模型之前自动压缩 prompt 和上下文，减少 60-95% 的 token 消耗，直接降低 API 成本。支持 Claude/OpenAI/Gemini 等主流模型，提供代理模式、CLI 包装、Python SDK 和 MCP Server 四种接入方式。内置一键安...

下载

• JWT 必须验证签名有效性、exp/nbf 时间窗口（建议 exp ≤ 15 分钟）
• 校验 jti + Redis 记录，防止重放；检查 azp/aud 是否匹配当前业务网关
• 可选增强：绑定 device_id、TLS 指纹、地理位置等上下文字段
• Nginx 不做任何 Token 解析，只通过 proxy_set_header 将原始 Authorization 或 Cookie 透传给后端

防伪造与 IP 一致性校验（关键安全层）

攻击者可伪造 X-Forwarded-For，仅靠 ip_hash 完全无法防御。必须叠加三层防护：

• Nginx 清除不可信头：
  proxy_set_header X-Forwarded-For "";
  proxy_hide_header X-Forwarded-For;
• Nginx 固定写入可信真实 IP：
  proxy_set_header X-Real-IP $remote_addr;
• 后端服务在登录成功后，将 X-Real-IP 存入 Token 或 Session；后续每次敏感请求都比对当前 X-Real-IP 与存储值是否一致，不一致则拒绝并告警

更可靠的替代方案（推荐用于生产）

当用户大量经过 NAT 或移动网络时，ip_hash 失效风险高。此时建议改用基于 Token 的哈希：

• 首次认证成功后，后端在响应中 Set-Cookie 写入 atrust_token
• upstream 中改用：
  hash $cookie_atrust_token consistent;
• 该方式不受 NAT 影响，只要 Token 有效，路由就稳定
• 需确保 Cookie 未被客户端篡改（配合 HttpOnly + Secure + SameSite 属性）