Nginx加固如何避免误伤业务?

Nginx 加固最容易出问题的地方，不是规则写错，而是把“禁止暴露”误解成“全部拒绝访问”。安全配置应先区分公开资源、业务入口和确实不应通过 Web 暴露的内容，再以小范围、可验证、可回滚的方式实施。首页、登录、后台、上传、静态资源、备份下载、定时任务和证书验证路径，都应纳入变更前后的检查范围。

第一步是确认现状，而不是直接套用规则。重点检查响应头和错误页面是否暴露 Nginx 版本，敏感文件是否能够访问，目录是否出现文件列表。版本隐藏可使用 server_tokens off，但它只减少 Nginx 自身的信息暴露，不能修复漏洞，也不能隐藏应用、PHP、WordPress 或 CDN 的版本信息。关闭目录索引时，应设置 autoindex off，同时确认依赖目录浏览的下载业务是否已有替代方案；robots.txt 不能替代访问控制。

误伤通常来自范围过大的匹配规则。阻断点文件时，应保留 /.well-known/ 等合法验证路径；禁止备份文件时，要核对业务是否确实提供 ZIP、SQL 或其他压缩文件下载。对明确不应公开的目录，优先使用精确的前缀匹配，例如 /private/、/backup/ 和 /internal/。更稳妥的方案是把这些目录移出 Web 根目录，而不是仅依赖 Nginx 拒绝规则。

上传目录尤其需要精细处理。WordPress 的媒体文件通常必须继续访问，因此不能直接封禁整个 wp-content/uploads/；应重点阻止其中的 PHP 文件执行，并验证图片仍能正常返回。后台也不应简单封禁 /wp-admin/，而应结合管理网段、VPN、额外认证和限速等措施逐步收紧。

每次变更前都要备份配置，并确认实际加载位置；修改后先执行 nginx -t，再 reload，不要在检查失败时强行加载。随后使用 nginx -T 查看最终配置，逐项验证公开资源、受保护路径、错误页面和日志。登录、上传、媒体预览、定时任务、健康检查及证书续期均正常，才说明加固没有破坏业务。若出现异常，应按原配置管理流程回滚，而不是临时叠加更多规则。