为何配置拒绝规则后Nginx仍暴露.git目录？

你配置的location ~ /\. { deny all; }未生效，核心原因是Nginx的location匹配优先级规则及配置执行顺序问题，以下是具体分析和解决办法：

核心原因 #

Nginx的location匹配优先级顺序为：

1. 精确匹配（=）
2. 前缀匹配（^~）
3. 正则匹配（~/~*，按配置文件中出现的顺序匹配，第一个命中的生效）
4. 普通前缀匹配

你的配置中，location ~ /\.和location ~ \.php$同属正则匹配，若请求路径同时满足两个规则（比如/.git/xxx.php），Nginx会选择配置文件中后出现的正则location（你把~ \.php$写在了~ /\.之后），直接绕过deny规则。此外，若.git目录下的请求被try_files转发到PHP处理，也会跳过deny限制。

解决方案 #

方案1：使用高优先级前缀匹配（推荐） #

用^~前缀匹配.git目录，优先级高于所有正则匹配，直接拦截所有.git相关请求：

location ^~ /.git/ {
    deny all;
    return 404; # 可选，返回404而非403，隐藏目录存在性
}

将该规则放在所有其他location之前（比如location /和location ~ \.php$之前）。

方案2：调整正则匹配顺序并优化规则 #

将.git相关的正则匹配放在所有其他正则location最前面，确保先命中deny规则：

# 放在所有正则location（如~ \.php$）之前
location ~ /\.(git|svn|hg) {
    deny all;
    access_log off;
    log_not_found off;
}

方案3：验证配置是否正确加载 #

1. 执行nginx -t检查配置文件语法是否正确，排除语法错误
2. 执行nginx -s reload重新加载配置（比restart更稳妥，避免服务中断）

额外检查项 #

• 确认.git目录确实在root /var/sites/.../public_html路径下，若在上级目录，当前server块的规则无法覆盖
• 检查是否有其他include的配置文件或server块覆盖了当前规则
• 确认未开启autoindex on（你的配置中未开启，若开启会导致目录可被遍历）

内容的提问来源于stack exchange，提问作者nwpullman