Nginx 安全要点：最佳实践与故障排查常见问题

Nginx 安全并非单一设置或某个神奇头部，而是一系列谨慎的默认配置：HTTPS、严格的文件访问、安全的代理行为、有限的暴露范围，以及能帮助你在问题扩大前发现它们的日志。

本常见问题解答涵盖了团队在部署 Nginx 并意识到默认配置只是起点后通常会提出的问题。

首先应审查哪些 Nginx 安全设置？

从减少意外暴露的基础设置开始。这些设置能保护你免受常见错误（而非高级攻击）的影响。

首先，禁用版本令牌：

server_tokens off;

这会阻止 Nginx 在错误页面和头部中显示其版本号。它不会让服务器隐形，但能去除不必要的细节。

其次，确保文档根目录正确。一个常见错误是将 root 指向项目目录而非公共构建目录，这可能导致源代码文件、环境示例或私有资产暴露。

对于静态站点，建议使用：

root /var/www/example.com/public;

而不是：

root /var/www/example.com;

第三，除非你的应用确实需要，否则阻止隐藏文件：

location ~ /\.(?!well-known) {
    deny all;
}

这允许证书验证所需的 .well-known 路径，同时拒绝 .env、.git 和 .htpasswd 等文件。

最后，审查上传限制。如果你的站点不接受大文件上传，请将 client_max_body_size 设置为合理值，以减少意外大请求的影响范围。

Nginx 应如何处理 HTTPS？

对于公共网站和 API，HTTPS 应是默认路径。将纯 HTTP 重定向到 HTTPS，使用有效证书，并避免过时的协议设置。

一个简单的重定向服务器块如下：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

HTTPS 服务器块应引用你的证书文件并包含现代 TLS 设置。许多团队使用 Certbot 或托管负载均衡器来处理证书。关键在于保持续期自动化并监控。

安全头部也能帮助浏览器做出更安全的决策：

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

使用内容安全策略（CSP）时要小心。它功能强大，但严格的策略可能会破坏脚本、字体、分析工具或嵌入内容，如果未经测试就应用。尽可能先从仅报告模式开始。

有关 HTTPS 的实践指南，请参阅使用 HTTPS 保护 Nginx。

如何保护作为反向代理的 Nginx？

当 Nginx 将流量代理到应用时，你需要保留正确的请求信息，同时不能盲目信任客户端输入。

常见的代理头部如下：

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

这些头部帮助上游应用理解原始请求，对日志记录、重定向、速率限制和安全检查非常有用。

如果 Nginx 位于另一个受信任的代理或负载均衡器之后，请谨慎配置真实 IP 处理。只信任已知的代理地址：

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

不要信任来自开放互联网的 X-Forwarded-For 头部。客户端可以伪造该头部。仅当请求来自你的负载均衡器、CDN 或内部代理时才信任它。

你还应隐藏上游实现细节。如果你的应用返回不需要的框架特定头部，请在代理或应用层移除它们。

是否应使用速率限制？

速率限制对登录页面、搜索端点、高成本 API 以及攻击者可以低成本滥用的任何路由非常有用。它不能替代应用安全，但可以减缓暴力破解尝试和嘈杂流量。

示例：

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

这会创建一个以客户端 IP 为键的共享内存区域，并限制对登录路径的请求。具体值取决于你的用户。企业仪表板通常可以容忍比移动网络上的公共消费应用更严格的限制。

仔细测试速率限制。如果你的站点位于代理之后且未配置真实客户端 IP 处理，每个用户可能看起来来自同一地址，从而可能阻止合法流量。

为什么我仍然看到可疑请求？

公共 Nginx 服务器会持续收到背景噪音：扫描旧管理面板、PHP 文件、WordPress 路径和暴露的环境文件。在日志中看到这些请求并不一定意味着你被入侵了。

关键在于你的服务器如何响应。对非 WordPress 站点的 /wp-admin 请求应返回 404 或 403。对 /.env 的请求绝不应返回机密信息。带有奇怪路径的请求不应被代理到内部管理服务。

检查你的访问日志，关注：

重复的 401 或 403 响应
来自同一 IP 的多个请求
大的请求体
探测隐藏文件
异常的用户代理
499、502 或 504 响应的激增

有关更广泛的故障排查，请参阅Nginx 常见错误。

何时寻求安全帮助

当 Nginx 保护客户数据、身份验证、支付流程、私有 API 或内部管理工具时，请引入安全工程师或经验丰富的 DevOps 顾问。在发生疑似入侵、意外文件暴露或影响可用性的重复攻击流量后，你也应寻求帮助。

当配置跨越多个层（如 CDN、负载均衡器、Nginx、服务网格和应用框架）时，专业审查是值得的。一个安全的 Nginx 文件仍可能因其他地方的错误信任边界而被削弱。

通过消除不必要的暴露、强制 HTTPS、谨慎处理代理头部以及监控日志来保护 Nginx。你不需要庞大的配置来变得更安全。你需要清晰的默认设置、经过测试的更改以及检查服务器实际提供内容的习惯。