Nginx实战：5分钟搞定Host头攻击防御配置（附正则表达式模板）

最近在帮几个创业团队做安全加固，发现一个挺普遍的现象：很多工程师对Host头攻击的原理能说个大概，知道它危险，但一到具体配置Nginx防御规则时就卡壳了。要么是正则表达式写不对，要么是配置放错了地方，结果漏洞一直敞开着。其实，这种攻击的防御配置远没有想象中复杂，核心就是几行配置，关键在于理解Nginx处理请求的流程和正则匹配的逻辑。今天我就把自己在多个生产环境里验证过的配置模板拆开揉碎了讲清楚，让你真正能在5分钟内部署到位，而不是停留在“知道但不会做”的层面。

1. 理解Host头攻击：为什么你的Nginx可能正在“裸奔”

Host头，这个看似普通的HTTP请求头，实际上是Web通信的“导航仪”。它告诉服务器：“我这次访问，目标是哪个域名。”对于一台服务器托管了多个网站（虚拟主机）的情况，Nginx就靠这个头来决定把请求交给哪个server块来处理。问题就出在这里：如果这个“导航仪”被恶意篡改了，会发生什么？

想象一下，你有一栋大楼（服务器），里面有很多公司（网站）。每个公司都有独立的门牌号和前台（server_name）。Host头就像是访客说的“我要去A公司”。正常情况下，前台会把他指引到A公司。但如果一个别有用心的人大喊“我要去B公司的机密档案室”，而你的前台（Nginx配置）没有核实他的身份和权限，就直接放行，甚至真的把他带到了B公司的核心区域，这就是Host头攻击最形象的比喻。

攻击者篡改Host头，通常不是为了“走错门”，而是有更明确的目的：

• 绕过安全验证：有些应用的安全检查逻辑依赖于Host头。比如，管理后台admin.example.com只允许内网IP访问，但攻击者通过将Host头改为admin.example.com来访问面向公网的www.example.com的IP，可能就能绕过IP限制。
• 缓存投毒：如果缓存系统（如CDN、Nginx缓存）以Host: 域名作为缓存键的一部分，攻击者通过伪造Host头，就能向缓存中注入恶意内容，影响其他正常用户。
• 密码重置劫持：有些老旧应用在生成密码重置链接时，直接使用了Host头来构建完整的URL。攻击者伪造Host头指向自己控制的域名，用户点击重置链接，密码就直接发到了攻击者手里。
• SSRF漏洞的跳板：在服务器端请求伪造（SSRF）场景中，伪造的Host头可能被用于访问内部网络服务。

很多默认的Nginx配置，或者从网上下载的“一键配置”，往往没有对Host头做任何校验。这就相当于大楼的前台对任何访客的“指路要求”都照单全收，风险不言而喻。下面这个最简单的配置，就是典型的“裸奔”状态：

server {
    listen 80;
    # 这里只声明了server_name，但没有验证请求的Host头是否匹配
    server_name www.example.com;
    root /var/www/html;
    ...
}

这个配置能正常工作，是因为Nginx默认会使用请求中的Host头来匹配server_name。但如果请求的Host头是evil.com，而你的服务器上没有为evil.com定义的server块，Nginx会默认使用第一个server块（或指定了default_server的块）来处理。攻击者就可能利用这个机制，将流量导向一个并非为他准备的server配置，结合应用层逻辑缺陷，发起攻击。

2. 核心防御策略：在Nginx层面构建“验证前台”

防御的核心思想很直接：在请求到达后端应用（如PHP、Python、Java应用）之前，就在Nginx这一层，对来访者声称的“目的地”（Host头）进行严格盘查。只放行我们明确允许的、合法的域名访问请求，其他一切伪造、猜测、探测的请求，直接拒绝并返回错误。这样，后端应用甚至都“看不到”这些恶意请求，安全性得到极大提升。

我们的防御体系主要围绕两个关键配置指令展开：$host变量和$http_host变量。理解它们的区别是写出正确配置的前提。

• $http_host： 这就是客户端原始请求头中Host:字段的值，未经Nginx处理。它是我们进行验证的直接对象。
• $host： 这个变量是Nginx经过一系列处理（比如去除端口号、大小写转换等）后得到的“规范化”主机名。它的优先级顺序是：请求行中的主机名 > “Host”请求头字段 > 与请求匹配的server_name。在防御配置中，我们通常优先使用$http_host进行精确匹配验证。

基于此，我们构建一个三层防御策略：

