这类问题我又碰上了一次。迁移时把一个 180MB 的数据库备份放在网站根目录，两周后 site 查询能直接搜到 backup_20261001.sql，点开就是全站的用户表和评论。
第一反应是「站点没有禁止目录列表，文件名能被猜出来」，验证下来不成立。
排查方向其实有限，先把可能性排一排。备份文件放在了 web 可访问目录，Nginx 按静态文件直出；扩展名是 .sql，默认 MIME 不对，浏览器直接下载但蜘蛛照样收；robots 里没有针对备份命名规则的兜底规则。
先确认这个地址现在还能不能下载
curl -sI https://www.example.com/backup_20261001.sql | head -3然后把备份目录整体移出网站根目录
mv /www/wwwroot/lu0.cn/backup /data/backup接着用 Nginx 规则拦掉常见备份后缀
location ~* \.(sql|bak|zip|tar\.gz)$ { deny all; }剩下的就是验证返回 403 而不是文件流
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/backup_20261001.sql改完先别撤，确认这几项。该地址返回 403 且响应体为空，site 查询里的这条记录在两三周内消失，日志中对 .sql 的请求全部变成 403。
文件被收录过就等于泄露过，删文件只能止血，备份里的数据要当作已外泄处理，密码和密钥该换就换。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。