报错是这么冒出来的。部署时把仓库一起传到了网站根目录，/.git/config 可以直接下载。必应搜索结果里出现站点可能被入侵的提示，自然流量掉了三成。
中间走过弯路，把「备份压缩包也放在可访问的目录里」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。部署脚本整目录同步，把 .git 一起带了上去。还有一种是Nginx 没有对点开头的目录做拒绝规则。
另外，站点没有文件完整性巡检，暴露了半年没人发现。
动手时先确认敏感路径能否下载
curl -s -o /dev/null -w '%{http_code}\n' https://www.lu0.cn/.git/config再往下统一拒绝点开头的目录
location ~ /\.(git|env|svn) { deny all; return 404; }接着把仓库与备份移出站点根目录
mv /var/www/html/.git /opt/repo-backup/提交安全复审请求重新评估
怎么算真的好了，看的是同一批现象。敏感路径全部返回 404，必应的安全提示在复审后消失，自然流量两周内恢复到原有水平。
容易忽略的是，这类暴露往往在上线那天就存在，只是没人去访问，加一条巡检比事后申诉有用得多。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。