Para bloquear .env e .git no nginx de verdade, negue todo caminho com um trecho que começa com ponto (location ~ /.), negue as extensões de backup e dump, e repita essas regras dentro de qualquer location ^~ do site. O último passo é o que mais falha: o ^~ desliga as regex e reabre a porta.
Qual configuração bloqueia .env, .git e backup juntos?
# dentro do server {}, antes do location / e do location ~ .php$
location ^~ /.well-known/acme-challenge/ {
default_type text/plain;
}
location ~ /. {
deny all;
}
location ~* .(sql|bak|old|orig|swp|tar|tgz|zip|7z|rar)$ {
deny all;
}
location ~* .(sql|tar).gz$ {
deny all;
}
O bloco do ACME vem primeiro para o certbot continuar renovando: prefixo com ^~ vence a regex, então o desafio do Let’s Encrypt passa e qualquer outro caminho com ponto dá 403. Evito o popular location ~ /.(?!well-known), que isenta a árvore /.well-known/ inteira, inclusive um .php que alguém largue ali. Se você publica outro arquivo nessa pasta, como o security.txt, libere o caminho exato com outro ^~.
Por que /uploads/.env passou mesmo com o deny?
A documentação do nginx explica: se o prefixo mais longo que casou tem ^~, as regex nem são testadas. No meu teste, com location ^~ /wp-content/uploads/ { expires 30d; } no server, /.env dava 403 e /wp-content/uploads/.env devolvia o conteúdo com 200. A correção é repetir o deny dentro do bloco, e aí o mesmo pedido passou a dar 403:
location ^~ /wp-content/uploads/ {
location ~ /. { deny all; }
location ~* .(php|phtml|phar)$ { deny all; }
expires 30d;
}
Como testar sem esperar o robô de varredura?
for u in /.env /.git/config /backup.sql /wp-config.php.bak /wp-content/uploads/.env; do
printf '%s %sn' "$(curl -s -o /dev/null -w '%{http_code}' "https://seusite.com.br$u")" "$u"
done
Tudo tem de voltar 403, exista o arquivo ou não. E não ponha access_log off nesses blocos: é esse log que o fail2ban lê para banir quem fica varrendo /.env atrás de senha de banco.