反向代理服务器Nginx的安全配置与Web应用防护
摘要：# 别再让Nginx裸奔了：聊聊那些“反向代理”里藏着的安全漏洞 我前两天帮一个朋友看他的线上业务，好家伙，网站直接用的Nginx反向代理到后端Tomcat，配置打开一看，差点没背过气去——基本就是默认配置改了个端口，啥防护都没加。我问他：“你这跟把服务…
别再让Nginx裸奔了：聊聊那些“反向代理”里藏着的安全漏洞
我前两天帮一个朋友看他的线上业务，好家伙，网站直接用的Nginx反向代理到后端Tomcat，配置打开一看，差点没背过气去——基本就是默认配置改了个端口，啥防护都没加。我问他：“你这跟把服务器IP直接印在名片上发出去有啥区别？” 他嘿嘿一笑：“这不是一直没出事嘛。”
这种心态我见得太多了。很多人觉得，Nginx就是个“转发请求”的，配置好了能访问就行，安全那是防火墙和WAF的事儿。说真的，这种想法才是最危险的漏洞。 很多所谓的“高级防护方案”，PPT写得天花乱坠，真遇到针对性攻击，第一个垮掉的就是你那个没穿“盔甲”的反向代理。
今天咱不聊那些云里雾里的黑话，就实实在在地盘盘，一个扛在生产环境最前线的Nginx反向代理，到底该怎么配置才能让人睡得着觉。
反向代理不是“传声筒”，它是你家第一道门
首先得打破一个误区：Nginx做反向代理，可不仅仅是把请求“倒个手”那么简单。你想想，所有用户请求都得先过它，再往后端送——这位置，简直就是小区保安亭啊。一个合格的保安，能只看个脸就放行吗？
你得让他会查证件（请求校验）、会拦可疑人物（恶意流量）、甚至能临时处理点小纠纷（缓存静态内容、限流）。很多站点的性能瓶颈和安全事件，根源都不是后端代码写得多烂，而是这个“保安”当得太佛系。
我见过最离谱的一个配置，直接把$host变量透传到后端，这等于把用户可能伪造的Host头原封不动交给了应用服务器。不出事才怪。
别让这些“默认配置”坑了你
Nginx安装完，那个默认的配置文件，就是个毛坯房，根本不能直接住人（上线）。咱得自己动手装修几个关键地方。
1. 先把“门牌号”藏好
server_tokens off;就这一行，必须加在http模块里。它的作用是让Nginx在报错页面和响应头里，别把自己的版本号给爆出来。你想想，攻击者一看到“nginx/1.18.0”，不就直接知道该用哪个版本的漏洞来打你了吗？这跟出门把家门钥匙插在锁眼上有啥区别。
2. 管好那些“不存在的房间” 默认情况下，你访问一个不存在的URI，Nginx可能会去尝试匹配文件路径，或者返回一些奇怪的索引信息。这会给扫描器可乘之机。
location / {
# 禁止访问隐藏文件（以点开头的）
location ~ /\.(?!well-known) {
deny all;
access_log off;
log_not_found off;
}
# 禁止访问常见敏感文件
location ~* (\.(git|svn|htaccess|bak|conf|sql)|~)$ {
deny all;
access_log off;
}
}说白了，就是告诉Nginx，凡是看到像.git目录、.bak备份文件这类明显是敏感信息的东西，直接拒之门外，连日志都别记，省得脏了你的日志文件。
3. 给请求“瘦身” 黑客常喜欢往请求里塞巨型的Header或者超长的URL，来拖垮你的服务器。你得设个规矩：
client_max_body_size 10m;
client_header_buffer_size 4k;
large_client_header_buffers 4 16k;这意思是，请求体最大别超过10M（具体按你业务来），普通的请求头缓冲区给4k，不够的话再用大的。超过？对不起，414（Request-URI Too Large）或者413（Request Entity Too Large）错误码送你，请求根本到不了后端。
核心防护：给Web应用穿上软猬甲
上面是基础加固，接下来才是真正体现“防护”价值的地方。你的Web应用（比如Java的Spring、PHP的Laravel）可能自己有些安全机制，但让Nginx在前面先滤一道，能省下后端大量计算资源。
1. 限流：对付CC攻击的“土办法”最有效 CC攻击说白了就是找来一堆“慢速客户端”或者代理IP，不停地发起正常请求，耗光你服务器的连接数。在Nginx这层做限流，立竿见影。
# 在http模块定义限流区域
limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;
server {
location /api/ {
# 应用限流，突发流量不超过5个请求
limit_req zone=api_per_ip burst=5 nodelay;
proxy_pass http://backend_server;
}
}这个配置给每个IP地址建了个“桶”，每秒最多只能从桶里舀10勺水（10个请求）。偶尔手抖多舀5勺（burst=5）也行，但再多就得等着了。对于登录口、短信验证码接口，这招能挡掉大部分自动化脚本的狂轰滥炸。
2. 屏蔽“坏蛋”的惯用伎俩
很多Web漏洞利用都有固定特征，比如SQL注入总少不了union select、sleep(这些字符串，文件包含攻击会带着../往上跳目录。虽然WAF更专业，但Nginx自己也能挡一波：
# 在server或location块里
set $block 0;
if ($query_string ~* "union.*select|select.*from|(?:sleep|benchmark)\s*\(|\.\./") {
set $block 1;
}
if ($request_uri ~* "(eval|base64_encode)") {
set $block 1;
}
if ($block = 1) {
return 403;
}注意，这种if判断要谨慎使用，性能有损耗，规则也别写太复杂，容易误伤。但针对一些极其明显的攻击特征，简单粗暴地返回个403，效果拔群。（这里得插一句，正则别写太死，不然正常用户带个“union”单词的搜索都可能被拦，我就吃过这个亏。）
3. 重要的头部管理：别让信息从你这里漏出去 通过反向代理时，有些来自客户端的头部信息，是绝对不能直接传给后端的。
location / {
proxy_pass http://backend_server;
# 移除客户端可能伪造的头部
proxy_set_header Host $http_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;
# 显式覆盖一些敏感头，确保后端收到的是你设置的，而不是客户端传来的
proxy_set_header X-Forwarded-Host "";
proxy_set_header X-Original-URI "";
}特别是X-Forwarded-Host这类头，如果被恶意用户伪造，可能导致后端应用的重定向劫持。你作为代理，必须自己重新设定一套可信的头部信息，告诉后端：“听我的，别听客户的。”
几个容易被忽略，但能救命的细节
- Upstream的“超时”与“重试”：别把
proxy_read_timeout、proxy_connect_timeout设得老长，这等于给慢速攻击开了后门。后端挂了，也别无限重试，设置proxy_next_upstream在特定错误（如502、504）时尝试下一个后端，并限制重试次数。 - 日志是你的“监控摄像头”：别只记个
access.log就完了。把$request_time、$upstream_response_time这些字段加上，哪天突然发现响应时间飙升，可能就是被攻击的前兆。日志最好实时收集分析，别等硬盘满了才看。 - SSL/TLS配置别偷懒：如果用了HTTPS，记得禁用老的、不安全的SSL协议（如SSLv2、SSLv3），选用安全的加密套件。可以用Mozilla的SSL配置生成器，选“Intermediate”兼容性那个配置，省心又安全。
最后说点大实话
安全配置从来不是一劳永逸的。你今天配好了，下个月出了新的漏洞利用方式，可能又得调整。所以，千万别把配置写死，多用include指令把不同功能的配置放到单独文件里，管理起来方便，更新也安全。
还有，配完了一定要测试。用nginx -t检查语法只是第一步，最好自己用curl或者一些简单的扫描工具（比如nmap的http-enum脚本）从外网扫一下，看看还有哪些信息漏了，哪些不该开放的端口还开着。
说到底，Nginx反向代理的安全配置，就是个“精细活”。它不需要你买多贵的高防IP，但需要你花时间去理解每一个参数背后的含义。你的网站是开着跑车，还是穿着拖鞋在裸奔，区别往往就在这些细节里。
行了，配置去吧。记得改之前，先备份。