ip_hash不符合零信任原则，因其依赖易伪造、共享的ip地址标识客户端，无法验证真实身份、不参与token校验、不支持动态策略决策，违背零信任“永不信任，持续验证”的核心思想。
ip_hash 本身不适用于零信任边缘准入系统，不能与 Token 验证“配合”构建合规的零信任机制。
为什么 ip_hash 不符合零信任原则
ip_hash 是 Nginx 的负载均衡策略，作用是将同一客户端 IP 的请求始终转发到同一台后端服务器。它依赖的是网络层 IP 地址，而零信任明确否定“IP 可信”这一假设：
- IP 地址极易伪造、复用或共享（如 NAT 网关、代理、公共 Wi-Fi）
- 无法标识真实用户身份，也无法绑定设备、会话或上下文
- 不参与认证、不校验 Token、不支持动态策略决策
- 若仅靠 ip_hash 转发请求，相当于把 Token 校验逻辑下放到单台后端，丧失统一鉴权入口和策略一致性
真正可行的零信任边缘准入架构
应以身份为中心，在边缘网关（如 Envoy、Traefik、Nginx + OpenResty + JWT 插件）完成 Token 解析、签名验证、声明提取与策略执行：
- Token 必须由可信 IdP（如 Keycloak、Auth0、aTrust）签发，含 sub、exp、aud、scope 等标准字段，建议使用 RS256 或 ES256 签名
- 边缘层强制校验 JWT：验证签名有效性、有效期、受众（aud）、颁发者（iss），拒绝无 Token 或无效 Token 的请求
- 提取身份并透传：将 verified_user_id、roles、device_id 等关键声明注入请求头（如 X-User-ID、X-Roles），供后端服务做细粒度授权
- 集成动态策略引擎：在网关侧调用 OPA 或本地策略模块，结合时间、地理位置、设备指纹等实时上下文做放行/挑战/拒绝决策
如果必须用 Nginx，正确做法是替代 ip_hash
放弃基于 IP 的路由逻辑，改用以下组合实现安全、可扩展的边缘准入：
- 启用 JWT Auth 模块（如 openresty/jwt、nginx-plus 的 auth_jwt 指令）校验 Token 并设置变量
- 用 map 指令+set_by_lua* 提取 Token 中的 sub 或 client_id，作为上游分发依据（非 IP）
- 后端服务按需做二次校验（如检查 X-User-ID 是否在允许列表），但核心鉴权必须前置到边缘
- 所有流量走 HTTPS，禁用 HTTP 明文传输 Token；敏感 Header（如 Authorization）不在日志中记录
典型错误配置示例（应避免）
以下写法看似“结合”，实则破坏零信任模型：
upstream backend {
ip_hash; # ❌ 仅靠 IP 绑定，Token 可能未校验或被绕过
server 10.1.1.10:8080;
server 10.1.1.11:8080;
}
location /api/ {
proxy_pass http://backend;
proxy_set_header Authorization $http_authorization; # ❌ 未校验就透传
}
这种配置下，攻击者只要拿到一个有效 Token，就能通过任意 IP 发起请求，且负载完全依赖 IP，失去策略控制能力。
