nginx upstream 不支持 ntlm 协议解析或中继，所谓“ntlm 负载均衡”实为通过 ip_hash、keepalive、http/1.1 长连接等强制会话粘性，使三次握手落在同一后端；真正推荐方案是弃用 ntlm，改用 kerberos——无需特殊 upstream 配置，可自由使用轮询、健康检查等全部策略。
NGINX upstream 块里没有 ntlm 参数，也不存在官方支持的 NTLM 协议解析或中继能力。所谓“NTLM 负载均衡”，本质是绕过协议限制、用连接控制策略模拟会话粘性，让 NTLM 三次握手（NEGOTIATE → CHALLENGE → AUTHENTICATE）始终落在同一台后端服务器上。
直接启用轮询（如默认 round-robin 或 least_conn）会导致认证失败——因为三次请求被分发到不同节点，后端无法完成状态化挑战-响应流程。
所以，“支持 NTLM 的集群轮询”这个目标本身存在矛盾。真正可行的是以下两类路径：
必须启用的连接粘性配置（非轮询，但能“跑通”NTLM）
-
ip_hash：按客户端 IP 哈希固定后端，最常用 -
keepalive N：在 upstream 中声明长连接池数量（如keepalive 32） - 禁用连接头干扰：在 location 中设置
proxy_http_version 1.1; proxy_set_header Connection '';
- 关闭缓冲：
proxy_buffering off;，防止 Type-2 Challenge 被截断或延迟 - 不使用
weight、least_conn、hash $cookie_xxx等动态调度指令
示例 upstream：
upstream crm_backend {
ip_hash;
server 10.20.30.101:80;
server 10.20.30.102:80;
keepalive 60;
}
⚠️ 注意：
ip_hash在 NAT 环境（如办公网出口共用一个公网 IP）下会导致所有用户被路由到同一台后端，失去负载意义；且不支持 IPv6 哈希（需额外补丁）。
更推荐的解法：放弃 NTLM，改用 Kerberos（真正支持轮询）
这才是微软官方建议、安全合规、且与 NGINX 完全兼容的方案：
- 后端 IIS 开启 Windows 身份验证，强制 Kerberos（注册正确 SPN，禁用 NTLM 回退）
- 客户端加入域并配置组策略启用 Kerberos 协商
- NGINX 无需特殊 upstream 配置，可自由使用轮询、加权、健康检查等全部策略
- 只需透传头部：
proxy_set_header Authorization $http_authorization; proxy_pass_request_headers on; proxy_pass_header WWW-Authenticate;
此时 upstream 可回归标准轮询：
upstream crm_kerberos {
server 10.20.30.101:80;
server 10.20.30.102:80;
# 支持 weight、max_fails、health_check 等任意增强
}
NTLM 是有状态、易受攻击、已被微软标记为“应弃用”的旧协议。强行在 NGINX 上做 NTLM 负载均衡，不是配置技巧问题，而是架构妥协——短期可用，长期隐患多。
不复杂但容易忽略。
