最根本有效的防护是禁止Nginx将系统配置文件作为Web资源提供：需在http或server块中显式屏蔽敏感路径（如location ~ ^/(etc|usr|var/log|proc|sys|root|boot|dev)/ { deny all; }），严格校验root/alias指向、关闭autoindex，并禁用高危模块，重载后验证返回403或404。
直接禁止 Nginx 服务对外暴露系统配置文件，是最根本且有效的防护方式。关键不是“限制访问”，而是“不让它被当作 Web 资源提供”。
禁止匹配敏感路径的 location 块
Nginx 默认不会自动提供 /etc/、/usr/local/nginx/conf/ 等目录下的文件，但若配置了 root 指向系统目录或使用了不安全的 alias，就可能意外暴露。应在主配置（如 nginx.conf）或站点配置中显式屏蔽常见敏感路径：
- 在 http 或 server 块内添加以下 location 规则：
deny all;
}
注意：正则需锚定开头（^/），避免误伤正常路径；也可单独针对 /etc/ 和 Nginx 自身配置目录更精确地写：
location = /nginx.conf { deny all; }location ^~ /etc/ { deny all; }
检查 root 和 alias 的实际指向
很多泄露源于 root 指令错误地指向了系统根目录或上级目录。例如：
root /;或
这类配置会让 Nginx 把请求直接映射到真实文件系统。务必确保：
- root 指向的是专用于 Web 服务的文档根目录（如 /var/www/html）
- 避免在 location 中使用 alias 指向系统敏感路径
- 禁用 autoindex（除非明确需要目录列表），防止目录遍历后看到文件名
关闭不必要的模块与功能
某些模块可能间接导致配置文件可读，比如：
- 禁用 ngx_http_autoindex_module（删除或注释掉 autoindex on;）
- 禁用 ngx_http_perl_module 等高危扩展（编译时剔除或配置中不加载）
- 确保没有启用类似 include /etc/nginx/conf.d/*.conf 的指令出现在可被外部请求解析的上下文中（这本身不暴露文件，但若配合其他漏洞可能被利用）
验证是否仍可访问敏感路径
修改配置后必须重载并测试。例如尝试请求：
curl -I http://your-site/etc/passwdcurl -I http://your-site/nginx.conf
预期返回应为 403 Forbidden 或 404 Not Found，而非 200。也可用工具扫描常见路径（如 /etc/nginx/nginx.conf、/.git/config）确认无响应。
