Nginx不直连LDAP，而是通过auth_request模块将认证委托给独立的nginx-ldap-auth-daemon.py守护进程，该进程负责TLS连接、LDAP bind验证并返回HTTP状态码，Nginx则承担请求拦截、结果缓存、负载分发及高可用调度。
要让 Nginx 代理 LDAP 服务并支撑企业级身份验证的高可用负载，关键不是简单转发 LDAP 流量（LDAP 协议本身不适用于 HTTP 反向代理），而是用 Nginx 作为认证网关，把用户访问 Web 应用的请求统一交由后端 LDAP 服务校验——即“Nginx + LDAP 认证守护进程”架构。这种模式既保留 LDAP 的集中管理能力，又借力 Nginx 的高性能、健康检查与负载分发能力。
明确角色分工：Nginx 不直连 LDAP，而是调度认证请求
Nginx 本身不原生支持 LDAP bind 操作。它通过 auth_request 模块将认证逻辑委托给一个独立的认证服务（如 nginx-ldap-auth-daemon.py）。这个守护进程才是真正连接 OpenLDAP 或 Active Directory 的组件。
- Nginx 负责：接收用户 HTTP 请求、拦截未认证访问、转发认证请求到守护进程、缓存结果、控制访问流
- 认证守护进程负责：解析用户名密码、建立 TLS/SSL 连接、执行 LDAP bind 和搜索、返回 200（成功）或 401/403（失败）
- LDAP 服务器负责：凭证存储、组织结构查询、组成员判定、密码策略执行
高可用 LDAP 后端：双活镜像 + 健康探测
为避免单点故障，LDAP 层必须部署多实例，并确保 Nginx 能自动识别和切换。
- OpenLDAP 使用
mirrorMode配置双主复制，两台服务器均可读写，实时同步数据 - 在 Nginx 中定义 upstream 时启用主动健康检查：
health_check interval=3 fails=2 passes=2 - 配合 Keepalived 设置虚拟 IP（VIP），当主节点宕机时 VIP 自动漂移到备用节点，对上层无感
- 守护进程中配置多个 LDAP URL（如逗号分隔），或使用 DNS 轮询实现客户端侧容错
Nginx 认证层的负载与缓存优化
认证请求虽轻量，但高频调用下仍需合理分流与缓存，否则会成为性能瓶颈。
- 用
proxy_cache缓存认证结果（例如成功响应缓存 5 分钟，失败响应缓存 30 秒），大幅降低 LDAP 查询压力 - 为不同业务路径设置独立的
auth_request上游，避免共用同一守护进程实例导致相互影响 - 守护进程建议以 systemd 多实例方式部署（如
nginx-ldap-auth@1.service、@2.service），Nginx upstream 指向多个本地端口，实现横向扩展 - 限制单个守护进程并发连接数（如
--max-connections=200），防止单实例过载拖垮整条链路
安全加固要点：从传输到权限逐层设防
认证通道是攻击者重点突破面，必须端到端加密与最小权限控制。
- 强制使用 LDAPS（端口 636）或 STARTTLS，禁用明文 LDAP；Nginx 守护进程配置
ssl_check_cert on并指定可信 CA 证书 - LDAP Bind DN 使用专用只读账号（如
cn=auth-reader,dc=example,dc=com），禁止使用管理员账号 - 在 OpenLDAP 侧配置 ACL，限制该账号仅能读取
uid、cn、memberOf等必要属性 - Nginx 服务器防火墙（iptables/nftables）仅放行到 LDAP 服务器的 636 端口，源地址限定为 Nginx 所在网段
