Web根目录最小化的防护价值

Web 根目录最小化的核心价值，不是“把目录藏起来”，而是缩小 HTTP 入口与文件系统之间的映射范围：只把必须公开的首页、CSS、JavaScript、图片和媒体文件放入可访问目录，源码、配置、备份、数据库导出文件及内部数据则移出 Web 根目录。这样即使 Nginx 规则出现遗漏，攻击者也更难通过 URL 直接取得敏感文件。

为什么最小化比单条拦截规则更可靠

版本号泄露、目录索引和敏感路径暴露通常不会单独造成入侵，却会降低侦察成本。若 Web 根目录中存在 .git、.env、config.php.bak、database.sql、backup.zip 或内部目录，攻击者可能通过猜测路径、错误页面或目录列表确认技术结构，并进一步获得源码、凭据或备份数据。

Nginx 的 deny all、autoindex off 和 server_tokens off 仍然有价值，但它们属于入口收敛措施，而不是文件系统隔离。规则可能因站点配置继承、正则匹配顺序、CDN 或上游应用行为而失效；而不需要通过 HTTP 访问的文件，根本不应位于 Web 根目录。对于明确禁止公开的 /private/、/backup/、/internal/，优先移出站点目录，再辅以精确的路径限制。

最小化也不等于粗暴封禁。公开上传目录中的图片仍需正常访问，但应阻止其中的 PHP 文件被执行；.well-known/ 可能承担证书验证等合法用途，不能被通用隐藏文件规则误伤。依赖目录索引提供下载的业务，则应改为由应用生成文件列表，并增加认证、授权或过期控制。

改造后的验收重点

变更前应备份 Nginx 配置，并确认配置是否由自动化系统、容器或面板管理。修改后先执行 nginx -t，再使用 reload，随后检查首页、登录、后台、静态资源、上传、备份路径和定时任务相关路径。对明确禁止访问的资源，不能只看 403 或 404，还要确认响应体没有泄露内容。

最后，应同时检查外部入口、源站入口、错误页面和访问日志。若仍能看到 Nginx 具体版本、目录文件清单，或上传目录中的脚本被触发，说明整改尚未完成。Web 根目录最小化降低的是暴露面和配置失误的后果，不能替代补丁更新、依赖升级、备份保护与持续审计。