Nginx主机变量$http_host、$host与$proxy

Nginx主机变量$http_host、$host与$proxy_host详解

佚格麻瓜

1. 理解Nginx中的主机变量

在Nginx配置中，$http_host、$host和$proxy_host这三个变量看似相似，实则各有其特定的使用场景和行为特点。作为Web服务器管理员，我曾多次在配置反向代理和虚拟主机时混淆它们的用法，导致各种意料之外的请求转发问题。今天我们就来彻底拆解这三个变量的区别。

这三个变量都用于处理HTTP请求中的主机信息，但它们的来源、处理逻辑和使用场景各不相同。$http_host直接取自HTTP请求头，$host经过Nginx的标准化处理，而$proxy_host则是专门为反向代理场景设计的变量。理解它们的差异，能帮助我们避免配置错误导致的请求路由混乱、HTTPS重定向失败等问题。

2. 变量定义与来源解析

2.1 $http_host：原始请求头

$http_host变量直接对应客户端HTTP请求中的Host头部字段。当浏览器访问http://example.com时，请求头中会包含：

code复制Host: example.com

此时$http_host的值就是"example.com"，包括端口号（如果指定了非标准端口）。例如访问http://example.com:8080时：

code复制$http_host = "example.com:8080"

重要特性：

完全保留客户端原始请求的Host头信息
包含端口号（如果请求中有指定）
当请求没有Host头时，该变量为空

2.2 $host：标准化处理后的主机名

$host变量是Nginx经过一系列处理规则后得到的主机名，其确定顺序为：

从请求行中的主机名获取（HTTP/1.0）
从Host请求头获取（HTTP/1.1）
与server_name匹配的第一个名称

关键处理规则：

去除端口号（与$http_host的主要区别）
转换为小写形式
如果Host头包含非法字符，Nginx会拒绝请求

典型场景：

当配置基于域名的虚拟主机时
生成重定向URL时（避免携带冗余端口信息）

2.3 $proxy_host：反向代理专用

$proxy_host专为proxy_pass指令设计，表示上游服务器的地址。当配置：

nginx复制location / {
    proxy_pass http://backend;
}

且upstream定义为：

nginx复制upstream backend {
    server 192.168.1.10:8080;
}

此时$proxy_host的值为"192.168.1.10:8080"。

核心特点：

仅在使用proxy_pass时有效
反映实际连接的后端服务器地址
常用于设置Host请求头传递给后端

3. 使用场景对比分析

3.1 虚拟主机配置

在server块配置中，$host常用于匹配请求：

nginx复制server {
    listen 80;
    server_name example.com www.example.com;
    
    if ($host != 'example.com') {
        rewrite ^/(.*)$ http://example.com/$1 permanent;
    }
}

这里使用$host而非$http_host，因为：

不需要端口号信息
已经过标准化处理（统一小写）
避免因端口号差异导致重定向循环

3.2 反向代理配置

当Nginx作为反向代理时，通常需要将原始Host头传递给后端：

nginx复制location / {
    proxy_pass http://backend;
    proxy_set_header Host $host;
}

为什么使用$host而不是$http_host：

确保后端收到统一格式的主机名（无端口）
避免某些应用因端口号处理不当而出错
符合HTTP/1.1 Host头的标准格式

3.3 日志记录场景

在access_log中记录客户端原始信息时：

nginx复制log_format detailed '$remote_addr - $http_host [$time_local] '
                    '"$request" $status $body_bytes_sent';

此时使用$http_host更合适，因为：

需要完整记录客户端原始请求
包含端口号有助于调试非常规端口访问
反映用户实际访问的地址

4. 典型问题与解决方案

4.1 端口号处理不当导致的循环重定向

错误配置示例：

nginx复制server {
    listen 8080;
    server_name example.com;
    
    if ($http_host != 'example.com:8080') {
        return 301 http://example.com:8080$request_uri;
    }
}

问题分析：

硬编码端口号在配置中
当负载均衡器或CDN改变端口时会导致失败
某些客户端可能省略标准端口

正确做法：

nginx复制server {
    listen 8080;
    server_name example.com;
    
    if ($host != 'example.com') {
        return 301 $scheme://example.com$request_uri;
    }
}

