proxy_pass_request_headers off 是静态开关，无法动态控制；需结合 map、if 或 Lua 实现按来源、路径或内容的请求头透传策略，核心为默认关闭+按需注入+条件重写。

proxy_pass_request_headers off 是静态开关，不能“动态”切断——它一开全关、一关全透。真要实现按来源、路径或内容动态控制请求头透传，得靠组合策略，核心思路是：默认关闭透传 + 按需显式注入 + 条件化重写。

---

用 map 实现基于来源或路径的差异化头控制

Nginx 本身不支持运行时判断再开关 proxy_pass_request_headers，但可以用 map 提前打标，配合 proxy_set_header 精准放行。

例如：只对内网 IP 或特定 API 路径透传 X-Real-IP 和 X-Forwarded-Proto，其余请求清空所有客户端头：

# 在 http 块顶部定义映射
map $remote_addr $trusted_source {
    default          0;
    10.0.0.0/8       1;
    172.16.0.0/12    1;
    192.168.0.0/16   1;
}

map $uri $is_api_path {
    ~^/api/v[0-9]+/  1;
    default          0;
}

server {
    location / {
        # 默认关闭透传
        proxy_pass_request_headers off;

        # 只对可信源或 API 路径，才设置关键头
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Host 强制使用上游地址（安全）
        proxy_set_header Host $proxy_host;

        # 非可信请求：显式清空高风险头（即使 off 了，也防 Lua 等模块注入）
        proxy_set_header Origin "";
        proxy_set_header User-Agent "";
        proxy_set_header Referer "";

        # 条件化补充：仅当 $trusted_source=1 时，才透传 X-Custom-Header（需配合后端约定）
        proxy_set_header X-Custom-Header $http_x_custom_header;

        proxy_pass http://backend;
    }
}

⚠️ 注意：$http_x_custom_header 这类变量在 proxy_pass_request_headers off 下不会自动存在。若需读取，必须先设 proxy_pass_request_headers on，再用 map 或 if 判断后 proxy_set_header 覆盖 —— 但 if 在 location 中受限，推荐用 map + 变量间接控制。

---

用 if + proxy_set_header 动态覆盖（谨慎使用）

虽不推荐在 location 中大量用 if，但在简单场景下可行：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

location /admin/ {
    proxy_pass_request_headers off;

    # 只有带合法 token 的请求，才透传 X-Admin-Token
    if ($http_authorization ~* "^Bearer\s+[a-zA-Z0-9\-\._~\+/]+=*$") {
        proxy_set_header X-Admin-Token $http_authorization;
    }

    # 其他头一律清空
    proxy_set_header Host $proxy_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    proxy_pass http://admin-backend;
}

✅ 有效，但注意：if 内部不能用 proxy_pass，且多个 if 不叠加，建议优先用 map。

---

结合 Lua（OpenResty）做细粒度决策

如果已部署 OpenResty，可用 access_by_lua_block 实时解析、过滤、重写请求头：

location / {
    access_by_lua_block {
        local headers = ngx.req.get_headers()
        -- 只保留白名单头
        local safe_headers = { ["host"] = headers.host, ["content-type"] = headers["content-type"] }
        -- 清空 Origin、User-Agent 等
        ngx.req.clear_header("Origin")
        ngx.req.clear_header("User-Agent")
        ngx.req.clear_header("Referer")
        -- 按业务逻辑加头
        if headers["x-api-key"] and #headers["x-api-key"] > 10 then
            ngx.req.set_header("X-Trusted-Key", headers["x-api-key"])
        end
    }

    proxy_pass_request_headers off;  # 此时客户端头已被 Lua 清理，off 更保险
    proxy_set_header Host $proxy_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://backend;
}

✅ 最灵活，适合风控、灰度、多租户等复杂场景；缺点是增加执行开销，需评估 QPS 承载。

---

关键提醒：别踩这些坑

• proxy_pass_request_headers off 后，$http_* 变量（如 $http_origin）将为空 —— 它们依赖原始头，不是 Nginx 自动提供的。
• Lua 设置的头（如 ngx.req.set_header）不受 proxy_pass_request_headers off 影响，它发生在 Nginx 处理阶段之前。
• proxy_set_header 总是生效，无论 proxy_pass_request_headers 是 on 还是 off；off 只禁客户端原始头，不限制你主动设的头。
• 想彻底阻断某头（比如恶意 X-Forwarded-For），光 off 不够，还得 proxy_set_header X-Forwarded-For $remote_addr 主动覆盖。

不复杂但容易忽略