403错误会暴露路径存在性，应统一返回404或自定义错误页以隐藏敏感路径；需配置return 404、server_tokens off、proxy_hide_header并确保规则优先级正确。
直接返回 403 页面本身并不能隐藏目录结构，反而可能暴露路径存在——攻击者看到 403 Forbidden 就知道这个路径是真实存在的，只是被禁止访问。真正安全的做法是让“不存在的敏感路径”也返回 404，或统一用自定义错误页模糊响应差异。
别让 403 泄露路径存在性
默认情况下，Nginx 对未授权访问（如 /.git、/config/）常返回 403，这等于告诉攻击者：“这个目录有，但你不许进”。更稳妥的方式是：对所有本不该被外部知晓的路径，统一返回 404 或跳转至通用错误页，切断路径探测链。
- 用
return 404;替代deny all;，适用于明确不想暴露的路径，例如：location = /.env { return 404; } - 对整类隐藏路径（如
.git、.svn），推荐正则匹配 + 404：location ~ /\.git|\.svn|\.htaccess { return 404; } - 若必须用 403（如权限控制场景），至少配合自定义错误页，避免默认页中泄露 Nginx 版本、服务器路径等信息
配置统一且无信息泄露的 403 错误页
即使返回 403，也要确保错误页本身不泄漏后端细节。Nginx 默认错误页会显示版本号、系统路径甚至请求 URI，需主动屏蔽：
- 在
http或server块中关闭版本标识：server_tokens off; - 指定自定义错误页，并确保 HTML 文件内容干净（不写
Nginx/1.24.0等字样）：error_page 403 /403.html;location = /403.html { internal; } - 防止错误页被直接访问或索引，加限制：
location ^~ /403.html { deny all; }
配合 location 精确拦截，避免规则被绕过
敏感路径防护效果取决于匹配优先级。普通前缀匹配（location /admin）可能被后续正则覆盖，应优先使用高优先级语法：
- 用
^~处理目录类路径，语义明确且不参与正则竞争：location ^~ /backup/ { return 404; } - 用
=精确匹配单个敏感文件，杜绝歧义：location = /wp-config.php { return 404; } - 所有敏感路径规则应放在
location /和静态资源规则之前，防止被try_files或proxy_pass意外兜底
额外加固：封禁扩展名 + 隐藏响应头
光靠状态码还不够，要从请求入口和响应出口双向过滤：
- 批量禁止敏感后缀访问（不区分大小写）：
location ~* \.(conf|log|bak|yml|env|sh|php)$ { return 404; } - 反向代理场景下，隐藏后端暴露的响应头：
proxy_hide_header X-Powered-By;proxy_hide_header Server; - 确认配置重载生效：
nginx -t && nginx -s reload，再用curl -I https://site/.git验证是否返回 404 且无敏感头
