1. 项目概述为什么Nginx安全配置不能只靠“默认”如果你用过Nginx大概率会觉得它挺“乖”的下载、安装、启动一个简单的配置文件就能让网站跑起来。很多新手甚至一些有经验的运维可能就止步于此了觉得默认配置“够用”。但现实是一个未经加固的Nginx就像一个没锁门还开着窗的家攻击者可以轻易地“登堂入室”进行信息刺探、资源盗用甚至直接入侵后端服务。“Nginx安全配置大白话总结”这个项目就是想把这些看似复杂的安全加固点用最直白的语言和可落地的操作讲清楚。它不是一份面面俱到的安全白皮书而是一个从实战出发的、针对Nginx这个具体组件的“安全自查与加固清单”。无论你是个人站点的站长还是企业应用的运维这份总结都能帮你快速排查风险堵上那些最常见、也最容易被忽略的安全漏洞。安全从来不是一劳永逸的但通过一些基础的、有效的配置我们能极大地提高攻击门槛把绝大多数自动化扫描和低水平攻击挡在门外。2. 核心安全思路从“对外展示”到“最小权限”在动手改配置之前我们先得理清思路。Nginx的安全配置核心思想就两条隐藏自己和守住边界。隐藏自己就是尽可能少地向外界暴露信息。你用的Nginx是什么版本跑在什么操作系统上后端是什么语言这些信息对普通访客毫无用处但对攻击者却是宝贵的“情报”。他们可以根据版本信息查找已知漏洞发起精准攻击。所以我们的第一个目标就是“抹去”这些不必要的指纹。守住边界就是严格遵循“最小权限原则”。Nginx作为反向代理或Web服务器它不应该知道不该知道的信息也不应该执行超出其职责的操作。这意味着限制它能访问的文件路径、限制它能执行的系统操作、限制客户端能发起的请求类型和大小。把Nginx的活动范围框死在一个安全的“沙箱”里。基于这两条思路我们的配置工作就可以有条不紊地展开了。下面我将从信息隐藏、访问控制、请求过滤、SSL/TLS强化、文件安全等多个维度逐一拆解具体的配置项和背后的原理。2.1 信息隐藏让Nginx成为“隐形战士”攻击的第一步往往是信息收集。一个配置不当的Nginx会主动“报上家门”。2.1.1 关闭Server Tokens这是最基本也最有效的一步。默认情况下Nginx会在HTTP响应头Server头和错误页面中详细展示版本号甚至操作系统信息。http { # 在http上下文中关闭server_tokens server_tokens off; }这行配置会让Nginx在Server响应头中只显示“nginx”而不会显示类似“nginx/1.18.0 (Ubuntu)”这样的详细信息。错误页面如404、500中的版本信息也会被隐藏。注意仅仅关闭server_tokens有时还不够。一些基于模块的漏洞扫描器可能会通过其他方式探测。但它能过滤掉绝大部分的自动化信息收集脚本是性价比极高的安全措施。2.1.2 自定义错误页面即使关闭了server_tokensNginx默认的错误页面样式也可能带有特征。更好的做法是使用统一的、自定义的错误页面。server { error_page 404 /custom_404.html; error_page 500 502 503 504 /custom_50x.html; location /custom_404.html { root /usr/share/nginx/html; internal; # 关键标记为内部位置禁止直接外部访问 } location /custom_50x.html { root /usr/share/nginx/html; internal; } }这里有两个关键点一是将错误页面统一到简洁的HTML文件二是使用internal指令确保这些错误页面只能由Nginx在触发错误时内部重定向访问而不能通过https://yoursite.com/custom_404.html这样的URL直接访问防止暴露文件路径信息。2.2 访问控制给大门加上“门禁”和“监控”控制谁能访问以及能访问什么是安全的核心。2.2.1 限制HTTP请求方法通常一个Web站点只需要GET和POST方法。像PUT、DELETE、TRACE、OPTIONS等方法如果业务用不到就应该直接拒绝因为它们可能被用于攻击探测或利用。location / { # 只允许 GET, POST, HEAD 方法 if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; # 返回 405 Method Not Allowed } # ... 其他配置 }实操心得使用if指令时要格外小心在location上下文中if存在一些众所周知的“坑”。上述用法在判断请求方法时是相对安全的。更严谨的做法是对于需要复杂条件判断的访问控制可以考虑结合map指令或使用防火墙如iptables, firewalld在更底层进行过滤。2.2.2 配置安全的响应头HTTP响应头是浏览器与服务器之间的“安全契约”正确配置能有效防御多种前端攻击。server { add_header X-Frame-Options SAMEORIGIN always; add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy strict-origin-when-cross-origin always; # 注意Content-Security-Policy需要根据站点内容仔细配置此处为示例 add_header Content-Security-Policy default-src self; script-src self unsafe-inline https://trusted.cdn.com; always; }X-Frame-Options: SAMEORIGIN防止你的网站被嵌套在别人的iframe里进行点击劫持攻击。X-Content-Type-Options: nosniff阻止浏览器对响应内容进行MIME类型嗅探强制其遵守Content-Type头可防御某些类型的MIME混淆攻击。Referrer-Policy控制Referrer信息的发送减少敏感信息从URL中泄露。Content-Security-Policy (CSP)这是一个强大的“白名单”机制可以精细控制页面能加载哪些来源的资源JS、CSS、图片等。配置CSP需要根据站点实际使用的资源进行调整初始配置可能会阻断正常功能建议在测试环境充分验证。2.2.3 基础认证与IP白名单对于管理后台、API接口等敏感路径需要更严格的访问控制。IP白名单更推荐只允许受信任的IP访问。location /admin/ { allow 192.168.1.0/24; # 允许内网网段 allow 203.0.113.5; # 允许某个特定公网IP deny all; # 拒绝所有其他IP # ... 代理到后端应用的配置 }基础认证Basic Authentication需要用户名密码。location /private/ { auth_basic Restricted Area; auth_basic_user_file /etc/nginx/.htpasswd; # 密码文件路径 # ... 其他配置 }密码文件可以使用htpasswd工具Apache工具Nginx通用创建htpasswd -c /etc/nginx/.htpasswd username。切记基础认证的密码在网络中以Base64编码传输近乎明文必须在HTTPS环境下使用。2.3 请求过滤与限制设置“流量安检仪”恶意请求往往伴随着异常的参数、过大的体积或过高的频率。2.3.1 限制客户端请求体大小防止攻击者通过上传超大文件如巨大的JSON、XML来耗尽服务器资源DoS攻击的一种。http { client_max_body_size 10m; # 全局限制为10MB } server { # 可以为特定location设置更严格的限制 location /upload/ { client_max_body_size 2m; # ... } }2.3.2 限制请求速率防止暴力破解如登录接口或CC攻击。http { # 定义一个名为“login_limit”的共享内存区大小10m每秒请求数限制为5 limit_req_zone $binary_remote_addr zonelogin_limit:10m rate5r/s; } server { location /api/login { # 应用限流突发队列设置为10个请求 limit_req zonelogin_limit burst10 nodelay; # ... 代理到后端的配置 } }limit_req_zone定义限流规则。$binary_remote_addr以客户端IP作为键zone定义共享内存区名称和大小rate是速率限制。limit_req在location中应用规则。burst允许一定数量的突发请求排队nodelay意味着超过burst的请求会立即被拒绝返回503而不是延迟处理。2.3.3 过滤非法User-Agent和Referer虽然可以被伪造但过滤一些明显的恶意扫描器或爬虫的User-Agent和Referer可以减轻服务器压力。# 在http或server块中使用map定义黑名单示例 map $http_user_agent $bad_bot { default 0; ~*(python|curl|wget|scan|bot|crawler|spider) 1; # 示例需谨慎可能误伤 } server { if ($bad_bot) { return 403; } # 或者针对特定路径的盗链进行Referer过滤 location ~* \.(jpg|jpeg|png|gif)$ { valid_referers none blocked server_names *.yourdomain.com; if ($invalid_referer) { return 403; } } }踩坑提醒User-Agent过滤是一把双刃剑。上面的正则示例非常粗糙很可能把正常的搜索引擎爬虫如Googlebot或使用python/curl的合法用户也屏蔽掉。在生产环境中使用前必须结合日志分析精确地定义黑名单否则可能影响业务。2.4 SSL/TLS强化为通信通道加上“防弹玻璃”如果使用HTTPSSSL/TLS的配置至关重要。一个弱的SSL配置会让加密形同虚设。2.4.1 禁用不安全的协议和加密套件SSLv2、SSLv3以及TLS 1.0、TLS 1.1已被证实存在严重漏洞必须禁用。优先使用现代、强壮的加密套件。server { listen 443 ssl http2; # 推荐启用HTTP/2 ssl_protocols TLSv1.2 TLSv1.3; # 只允许 TLS 1.2 和 1.3 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:!aNULL:!MD5:!RC4:!DHE; ssl_prefer_server_ciphers on; # ... 证书路径等配置 }ssl_protocols明确指定允许的协议版本。ssl_ciphers定义加密套件优先级列表。上面的示例是一个相对安全的配置优先使用前向保密Forward Secrecy的ECDHE套件并禁用已知不安全的算法如RC4, MD5, aNULL。ssl_prefer_server_ciphers on让服务器端的套件优先级高于客户端确保使用我们配置的更安全的套件。2.4.2 启用HSTS (HTTP Strict Transport Security)强制浏览器在未来一段时间内始终使用HTTPS访问该站点防止SSL剥离攻击。add_header Strict-Transport-Security max-age31536000; includeSubDomains; preload always;max-age31536000有效期1年。includeSubDomains此策略适用于所有子域名。preload这是一个提交到浏览器预加载列表的指令需要到 hstspreload.org 提交申请。一旦启用并预加载很难回退请确保你的所有子域名都永久支持HTTPS后再使用。2.5 文件与路径安全锁死“后门”与“资源库”Nginx对文件系统的访问权限必须受到严格控制。2.5.1 禁用不需要的HTTP模块在编译安装Nginx时只启用你需要的模块。例如如果不需要自动索引功能就不要安装ngx_http_autoindex_module。对于已安装的模块在配置中也要禁用其功能。# 在location中禁用autoindex location /some-path/ { autoindex off; }2.5.2 严格控制文件访问和目录列表确保Nginx进程用户如www-data,nginx对web根目录只有必要的读权限对上传目录通常只有写权限而无执行权限。server { root /var/www/html; # 全局禁止访问隐藏文件以点开头 location ~ /\. { deny all; access_log off; log_not_found off; } # 禁止访问特定敏感文件 location ~* ^/(\.git|\.env|config\.ini|composer\.lock|yarn\.lock|package-lock\.json) { deny all; access_log off; log_not_found off; } # 上传目录禁止执行PHP等脚本 location ~* ^/uploads/.*\.(php|php5|sh|pl|py)$ { deny all; } }2.5.3 使用安全的文件描述符和连接处理在http块进行全局优化提升性能和抗压能力。http { # 限制每个worker进程能打开的文件描述符数量与系统ulimit匹配 worker_rlimit_nofile 65535; # 优化连接处理 client_header_timeout 10s; client_body_timeout 10s; send_timeout 10s; keepalive_timeout 65s; # 限制连接数防御简单的连接耗尽攻击 limit_conn_zone $binary_remote_addr zoneaddr:10m; limit_conn addr 100; # 每个IP同时最多100个连接 }3. 完整配置示例与分段解析下面是一个整合了上述多项安全措施的虚拟主机配置示例我们分段进行解析。# 第一部分全局安全与优化基础 user nginx; # 使用专用的低权限用户运行worker进程 worker_processes auto; # 自动根据CPU核心数设置 worker_rlimit_nofile 65535; # 提高worker进程文件描述符限制 events { worker_connections 4096; # 每个worker进程的最大连接数 use epoll; # Linux下高性能事件模型 multi_accept on; } http { # 基础隐藏与限制 server_tokens off; # 隐藏Nginx版本 client_max_body_size 10m; # 全局请求体大小限制 limit_conn_zone $binary_remote_addr zoneperip:10m; # 连接数限制区 limit_conn perip 100; # SSL通用配置如果多个server共用 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # 安全响应头可被server块覆盖 add_header X-Frame-Options SAMEORIGIN always; add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy strict-origin-when-cross-origin always; # 日志格式包含安全相关字段 log_format security $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; # 第二部分具体的Server块配置 server { listen 80; server_name yourdomain.com www.yourdomain.com; # 强制跳转到HTTPS return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name yourdomain.com www.yourdomain.com; # SSL证书路径 ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # 启用HSTS谨慎使用includeSubDomains和preload add_header Strict-Transport-Security max-age31536000 always; root /var/www/yourdomain.com/public; index index.html index.htm; # 全局安全规则禁止访问隐藏文件和特定敏感文件 location ~ /\. { deny all; access_log off; log_not_found off; } location ~* ^/(\.git|\.env|\.htaccess|\.htpasswd) { deny all; access_log off; log_not_found off; } # 静态资源服务并设置缓存和安全头 location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ { expires 1y; add_header Cache-Control public, immutable; # 可选的防盗链 # valid_referers none blocked server_names *.yourdomain.com; # if ($invalid_referer) { return 403; } } # 主应用入口假设是反向代理到后端应用如Node.js, Python等 location / { # 限制请求方法 if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; } # 应用连接数限制 limit_conn perip 20; # 代理配置 proxy_pass http://backend_app_upstream; 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; } # 敏感的管理后台路径使用IP白名单 location /admin/ { allow 192.168.1.0/24; # 内网IP段 allow 203.0.113.100; # 特定管理IP deny all; # 同样代理到后端 proxy_pass http://backend_app_upstream; # ... 其他proxy_set_header } # 登录API接口应用请求速率限制 location /api/v1/login { limit_req_zone $binary_remote_addr zonelogin_api:10m rate2r/s; limit_req zonelogin_api burst5 nodelay; proxy_pass http://backend_app_upstream; # ... } # 上传目录禁止脚本执行 location ^~ /uploads/ { # 取消所有PHP等脚本的执行权限 location ~ \.(php|pl|py|jsp|asp|sh|cgi)$ { deny all; return 403; } # 允许上传和访问文件 try_files $uri 404; } # 自定义错误页面 error_page 404 /error/404.html; error_page 500 502 503 504 /error/50x.html; location ^~ /error/ { internal; # 关键内部访问 root /var/www/yourdomain.com/static; } # 访问日志使用安全格式和错误日志 access_log /var/log/nginx/yourdomain_access.log security; error_log /var/log/nginx/yourdomain_error.log warn; } }配置解析要点分层配置将通用的安全设置如server_tokens, 安全响应头, SSL基础参数放在http块将站点特定的配置放在server块。强制HTTPS通过一个独立的server块监听80端口并301重定向到443端口这是现代网站的标配。精细化location控制这是安全配置的灵魂。通过不同的location规则我们对静态资源、API接口、管理后台、上传目录等施加了截然不同的安全策略实现了“最小权限”。内部位置internal用于错误页面防止直接访问。日志记录使用自定义的security日志格式记录了客户端IP、请求方法、状态码、User-Agent等信息这对于事后安全审计和攻击分析至关重要。4. 配置检查、测试与持续维护配置写完了直接上线是危险的。必须经过严格的检查和测试。4.1 配置文件语法检查每次修改配置后第一件事就是检查语法。sudo nginx -t这个命令会测试配置文件的语法并检查文件路径是否正确。如果显示“syntax is ok”和“test is successful”才能进行下一步。4.2 使用安全扫描工具测试手动检查难免疏漏可以利用一些自动化工具进行扫描。SSL/TLS测试使用 SSL Labs SSL Test 网站输入你的域名它会给出详细的评分和安全建议比如协议支持、加密套件强度、证书有效性等。目标是拿到A或A评级。安全响应头测试使用浏览器开发者工具Network标签页查看响应头或者使用在线工具如 SecurityHeaders.com 扫描检查X-Frame-Options、CSP、HSTS等头是否正确设置。漏洞扫描谨慎使用可以使用nikto、nmap等工具对本地测试环境进行扫描查看是否有明显的目录遍历、默认文件泄露等问题。切勿未经授权扫描他人服务器。4.3 灰度发布与监控灰度发布将新的安全配置先应用到一小部分流量如某个测试子域名或非核心业务服务器上观察一段时间确保没有阻断正常业务。监控日志上线后密切监控Nginx的错误日志error_log和访问日志。特别关注403、404、499、500等错误码的突然增多这可能是安全规则过于严格导致的误拦截。建立基线记录正常业务流量下的请求模式、频率等便于在遭受攻击时进行对比识别。4.4 常见问题排查实录即使经过测试在生产环境仍可能遇到问题。以下是一些常见场景问题网站部分功能如上传、AJAX请求突然失效。排查首先查看Nginx错误日志。很可能触发了client_max_body_size限制返回413错误或请求方法限制返回405错误。检查对应location的配置。解决调整client_max_body_size大小或检查前端发起的请求方法是否正确。问题管理后台自己也无法访问了。排查检查IP白名单配置。你的公网IP可能发生了变化或者你正在通过移动网络IP不同访问。解决临时将当前IP加入白名单或考虑结合VPN、跳板机确保管理流量来自固定IP段。问题启用CSP后网站样式错乱JS不执行。排查这是配置CSP时最常见的问题。打开浏览器控制台Console你会看到具体的CSP违规报告指出哪个资源被哪个指令阻止了。解决根据控制台报错逐步调整Content-Security-Policy头的策略将合法的资源域名如CDN、第三方统计代码加入script-src、style-src、img-src等指令中。这是一个迭代和细化的过程。问题服务器负载莫名升高日志中出现大量同一IP的请求。排查使用命令分析访问日志awk {print $1} access.log | sort | uniq -c | sort -nr | head -20查看请求最频繁的IP。结合请求路径如大量请求登录接口/api/login判断是否为暴力破解或CC攻击。解决立即对该IP应用更严格的limit_req和limit_conn限制或直接在防火墙层面临时封禁。长期方案是完善速率限制策略并对异常流量设置告警。安全配置不是一次性任务而是一个持续的过程。你需要定期如每季度回顾配置关注Nginx官方安全公告更新已知漏洞的配置项并根据业务变化和攻击趋势调整安全策略。将配置文档化并纳入版本控制系统如Git任何修改都有迹可循。记住安全的目标不是追求绝对的无懈可击而是在成本可控的前提下让攻击者的代价远高于收益。这份“大白话总结”提供的正是这样一套高性价比的Nginx安全加固起点。