NGINX不原生支持NTLM协议，无法解析或中继NTLM挑战-响应流程；所谓“支持”实为通过ip_hash、keepalive、HTTP/1.1长连接等配置强制会话粘性，使三次握手落在同一后端，属妥协方案。
NGINX 本身不内置“NTLM 模块”，它原生不支持 NTLM 协议的会话保持与转发。但可通过启用 HTTP/1.1 连接复用 + keepalive + ip_hash 等组合方式，让 NTLM 认证在反向代理场景下“勉强可用”。真正稳定支持 NTLM 的负载均衡，需依赖 Windows 原生方案（如 NLB）或改用 Kerberos（推荐）。
为什么 upstream 不能直接“配置 NTLM 模块”
NTLM 是一种有状态的挑战-响应协议，要求客户端与同一后端服务器完成三次握手（NEGOTIATE → CHALLENGE → AUTHENTICATE）。而标准的 NGINX 反向代理默认使用短连接、无状态转发，会把同一用户的三次请求打散到不同后端，导致认证失败。
所以不存在“开启 NTLM 模块”的配置项——NGINX 官方从未提供 NTLM 解析或中继能力。所谓“支持 NTLM”，本质是通过连接控制策略，让三次握手落在同一台服务器上。
upstream 中实现 NTLM 兼容的关键配置
以下配置适用于 Microsoft Dynamics 365 CRM、SharePoint 或其他依赖 NTLM 的 IIS 应用：
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
- 必须启用 ip_hash：确保同一客户端 IP 始终路由到固定后端（简单但有局限，如多用户共用出口 IP 时会冲突）
- 必须设置 keepalive（如 keepalive 60）：维持长连接池，避免每次请求重建连接，减少 NTLM 握手中断风险
-
禁用 connection 头重写：在 location 中显式设置
proxy_http_version 1.1;和proxy_set_header Connection "";，防止代理切断 HTTP/1.1 持久连接 - 避免使用 weight、least_conn 等动态算法：它们会破坏 NTLM 所需的请求顺序与粘性
示例 upstream 片段：
upstream crm_ntlm {ip_hash;
server 10.1.5.9:80 max_fails=2 fail_timeout=2;
server 10.1.5.10:80 max_fails=2 fail_timeout=2;
keepalive 60;
}
更可靠的做法：绕过 NTLM，改用 Kerberos
NTLM 不仅难负载均衡，还存在重放攻击、无服务端验证等严重安全缺陷。微软明确建议禁用 NTLM，全面转向 Kerberos：
- 在 IIS 后端启用 Windows 身份验证，并强制协商使用 Kerberos（通过 SPN 正确注册 + 客户端组策略设置）
- Kerberos 支持无状态验证：票据由域控签发，NGINX 只需透传 Authorization 头，无需保持连接或绑定后端
- 此时可自由使用轮询、加权、健康检查等任意 upstream 策略，完全不受协议限制
若必须保留 NTLM（如老旧系统无法改造），应优先考虑 Windows 自带的 NLB（Network Load Balancing） 或 Windows Server 的 SLB（软件负载均衡器），它们内建对 NTLM 流量的感知与会话保持能力。
补充提醒：生产环境务必审计 NTLM 使用情况
在域控上启用组策略稽核（如“限制 NTLM：稽核传入流量”），确认哪些服务仍在用 NTLM。一旦发现非必要使用，应推动升级或替换。封禁 NTLM 并非一步到位，但长期目标必须是彻底淘汰——这不是兼容性问题，而是基础安全要求。
