关键不是加密或混淆URL，而是拦截、过滤、重写和隔离敏感参数，避免其出现在路径、响应头、日志或错误信息中；通过map预处理$args、proxy_set_header注入可信值、proxy_hide_header屏蔽敏感头、server_tokens off及权限管控实现源头防护。
直接在 Nginx 配置中“隐藏”敏感参数（如密码、密钥、token）的关键，不是靠加密或混淆 URL，而是避免让它们出现在客户端可见的路径、响应头、日志或错误信息中。Nginx 本身不存储或管理应用层密钥，它的作用是拦截、过滤、重写和隔离——把敏感值挡在用户视线之外，同时确保后端服务仍能安全获取。
禁止敏感参数出现在 URL 和日志中
Nginx 默认会把完整请求行（含 query string）记入 access_log，如果请求带 ?api_key=xxx 或 ?token=abc123，这些就会明文落盘。应主动剥离或屏蔽：
- 用
log_format自定义日志格式，配合$args的条件截断（较难精准），更稳妥的是用map模块预处理 - 推荐方式：在
http块中定义 map，将含敏感键名的 query string 替换为空或占位符 - 示例：
map $args $safe_args { default $args; ~*(?:^|&)(api_key|secret|token|password)=([^&]*)(&?.*) "-"; }
再在 log_format 中使用$safe_args替代原始$args - 也可用
rewrite在location内清除参数（如rewrite ^(.*)$ $1? break;），但需确保后端不依赖这些参数
禁止敏感值透传到后端或返回给客户端
若后端服务需使用某些凭证（如内部调用 token），不应由前端传入，而应在 Nginx 层注入；反之，后端返回的敏感字段（如 X-Api-Key 响应头）必须被移除：
- 用
proxy_set_header注入可信值，例如：proxy_set_header X-Internal-Token "s3cr3t-456";
这样后端拿到的是 Nginx 提供的凭证，而非用户提交的 - 用
proxy_hide_header屏蔽后端返回的敏感响应头：proxy_hide_header X-Internal-Token;proxy_hide_header Set-Cookie;（如需禁用特定 cookie） - 若需修改响应体（如过滤 JSON 中的
"secret": "xxx"），Nginx 原生不支持，需搭配ngx_http_sub_module（简单替换）或 OpenResty + Lua（精准 JSON 处理）
防止敏感配置泄露在错误页面与响应中
开启 server_tokens off; 只是基础，还需杜绝因配置错误导致的泄露：
- 关闭
error_page 404 /404.html类自定义页时的路径回显（默认 Nginx 不暴露路径，但若用try_files错误配置可能暴露） - 禁用
fastcgi_intercept_errors或proxy_intercept_errors的反向代理错误透传，统一用 Nginx 自定义错误页，避免后端堆栈、配置路径等泄漏 - 检查所有
include的配置文件权限：确保/etc/nginx/conf.d/*.secret等含密钥的文件，仅 root 可读（chmod 600），且不在 web root 下可访问
用变量与环境隔离提升安全性
Nginx 本身不支持环境变量注入（除非用 OpenResty 或 systemd 启动时传递），但可通过间接方式解耦：
- 在启动前用脚本生成配置片段（如
nginx-secret.conf），内容为set $upstream_token "xxx";，再include进主配置，该文件设为仅 root 访问 - 使用
auth_request模块将鉴权逻辑下沉到独立认证服务，Nginx 只负责转发和拦截，不接触任何密钥 - 对静态资源（如 JS/CSS）启用
sub_filter动态抹除 HTML 中硬编码的敏感值（不推荐长期使用，应从前端构建阶段解决）
