在 Nginx 中禁止访问以点开头的隐藏文件,需在 server 块顶层添加 location ~ /. { return 403; },并可补充 location ~ /.(git|hg|svn|env|env.local|htaccess|htpasswd)($|/) { return 403; } 以增强防护,配置后须 reload 并用 curl 验证返回 403。
在 Nginx 中禁止访问以点开头的隐藏文件(如 .git、.env、.htaccess 等),核心是利用 location 块匹配以 . 开头的路径,并统一返回 403 或 404。这是生产环境必备的安全加固措施。
最常用也最稳妥的方式,是在 server 块或 location 上级上下文中添加以下配置:
. 开头的 URI 路径(包括 /.git、/.env、/api/.config 等)return 403 明确拒绝访问,避免暴露文件是否存在(比 404 更安全)示例配置:
location ~ /. {deny all;# 或等价写法:return 403;}
注意:~ . 是正则匹配,. 匹配字面量点号;deny all 在非 auth 模块下等效于 return 403,语义清晰且兼容性好。
仅靠 /. 可覆盖大部分情况,但某些部署可能把 .env 放在根目录外(如 /app/.env),而正则 /. 仍能匹配;不过为防漏网之鱼,可额外显式屏蔽高频敏感文件:
.git 目录及其子路径(含 /.git/config、/.git/HEAD).env、.env.local 等环境配置文件.htaccess、.svn、.hg 等版本/权限控制文件推荐补丁式配置(放在同一 server 块中):
location ~ /.(git|hg|svn|env|env.local|htaccess|htpasswd)($|/) {return 403;}
该规则优先级高于通用 /.,更精准,且支持扩展(如后续加 |dockerignore)。
这类访问控制必须放在能覆盖所有请求的位置,常见错误是只写在某个 location / 内部,导致被嵌套覆盖:
server { ... } 块顶层(即所有 location 外层)location /api { ... } 里,无法拦截 /.env
try_files 或 PHP fastcgi_pass,需确认未因 rewrite 或内部跳转绕过此规则配置后务必测试,方法简单直接:
nginx -t && systemctl reload nginx
curl -I http://yoursite/.env,应返回 HTTP/1.1 403 Forbidden
Content-Length: 0 以外的正文)不复杂但容易忽略。