Nginx 不直接连接数据库，而是通过IP封禁、路径限流、请求模式拦截和白名单机制，在流量入口处阻断恶意请求，防止其穿透至数据库代理或API层。
Nginx 本身不直接连接数据库，但它作为反向代理或网关，能有效拦截、过滤、限流发往后端服务（包括数据库代理层，如 pgBouncer、MySQL Router 或 API 层）的恶意请求。预防特定 IP 对后端数据库的冲击，核心不是“让 Nginx 去查数据库”，而是在流量入口处阻断或压制那些可能触发数据库高负载的异常访问行为。
关键思路是：识别攻击特征 → 在 Nginx 层做前置控制 → 避免请求穿透到数据库代理或应用层。
一、精准封禁已知恶意 IP
最直接有效的方式，适用于已确认攻击源的场景。
http {
# 在 http 块中定义 IP 黑名单
geo $bad_ip {
default 0;
192.168.5.100 1; # 攻击源 IP
203.0.113.42 1;
2001:db8::1 1; # 支持 IPv6
}
map $bad_ip $blocked {
1 1;
default 0;
}
server {
location / {
if ($blocked) {
return 403 "Access denied";
}
proxy_pass http://backend_db_api; # 指向数据库代理或 API 网关
}
}
}⚠️ 注意：if 在 location 中慎用，但用于简单 IP 判断是安全且高效的；更推荐用 geo + map 组合，避免正则开销。
二、对数据库相关路径做强限流
攻击者常通过高频查询接口（如 /api/v1/query, /search, /report）反复刷数据库。需针对性限流：
http {
# 按 IP + 路径组合限流，防止绕过单 IP 限制
limit_req_zone $binary_remote_addr$request_uri zone=db_api:10m rate=3r/s;
server {
location ~ ^/(api/v1/query|search|report) {
limit_req zone=db_api burst=5 nodelay;
proxy_pass http://db_gateway;
proxy_set_header X-Real-IP $remote_addr;
}
}
}✅ 效果：同一 IP 访问 /api/v1/query?id=1 和 /api/v1/query?id=2 视为不同 key（因 $request_uri 包含参数），但若攻击者固定 URI 刷量，仍会被严格限制。
? 进阶建议：用 $binary_remote_addr$host 或 $binary_remote_addr$http_user_agent 做 zone key，可识别伪装 IP 的爬虫或工具。
三、拦截高风险请求模式
很多数据库冲击源于构造性请求，如超长参数、异常 method、可疑 header：
server {
# 拒绝非标准方法
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$ ) {
return 405;
}
# 拒绝超长 query string（防 SQL 注入探测或暴力遍历）
if ($args ~ "[a-zA-Z0-9_]{100,}") {
return 444; # 直接关闭连接，不返回响应
}
# 拒绝无 User-Agent 或 UA 含典型扫描器标识
if ($http_user_agent = "" ) {
return 444;
}
if ($http_user_agent ~* "(sqlmap|nmap|dirbuster|gau)") {
return 444;
}
location /api/ {
proxy_pass http://db_backend;
}
}? 提示：return 444 比 403 更隐蔽，不暴露服务存在，适合防御自动化探测。
四、结合白名单保护关键操作
对真正需要高频访问数据库的内部系统（如运维后台、BI 工具），用 IP 白名单放开限制：
geo $trusted {
default 0;
10.10.0.0/16 1; # 内网段
192.168.100.5 1; # DBA 主机
}
map $trusted $db_rate {
1 "100r/s";
0 "3r/s";
}
http {
limit_req_zone $binary_remote_addr zone=db_safe:10m rate=$db_rate;
server {
location /admin/db/ {
limit_req zone=db_safe burst=10;
proxy_pass http://db_admin;
}
}
}这样既保障运维效率，又严控外部访问节奏。
不复杂但容易忽略。
