Nginx通过auth_request指令将请求转发至内部/auth位置块进行LDAP认证，/auth必须声明internal防止外部直接访问；认证成功返回200并可透传用户信息，失败则拦截；后端负责LDAP校验，Nginx仅处理状态码与缓存。
核心是用 auth_request 指令把请求“转发”给一个内部认证服务，由它对接 LDAP 并返回 200（放行）或非 200（拒绝），Nginx 根据这个结果决定是否继续处理原始请求。
必须加 internal 的 /auth 位置块
这是安全前提。外部用户不能直接访问认证接口，否则等于绕过鉴权。
- 用
location = /auth { internal; ... }精确匹配并声明为内部地址 -
internal指令会拦截所有来自浏览器、curl 等的直接请求，只允许 Nginx 自身发起的子请求（比如auth_request触发的）通过 - 若漏掉
internal，攻击者可构造GET /auth?user=test&pwd=123尝试爆破或探测，风险极高
在目标接口 location 中启用 auth_request
告诉 Nginx：每次有请求打到这个路径，先去 /auth 过一遍。
- 例如保护所有 API：
location /api/ { auth_request /auth; proxy_pass http://backend; } - 可配合
auth_request_set提取认证服务返回的头信息，比如用户名：auth_request_set $user $upstream_http_x-auth-user; - 提取后就能透传到后端：
proxy_set_header X-User $user;，方便业务侧做二次校验或审计
后端认证服务需完成 LDAP 校验逻辑
Nginx 不直连 LDAP，它只负责转发和判断状态码。真正的账号密码比对、DN 查询、组权限检查等，都由你写的 /auth 后端完成。
- 后端收到子请求时，通常能拿到原始请求的
Authorization头（如 Basic 或 Bearer）、Cookie 或自定义 token - 后端解析凭证，用标准 LDAP 客户端（如 Python 的
ldap3、Java 的spring-ldap）连接 LDAP 服务器（AD 或 OpenLDAP）进行 bind 或 search+compare - 验证通过则返回 HTTP 200，并可附带自定义响应头（如
X-Auth-User: alice、X-Auth-Groups: dev,admin）供 Nginx 提取 - 失败则返回 401 或 403，Nginx 自动拦截原请求，不转发给业务后端
缓存与超时建议
避免每次请求都查 LDAP，影响性能；也要防止缓存太久导致权限变更延迟生效。
- 在
/auth的location块中配置缓存：proxy_cache ldap_auth_cache;，并定义 cache zone - 设置合理缓存时间：
proxy_cache_valid 200 5m;（成功结果缓存 5 分钟） - 设好超时：
proxy_read_timeout 10;、proxy_connect_timeout 3;，防止单点 LDAP 故障拖垮整个网关 - 缓存 key 建议包含关键变量，例如：
proxy_cache_key "$http_authorization$cookie_sessionid";