4.2 反向代理丢失原始Host头

常见错误：

nginx复制location / {
    proxy_pass http://backend;
    # 忘记设置Host头
}

导致问题：

后端应用无法识别原始请求域名
基于域名的路由功能失效
可能破坏绝对URL生成

解决方案：

nginx复制location / {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header X-Original-Host $http_host;
}

4.3 HTTPS重定向问题

错误配置：

nginx复制server {
    listen 80;
    server_name example.com;
    
    return 301 https://$http_host$request_uri;
}

潜在问题：

重定向后的URL包含http://example.com:80
某些浏览器会隐藏默认端口
可能导致混合内容警告

推荐方案：

nginx复制server {
    listen 80;
    server_name example.com;
    
    return 301 https://$host$request_uri;
}

5. 高级应用场景

5.1 多域名代理的统一处理

当需要将多个域名代理到同一后端时：

nginx复制map $http_host $backend_host {
    default        backend_default;
    "domain1.com" backend_domain1;
    "domain2.com" backend_domain2;
}

server {
    listen 80;
    server_name domain1.com domain2.com;
    
    location / {
        proxy_pass http://$backend_host;
        proxy_set_header Host $host;
    }
}

5.2 动态上游选择

结合变量实现智能路由：

nginx复制set $upstream "";
if ($host ~* "^admin\.(.*)") {
    set $upstream "backend_admin_$1";
}

location / {
    proxy_pass http://$upstream;
    proxy_set_header Host $host;
}

5.3 协议相对重定向

处理HTTP/HTTPS自适应：

nginx复制server {
    listen 80;
    server_name example.com;
    
    location /secure {
        return 301 $scheme://$host/restricted$request_uri;
    }
}

6. 性能与安全考量

6.1 变量解析开销

不同变量的解析成本：

$http_host：直接从请求头读取，开销最低
$host：需要经过标准化处理，中等开销
$proxy_host：需要解析upstream配置，开销较高

优化建议：

避免在频繁执行的location中过度使用$proxy_host
对高流量站点，考虑使用map预处理复杂逻辑

6.2 安全防护措施

防范Host头攻击：

nginx复制server {
    listen 80 default_server;
    server_name _;
    
    if ($host !~* ^(example\.com|www\.example\.com)$ ) {
        return 444;
    }
}

6.3 请求头验证

验证Host头合法性：

nginx复制if ($http_host ~* "[\r\n]") {
    return 400 "Invalid Host header";
}

7. 调试技巧与实践

7.1 变量值输出调试

临时调试配置：

nginx复制location /debug {
    add_header X-Debug-Http_Host $http_host;
    add_header X-Debug-Host $host;
    add_header X-Debug-Proxy_Host $proxy_host;
    return 200 "Debug information sent in headers";
}

7.2 日志级别调整

获取详细变量信息：

nginx复制error_log /var/log/nginx/debug.log debug;

server {
    ...
    set $my_var $host;
    ...
}

7.3 单元测试方法

使用curl验证：

bash复制# 测试$http_host包含端口
curl -H "Host: example.com:8080" http://nginx-server

# 测试默认端口省略
curl -H "Host: example.com" http://nginx-server:8080

# 测试无效Host头处理
curl -H "Host: example.com\r\nInjection: true" http://nginx-server

8. 最佳实践总结

经过多年Nginx配置实践，我总结出以下经验：

在大多数情况下优先使用$host：
- 自动处理端口号标准化
- 符合HTTP标准
- 避免重定向问题
需要原始客户端信息时使用$http_host：
- 日志记录
- 特殊路由需求
- 调试目的
反向代理场景注意$proxy_host的特殊性：
- 仅在proxy_pass上下文中有效
- 反映实际后端连接信息
- 通常不直接用于请求头设置
关键配置检查清单：
- 所有重定向都使用$host而非$http_host
- 反向代理必须设置proxy_set_header Host
- 对用户提供的Host头进行验证
性能敏感场景：
- 避免在频繁匹配的location中使用复杂变量
- 考虑使用map预处理常用映射关系
- 对固定值使用set指令缓存结果