1. 第一层：默认丢弃。配置一个默认的server块，监听所有未明确匹配的请求，直接返回444（连接关闭）或自定义错误页。这是兜底策略。
2. 第二层：精确白名单。在每个正式的server块内，使用if指令和正则表达式，严格校验$http_host是否完全符合我们允许的域名。这是主防御阵地。
3. 第三层：应用层加固。指导后端应用程序避免直接信任Host头，而是从Nginx设置的安全变量（如$server_name）中获取域名信息。

接下来，我们就进入最关键的实战配置环节。

3. 5分钟部署：可复用的Nginx配置模板与详解

让我们直接上干货。下面这套配置模板，你可以根据注释说明，直接复制到你的Nginx配置文件中（通常是/etc/nginx/conf.d/目录下的某个.conf文件，或在主配置nginx.conf的http块内），替换掉你的域名即可。

3.1 基础防御配置模板

首先，我们为你的业务域名（例如www.example.com和example.com）创建一个安全的server块。

# 第一部分：定义合法的域名白名单，这里用变量方便管理和复用
# 将你的主域名和可能用到的二级域名放在这里
map $http_host $valid_host {
    default 0; # 默认都不合法
    "~^www\.example\.com(:[0-9]+)?$" 1; # 匹配 www.example.com 及其带端口的形式
    "~^example\.com(:[0-9]+)?$" 1;       # 匹配 example.com 及其带端口的形式
    # 你可以继续添加其他合法域名，例如：
    # "~^api\.example\.com(:[0-9]+)?$" 1;
    # "~^blog\.example\.com(:[0-9]+)?$" 1;
}

# 第二部分：主业务服务器配置
server {
    listen 80;
    # 强烈建议也配置SSL，这里以HTTP为例，HTTPS配置同理
    # listen 443 ssl;
    # ssl_certificate /path/to/cert.pem;
    # ssl_certificate_key /path/to/key.pem;

    # 声明这个块负责的合法域名
    server_name www.example.com example.com;

    # --- 核心防御配置开始 ---
    # 使用if指令检查$http_host是否在白名单内
    # 如果$valid_host变量不为1（即不合法），则直接返回444状态码（Nginx立即关闭连接）
    if ($valid_host != 1) {
        return 444;
    }
    # --- 核心防御配置结束 ---

    # 可选但推荐：设置一个安全的、内部使用的Host变量传递给后端
    # 这里强制将后端收到的Host头固定为www.example.com，避免应用层误用
    proxy_set_header Host www.example.com;

    # 你的其他业务配置，例如根目录、代理设置等
    root /var/www/example.com/public;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        # 注意：如果使用了上面的proxy_set_header，这里通常不需要再单独设置Host
    }

    # 其他location配置...
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
}

# 第三部分：默认服务器块（兜底）
# 这个块捕获所有未被上面server_name匹配的请求（包括Host头非法的请求，如果它侥幸绕过了上面块的if判断）
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    # 对于HTTPS，也需要一个default_server的SSL监听
    # listen 443 ssl default_server;
    # listen [::]:443 ssl default_server;

    # 直接返回444，不记录日志，消耗最小资源处理恶意请求
    return 444;
}

3.2 正则表达式模板拆解与自定义

配置的核心在于map块里的正则表达式。它决定了哪些Host头是“合法”的。上面的模板用了两个：

• "~^www\.example\.com(:[0-9]+)?$"
• "~^example\.com(:[0-9]+)?$"

我们来拆解一下这个模式"~^域名(:[0-9]+)?$"：

• ~^： 表示从此处开始进行正则匹配。
• www\.example\.com： 这是要匹配的精确域名。注意点号.需要用反斜杠\转义，因为在正则中.代表任意字符。
• (:[0-9]+)?： 这是一个可选分组。
  • :： 匹配冒号。
  • [0-9]+： 匹配一个或多个数字（端口号）。
  • ?： 表示前面的(:[0-9]+)这个分组出现0次或1次。即匹配带端口号（如www.example.com:8080）或不带端口号的情况。
• $： 匹配字符串的结束。这非常重要，确保evilexample.com这样的域名不会因为部分匹配而被放行。

提示： 如果你希望允许任何端口，但严格限定域名，这个表达式是合适的。如果你只想允许标准的80或443端口访问，可以修改为"~^www\.example\.com(:80|:443)?$"，但这通常不必要，因为Nginx监听的是端口，请求中的端口信息更多是客户端告知的。

如何自定义你的白名单？

假设你的业务还有m.example.com（移动站）和static.example.com（静态资源），只需在map块中添加两行：

