Nginx中server、if、location块内return指令的差异及安全考量

咱们来聊聊Nginx里用return指令实现HTTP转HTTPS跳转的不同写法，以及每种写法的适用场景和安全细节。

一、在server块中使用return #

这种写法是把跳转规则直接放在server层级，比如下面这个例子：

# Redirect HTTP to HTTPS
server {
    server_name             .supersecure.codes;
    listen                  80;
    return                  307 https://$host$request_uri;
}

它的逻辑很直接：所有访问80端口、且Host头匹配.supersecure.codes（包括所有子域名）的HTTP请求，都会被返回307临时重定向到对应的HTTPS地址。307的好处是会保留原请求的方法（比如POST）和请求体内容，适合需要传递数据的场景。

二、在location块中使用return #

Mozilla的SSL配置生成工具会用这种写法来做跳转：

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}

这种写法把跳转规则放在location /里，最大的优势是灵活性强。如果之后你想在HTTP端口单独服务某些内容（比如静态资源、特定接口），直接在这个server块里新增对应的location规则就行，不用改动现有的跳转逻辑，维护起来更方便。

三、在if块中使用return #

这是某生产环境里的老配置：

server {
    if ($host = some.org) {
        return 301 https://$host$request_uri;
    }

    listen 80;
    server_name some.org;
    return 404;
}

它的逻辑是先检查请求的Host头是否严格等于some.org：如果匹配，就301永久重定向到HTTPS；如果不匹配，直接返回404。

这种写法的安全优势 #

之前在相关社区讨论里看到过对应的安全分析，这里给大家拆解下：
如果像Certbot默认那样，直接在server块里写return 301 https://$host$request_uri;，这个跳转完全依赖请求的Host头。要是这个server块是HTTP的默认服务器，攻击者可以构造带有恶意域名的Host头请求，万一遇到有bug或者配置错误的缓存服务器，就可能把这个恶意跳转缓存下来，导致正常用户访问时被导向攻击者指定的恶意域名。

而用if块判断Host的写法，只有当Host头完全匹配我们指定的域名时才会触发跳转，其他非法请求直接返回404，从根源上避免了这种被缓存恶意跳转的风险。虽然这种场景依赖缓存服务器的漏洞，但从防御性配置的角度来说，确实更安全。

备注：内容来源于stack exchange，提问作者toraritte