map $http_host $valid_host {
    default 0;
    "~^www\.example\.com(:[0-9]+)?$" 1;
    "~^example\.com(:[0-9]+)?$" 1;
    "~^m\.example\.com(:[0-9]+)?$" 1;
    "~^static\.example\.com(:[0-9]+)?$" 1;
}

3.3 针对复杂场景的进阶配置

场景一：需要区分HTTP和HTTPS的严格校验 有时，你可能希望HTTP请求强制跳转到HTTPS，并且在跳转前也做Host头验证。可以这样配置：

server {
    listen 80;
    server_name www.example.com example.com;

    # 同样进行Host头验证
    if ($valid_host != 1) {
        return 444;
    }

    # 合法的HTTP请求，重定向到HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com example.com;
    ssl_certificate ...;
    ssl_certificate_key ...;

    # HTTPS站点同样需要验证
    if ($valid_host != 1) {
        return 444;
    }
    ... # 其余HTTPS配置
}

场景二：反向代理到后端应用 当Nginx作为反向代理时，除了验证传入的Host头，更重要的是重写发送给后端的Host头，防止后端应用被欺骗。

server {
    listen 80;
    server_name api.example.com;

    if ($valid_host != 1) {
        return 444;
    }

    location / {
        proxy_pass http://backend_server_ip:port;

        # 关键！覆盖后端接收到的Host头，固定为预期的值或使用Nginx的$host变量
        proxy_set_header Host $server_name; # 或直接写死为 "api.internal.com"
        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;
    }
}

场景三：处理缺失Host头的请求 HTTP/1.0规范不要求Host头，但现代浏览器和工具都会发送。为防万一，可以显式拒绝缺失Host头的请求。这通常在默认server块或主location中处理。

# 在主server块或http块中
if ($http_host = "") {
    # 可以返回400错误（错误请求）或直接444
    return 400;
}

4. 配置验证、测试与监控

配置写好了，千万别直接重启了事。不经过测试的配置上线，就是给自己埋雷。

第一步：语法检查 在保存配置文件后，执行：

sudo nginx -t

如果看到 syntax is ok 和 test is successful，说明语法没问题。

第二步：模拟攻击测试 使用curl命令模拟各种恶意和边缘请求，观察响应是否符合预期。

1. 测试合法请求：

   curl -H "Host: www.example.com" http://你的服务器IP/
   

   应该返回你网站的正常内容或200状态码。

2. 测试非法域名：

   curl -H "Host: evil.com" http://你的服务器IP/
   

   应该没有正常响应，连接会被立即关闭。你可以用-v参数查看详细过程，通常会看到 curl: (52) Empty reply from server。

3. 测试缺失Host头（如果配置了相关规则）：

   curl -H "Host:" http://你的服务器IP/
   

   应该返回400错误。

4. 测试端口篡改：

   curl -H "Host: www.example.com:9999" http://你的服务器IP/
   

   根据你的正则表达式（是否包含(:[0-9]+)?），这个请求可能被允许（返回200）或拒绝（返回444）。通常允许是安全的，因为端口是客户端声明的，不影响服务器端路由。

5. 测试大小写混淆：

   curl -H "Host: WwW.ExAmPlE.CoM" http://你的服务器IP/
   

   Nginx的$http_host是大小写敏感的，但map匹配默认区分大小写。上面的请求会被拒绝。如果你需要支持，可以使用~*前缀进行不区分大小写的匹配，但需谨慎，避免引入新的歧义。

第三步：监控日志 配置生效后，密切关注Nginx的错误日志（error_log）。被return 444;拒绝的请求通常不会在访问日志中留下记录，但如果有语法错误或配置问题，会在错误日志中体现。你也可以在默认的server块中自定义一个access_log来记录所有“捕获”的非法请求，用于安全分析。

server {
    listen 80 default_server;
    ...
    access_log /var/log/nginx/default_host_attack.log combined;
    return 444;
}

第四步：集成到CI/CD或配置管理 对于使用Ansible、SaltStack、Chef或Terraform等工具管理服务器配置的团队，应该将这份加固配置模板化，纳入自动化部署流程，确保所有新上线的Nginx服务都默认具备Host头防御能力。

最后，别忘了安全是一个持续的过程。这份配置能有效阻断绝大多数基于Host头的初级和中级攻击，但它不是银弹。结合Web应用防火墙（WAF）、定期安全扫描、保持Nginx和系统补丁更新，才能构建更立体的防御体系。在实际操作中，如果遇到因配置导致合法业务异常的情况，最需要检查的就是map块里的正则表达式是否完整覆盖了所有合法的访问来源（比如公司的监控系统、API回调等可能使用的特殊Host头）。