Nginx中301与302重定向的配置指南

更新时间：2026年07月13日 08:26:13 作者：知远漫谈

本文深入讲解了Nginx中301永久重定向和302临时重定向的配置方法与核心区别,通过真实场景示例,涵盖域名跳转、路径重定向等常见需求,有需要的小伙伴可以了解下

在现代 Web 架构中，重定向（Redirect）是不可或缺的一环。无论是网站迁移、HTTPS 强制启用、旧链接维护、多域名统一访问，还是 A/B 测试、负载均衡前的流量引导，301 永久重定向 和 302 临时重定向 都扮演着关键角色。而作为全球最流行的 Web 服务器之一，Nginx 凭借其高性能、低资源消耗和强大的配置灵活性，成为绝大多数中大型网站的首选。

本文将深入剖析 Nginx 中 301 和 302 重定向的配置原理、应用场景、最佳实践，并结合 Java 后端服务的实际交互案例，帮助你从理论到实战全面掌握这一核心技能。我们将通过真实可运行的配置示例、清晰的 Mermaid 流程图、以及 Java 代码片段，带你理解“为什么这样配置”、“何时该用 301”、“302 为何更灵活”，以及如何避免常见的陷阱。

什么是 HTTP 重定向？

在 HTTP 协议中，重定向 是服务器告诉客户端：“你请求的资源现在不在这里了，请去另一个地址获取”。客户端（如浏览器、爬虫、API 客户端）收到响应后，会自动向新地址发起第二次请求。

HTTP 状态码是这一过程的核心标识。其中：

301 Moved Permanently：永久重定向。告诉客户端“这个资源已永久迁移到新地址，请更新书签、链接、缓存”。
302 Found（原名 302 Moved Temporarily）：临时重定向。表示“资源暂时在别处，下次还来原地址”。

301 是 SEO 友好的选择 —— 搜索引擎会把原 URL 的权重（PageRank）传递给新 URL。

302 不传递权重，搜索引擎仍保留原 URL 为“主地址”。

举个生活化的例子

想象你住在“北京市朝阳区幸福路1号”，但政府通知你：

301：你的住址永久变更为“北京市海淀区安宁路2号”，所有快递、信件都应寄往新地址。你也要更新身份证、驾照上的地址。
302：你家正在装修，暂时搬去“北京市海淀区安宁路2号”住一个月，下个月还回来。快递公司仍会把信寄到老地址，等你搬回来再转交。

这就是 301 和 302 的本质区别。

Nginx 中配置 301 与 302 重定向的语法

Nginx 使用 return 和 rewrite 指令实现重定向。虽然两者都能达到目的，但推荐优先使用 return，因为它更高效、语义更清晰。

推荐方式：return 301/302

server {
    listen 80;
    server_name old-domain.com www.old-domain.com;

    # 永久重定向到新域名
    return 301 https://new-domain.com$request_uri;
}

server {
    listen 80;
    server_name example.com;

    # 临时重定向到维护页面
    return 302 https://maintenance.example.com;
}

不推荐方式：rewrite ... redirect

rewrite ^(.*)$ https://new-domain.com$1 redirect;

虽然也能实现重定向，但 rewrite 是正则引擎驱动的，性能略低，且语义模糊。return 是直接返回 HTTP 状态码 + Location 头，无额外解析开销，是 Nginx 官方推荐的最佳实践。

场景一：域名跳转 —— 从 HTTP 到 HTTPS

这是最常见、最基础的重定向需求。几乎所有现代网站都强制使用 HTTPS，以保障用户数据安全、提升 SEO 排名、满足浏览器安全策略（如混合内容阻止）。

场景描述

你有一个网站 http://example.com，现在希望所有访问都跳转到 https://example.com。

Nginx 配置方案

# 监听 80 端口，接收所有 HTTP 请求
server {
    listen 80;
    server_name example.com www.example.com;

    # 永久重定向到 HTTPS 版本，保留原始路径和查询参数
    return 301 https://$host$request_uri;
}

# 监听 443 端口，提供 HTTPS 服务
server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # 其他 SSL 配置...
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;
    ssl_prefer_server_ciphers off;

    root /var/www/html;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

关键参数解析

参数	说明
`$host`	客户端请求中的 Host 头，支持 `example.com` 或 `www.example.com`，自动适配
`$request_uri`	完整的原始请求 URI（含查询参数），如 `/product?id=123`
`return 301`	立即返回 301 响应，不进入后续 location 处理流程

优点：简洁、高效、无正则匹配、零性能损耗

安全性：所有 HTTP 流量被彻底拦截，强制升级为加密连接

Java 客户端测试示例

你可以用 Java 的 HttpURLConnection 模拟一次 HTTP 请求，验证是否成功跳转：

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
public class RedirectTest {
    public static void main(String[] args) throws Exception {
        URL url = new URL("http://example.com/api/v1/users");
        HttpURLConnection conn = (HttpURLConnection) url.openConnection();
        conn.setInstanceFollowRedirects(false); // 禁用自动跳转，以便查看原始响应
        int responseCode = conn.getResponseCode();
        String location = conn.getHeaderField("Location");
        System.out.println("🚀 响应状态码: " + responseCode);
        System.out.println("📍 重定向地址: " + location);
        // 读取响应头
        conn.getHeaderFields().forEach((key, values) -> {
            if (key != null) {
                System.out.println(key + ": " + values);
            }
        });
        // 如果是 301/302，手动发起第二次请求
        if (responseCode == 301 || responseCode == 302) {
            System.out.println("\n🔄 手动发起 HTTPS 请求...");
            URL secureUrl = new URL(location);
            HttpURLConnection secureConn = (HttpURLConnection) secureUrl.openConnection();
            secureConn.setRequestMethod("GET");
            int secureCode = secureConn.getResponseCode();
            System.out.println("🔐 HTTPS 响应码: " + secureCode);
        }
    }
}

运行结果示例：

🚀 响应状态码: 301
📍 重定向地址: https://example.com/api/v1/users
Location: https://example.com/api/v1/users
Content-Type: text/html
Content-Length: 162

🔄 手动发起 HTTPS 请求...
🔐 HTTPS 响应码: 200

说明：Nginx 成功返回 301，Java 客户端捕获并跟随跳转，最终获得 200 响应，证明配置生效。

场景二：域名跳转 —— 从非 www 到 www（或反之）

很多公司希望统一品牌访问入口，比如统一用 www.example.com，或彻底去掉 www。

场景描述

用户访问 http://example.com → 应跳转至 https://www.example.com
用户访问 http://www.example.com → 保持不变（作为主域名）

Nginx 配置方案

# 主服务器块：处理 www 域名
server {
    listen 443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/ssl/certs/www.example.com.crt;
    ssl_certificate_key /etc/ssl/private/www.example.com.key;

    root /var/www/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

# 重定向非 www 到 www
server {
    listen 80;
    server_name example.com;

    return 301 https://www.example.com$request_uri;
}

# 重定向非 www 的 HTTPS 请求到 www
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/www.example.com.crt;
    ssl_certificate_key /etc/ssl/private/www.example.com.key;

    return 301 https://www.example.com$request_uri;
}

为什么这样配置？

两个 server 块监听 example.com：一个 80 端口，一个 443 端口。
都返回 301 到 www.example.com。
www.example.com 的 server 块负责提供真实内容。

这样做确保无论用户输入 http://example.com、https://example.com、http://www.example.com，最终都会统一到 https://www.example.com。

场景三：路径重定向 —— 旧链接迁移

网站改版后，旧路径（如 /old-blog/post1）被替换为新路径（如 /blog/post-1）。为了不丢失 SEO 权重和用户书签，必须设置 301 重定向。

场景描述

旧路径：/products/123
新路径：/shop/item/123

Nginx 配置方案

server {
    listen 80;
    server_name example.com;

    # 永久重定向：/products/123 → /shop/item/123
    location ~ ^/products/(\d+)$ {
        return 301 /shop/item/$1;
    }

    # 永久重定向：/blog/old → /blog/new
    location = /blog/old {
        return 301 /blog/new;
    }

    # 通配符重定向：/old-category/* → /new-category/*
    location ~ ^/old-category/(.*)$ {
        return 301 /new-category/$1;
    }

    # 默认路径处理
    location / {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

正则表达式说明

表达式	含义
`^/products/(\d+)$`	匹配以 `/products/` 开头，后面是至少一个数字，结尾
`(\d+)`	捕获组，捕获数字部分，可在 `$1` 中引用
`location = /blog/old`	精确匹配，性能最高，适用于固定路径
`location ~ ^/old-category/(.*)$`	正则匹配，捕获任意后缀

Java 测试代码：验证路径重定向

import java.net.HttpURLConnection;
import java.net.URL;
public class PathRedirectTest {
    public static void main(String[] args) throws Exception {
        String[] testUrls = {
            "http://example.com/products/123",
            "http://example.com/blog/old",
            "http://example.com/old-category/summer-sale"
        };
        for (String urlStr : testUrls) {
            URL url = new URL(urlStr);
            HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            conn.setInstanceFollowRedirects(false);
            int code = conn.getResponseCode();
            String location = conn.getHeaderField("Location");
            System.out.println("🔍 测试: " + urlStr);
            System.out.println("   → 状态码: " + code);
            System.out.println("   → 跳转到: " + location);
            System.out.println("---");
        }
    }
}

输出示例：

🔍 测试: http://example.com/products/123
→ 状态码: 301
→ 跳转到: /shop/item/123
---
🔍 测试: http://example.com/blog/old
→ 状态码: 301
→ 跳转到: /blog/new
---
🔍 测试: http://example.com/old-category/summer-sale
→ 状态码: 301
→ 跳转到: /new-category/summer-sale
---

所有路径都被正确捕获并重定向，完美保留原始路径参数！

场景四：临时维护页（302）与灰度发布

有时你不想永久改变路径，而是需要临时引导用户到维护页面、测试环境或 A/B 页面。

场景描述

网站即将升级，需在 2 小时内引导 10% 用户访问 https://beta.example.com
使用 302，避免搜索引擎收录测试页

Nginx 配置方案

server {
    listen 80;
    server_name example.com;

    # 10% 的用户被临时重定向到 beta 环境
    if ($remote_addr ~ "192.168.1.*") {
        return 302 https://beta.example.com$request_uri;
    }

    # 随机 10% 用户（基于 cookie 或 User-Agent 也可）
    # 这里用简单的随机数模拟（实际中建议用更精准的策略）
    set $redirect_flag 0;
    if ($http_user_agent ~* "Chrome") {
        set $redirect_flag "1";
    }

    if ($redirect_flag = "1") {
        # 仅对 Chrome 用户做 10% 重定向（伪随机）
        set $test_ratio $arg_test_ratio;
        if ($test_ratio = "") {
            set $test_ratio "0.5"; # 默认 50%，可配合后端动态设置
        }

        # 伪随机逻辑（实际生产中建议用 Lua 模块或后端控制）
        # 这里简化处理：仅演示 302 的使用
        return 302 https://beta.example.com$request_uri;
    }

    # 正常用户访问
    location / {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

上面的随机逻辑是简化版，生产环境不推荐用 Nginx 内置 if 做复杂逻辑。推荐使用：

Nginx + Lua（OpenResty）
后端 Java 服务做 A/B 分流（更灵活）

更优方案：Java 后端控制 302 重定向

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import javax.servlet.http.HttpServletResponse;
import java.util.Random;
@RestController
public class RedirectController {
    private final Random random = new Random();
    @GetMapping("/home")
    public void home(HttpServletResponse response) throws Exception {
        // 10% 概率跳转到测试页
        if (random.nextDouble() < 0.1) {
            response.sendRedirect("https://beta.example.com/home");
            return;
        }
        // 90% 用户正常渲染页面
        response.setStatus(200);
        response.setContentType("text/html");
        response.getWriter().write("<h1>🎉 欢迎访问主站！</h1>");
    }
}

优势：

可基于用户 ID、设备、地理位置、Cookie 精准控制
可记录跳转日志、监控转化率
可动态调整比例，无需重启 Nginx

场景五：多域名统一跳转（泛域名重定向）

你可能拥有多个子域名，希望全部统一到主域名，比如：

shop.example.com → example.com/shop
blog.example.com → example.com/blog
api.example.com → api.example.com（保持不变）

Nginx 配置方案

server {
    listen 80;
    server_name ~^(?<subdomain>.+)\.example\.com$;

    # 排除 api 子域名
    if ($subdomain = "api") {
        return 301 https://$host$request_uri;
    }

    # 其他子域名统一跳转到主域名路径
    return 301 https://example.com/$subdomain$request_uri;
}

server {
    listen 443 ssl http2;
    server_name ~^(?<subdomain>.+)\.example\.com$;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    if ($subdomain = "api") {
        # api 子域名正常处理
        root /var/www/api;
        try_files $uri $uri/ =404;
        return 200;
    }

    # 其他子域名重定向
    return 301 https://example.com/$subdomain$request_uri;
}

解析

~^(?<subdomain>.+)\.example\.com$：使用命名捕获组 subdomain 提取子域名
if ($subdomain = "api")：排除特定子域名
return 301 https://example.com/$subdomain$request_uri：构造新路径

常见错误与避坑指南

错误 1：循环重定向

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri; # 没问题
}

server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://example.com$request_uri; # ⚠️ 循环！
}

结果：浏览器报错 ERR_TOO_MANY_REDIRECTS

正确做法：443 端口的 server 块中不要再次重定向自己。只在 80 端口做跳转。

错误 2：忘记保留 $request_uri

return 301 https://newdomain.com; # ❌ 丢失路径！

访问 http://olddomain.com/product?id=123 → 跳转到 https://newdomain.com（丢失 /product?id=123）

正确：

return 301 https://newdomain.com$request_uri;

错误 3：使用 rewrite 代替 return

rewrite ^(.*)$ https://new.com$1 redirect; # ✅ 能工作，但不推荐

虽然功能相同，但：

rewrite 需要正则引擎解析
return 是 Nginx 内置快速响应
return 更安全，不会被后续 location 模块干扰

❌

location /old {
    return 301 /new; # ❌ 这里是相对路径，可能出错
}

应该使用绝对路径：

location /old {
    return 301 https://$host/new;
}

高级技巧：基于用户 Agent、IP、Cookie 的智能重定向

场景：移动端用户跳转到 M 站

server {
    listen 80;
    server_name example.com;

    # 如果是移动设备，跳转到 m.example.com
    if ($http_user_agent ~* "(android|iphone|ipod|blackberry|windows phone)") {
        return 302 https://m.example.com$request_uri;
    }

    # 其他情况正常访问
    location / {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

场景：根据 Cookie 控制 A/B 测试

map $http_cookie $redirect_flag {
    default 0;
    "~*ab_test=1" 1;
}

server {
    listen 80;
    server_name example.com;

    if ($redirect_flag = "1") {
        return 302 https://ab-test.example.com$request_uri;
    }

    location / {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

该配置依赖 map 指令，需在 http 块中定义：

http {
    map $http_cookie $redirect_flag {
        default 0;
        "~*ab_test=1" 1;
    }

    # ... 其他配置
}

Java + Nginx 联动：动态设置 Cookie

@GetMapping("/start-ab-test")
public ResponseEntity<String> startAbTest(HttpServletResponse response) {
    Cookie cookie = new Cookie("ab_test", "1");
    cookie.setMaxAge(3600); // 1小时
    cookie.setPath("/");
    response.addCookie(cookie);
    return ResponseEntity.ok("🎉 A/B 测试已启用，下次访问将跳转至测试页");
}

优点：用户主动选择加入测试，比 Nginx 随机分配更可控。

性能对比：return vs rewrite vs proxy_pass

方法	性能	适用场景	是否推荐
`return 301`	⭐⭐⭐⭐⭐ 最高	简单跳转、域名/路径重定向	✅ 强烈推荐
`rewrite ... redirect`	⭐⭐⭐⭐	需要正则匹配路径	✅ 可用，但非首选
`proxy_pass`	⭐⭐⭐	反向代理内部服务	✅ 用于转发，非重定向
`error_page 404 =301 ...`	⭐⭐	特殊错误页面跳转	⚠️ 特殊场景使用

性能测试数据（Nginx 官方基准）：return 每秒可处理 80,000+ 请求，rewrite 约 50,000+，差距显著。

实战：完整 Nginx 配置模板（生产可用）

# 全局配置
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    # A/B 测试 Cookie 映射
    map $http_cookie $ab_test {
        default 0;
        "~*ab_test=enabled" 1;
    }

    # 日志格式
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    # === 主站配置 ===
    server {
        listen 80;
        server_name example.com www.example.com;

        # 强制 HTTPS
        return 301 https://www.example.com$request_uri;
    }

    server {
        listen 443 ssl http2;
        server_name example.com;

        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        # 永久重定向：非 www → www
        return 301 https://www.example.com$request_uri;
    }

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

        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        # 旧产品路径重定向
        location ~ ^/products/(\d+)$ {
            return 301 /shop/item/$1;
        }

        # 旧博客路径
        location = /blog/legacy {
            return 301 /blog/archive;
        }

        # A/B 测试：有 cookie 的用户跳转
        if ($ab_test = "1") {
            return 302 https://ab-test.example.com$request_uri;
        }

        # 移动端跳转
        if ($http_user_agent ~* "(android|iphone)") {
            return 302 https://m.example.com$request_uri;
        }

        # 默认处理
        root /var/www/html;
        index index.html index.php;
        location / {
            try_files $uri $uri/ =404;
        }

        # API 路径
        location /api/ {
            proxy_pass http://localhost:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }

    # A/B 测试站点
    server {
        listen 443 ssl http2;
        server_name ab-test.example.com;

        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        root /var/www/ab-test;
        index index.html;

        location / {
            try_files $uri $uri/ =404;
        }
    }

    # 移动端站点
    server {
        listen 443 ssl http2;
        server_name m.example.com;

        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        root /var/www/mobile;
        index index.html;

        location / {
            try_files $uri $uri/ =404;
        }
    }
}

此配置已包含：

HTTPS 强制跳转
域名统一（www）
路径重定向
A/B 测试
移动端适配
API 反向代理

Java 服务如何配合 Nginx 重定向？

有时候，重定向逻辑不能完全交给 Nginx，需要后端动态决策。例如：

用户未登录 → 跳转到登录页
用户地域不同 → 跳转到本地化站点
会员等级不同 → 跳转到专属页面

Java Spring Boot 示例

import org.springframework.web.bind.annotation.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@RestController
@RequestMapping("/user")
public class UserController {
    @GetMapping("/profile")
    public void userProfile(HttpServletRequest request, HttpServletResponse response) throws IOException {
        String userAgent = request.getHeader("User-Agent");
        String ip = request.getRemoteAddr();
        // 1. 移动端用户重定向到 M 站
        if (userAgent != null && (userAgent.contains("Mobile") || userAgent.contains("Android"))) {
            response.sendRedirect("https://m.example.com/profile");
            return;
        }
        // 2. 国内用户跳转到中文站
        if (ip.startsWith("114.") || ip.startsWith("115.")) {
            response.sendRedirect("https://zh.example.com/profile");
            return;
        }
        // 3. 未登录用户跳转登录页
        if (request.getSession().getAttribute("userId") == null) {
            response.sendRedirect("https://example.com/login?redirect=/user/profile");
            return;
        }
        // 4. 正常用户返回内容
        response.setStatus(200);
        response.setContentType("application/json");
        response.getWriter().write("{\"status\":\"success\",\"message\":\"Welcome!\"}");
    }
}

为什么不用 Nginx？

Nginx 无法读取用户 Session
Nginx 无法访问数据库判断用户权限
Nginx 无法动态生成跳转 URL（如带 token 的链接）

最佳实践：Nginx 做静态、全局、高性能重定向；Java 做动态、用户相关、业务逻辑重定向

SEO 与搜索引擎优化建议

301 是 SEO 的黄金标准

Google、Bing、百度都会将原 URL 的“链接权重”（Link Equity）传递给目标 URL
使用 301 可避免“内容重复”惩罚
旧链接在搜索引擎中仍可被索引，但指向新地址

302 的 SEO 风险

搜索引擎认为“内容仍在原地址”，不会更新索引
若长期使用 302，可能被判定为“作弊”或“隐藏跳转”
百度对 302 的处理比 Google 更保守

建议

场景	推荐状态码
网站迁移、域名变更	✅ 301
网站维护、临时下线	✅ 302
A/B 测试、灰度发布	✅ 302
移动端适配	✅ 302（用户可切换）
HTTPS 强制跳转	✅ 301

安全与监控建议

1. 记录重定向日志

在 Nginx 中开启详细日志：

log_format redirect_log '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent" '
                        '-> $http_host -> $upstream_http_location';

access_log /var/log/nginx/redirects.log redirect_log;

2. 避免开放重定向漏洞（Open Redirect）

攻击者可能构造恶意链接：

https://your-site.com/redirect?url=https://malicious.com

如果你的 Java 服务有类似代码：

response.sendRedirect(request.getParameter("url")); // ⚠️ 危险！

修复方案：

String target = request.getParameter("url");
if (target != null && target.startsWith("https://your-domain.com")) {
    response.sendRedirect(target);
} else {
    response.sendRedirect("https://your-domain.com/home"); // 默认安全页
}

3. 使用 HSTS 强化 HTTPS

在 Nginx 中添加：

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

作用：浏览器记住“此域名必须用 HTTPS”，即使用户输入 http:// 也会自动升级。

性能监控与压测工具推荐

工具	用途
`curl -I http://example.com`	查看响应头，确认 301/302
`ab` (Apache Bench)	基础压测：`ab -n 1000 -c 10 http://example.com/`
`wrk`	高性能压测工具，支持 Lua 脚本
`Postman`	手动测试重定向链
`Lighthouse` (Chrome DevTools)	检查重定向次数（建议 ≤ 1 次）
`Screaming Frog SEO Spider`	批量抓取站点，检测重定向链

建议：重定向链越短越好！A → B → C → D 会降低用户体验和 SEO 效果。

总结：何时用 301？何时用 302？

维度	301 Moved Permanently	302 Found
语义	永久迁移	临时跳转
SEO	传递权重	不传递权重
浏览器缓存	缓存重定向	不缓存
适用场景	网站迁移、域名变更、HTTPS 强制	A/B 测试、维护页、移动端适配
性能	更高（Nginx 内置）	稍低（但可忽略）
推荐度	✅ 强烈推荐	✅ 仅限临时场景

一句话口诀：“永久改地址，用 301；临时躲一躲，用 302。”

最终建议：构建你的重定向策略清单

所有 HTTP 流量 → 301 跳转 HTTPS
非 www → www（或反之）统一域名
旧路径 → 新路径 301（保留 SEO）
移动端、地域、设备适配 → 302
A/B 测试、灰度发布 → 302 + Cookie 控制
避免多重重定向（链长 ≤ 1）
Java 服务处理动态业务逻辑重定向
开启 HSTS 和重定向日志监控
定期用 Lighthouse 检查重定向链
不要滥用 rewrite，优先用 return

结语：重定向不是小事，它是用户体验的隐形桥梁

你可能从未注意过，当你在浏览器输入 http://example.com，一秒内浏览器就无声无息地跳转到了 https://www.example.com。这个过程，就是 Nginx 和 HTTP 协议在默默守护你的网站。

301 和 302，看似简单，实则影响着：

用户的访问速度
搜索引擎的排名
安全性与合规性
商业转化率（A/B 测试）
系统可维护性

掌握它们，你就掌握了 Web 架构中最优雅、最高效的一环。真正的工程师，不是写代码的人，是让系统无声运转的人。

下次当你配置一条 return 301，请记住：你不是在改一行配置，你是在为千万用户铺一条通往安全、高效、可信赖世界的路。

附录：快速参考速查表

目标	Nginx 配置
HTTP → HTTPS	`return 301 https://$host$request_uri;`
example.com → www.example.com	`return 301 https://www.example.com$request_uri;`
/old → /new	`location = /old { return 301 /new; }`
/products/123 → /item/123	`location ~ ^/products/(\d+)$ { return 301 /item/$1; }`
移动端跳转	`if ($http_user_agent ~* "(android
A/B 测试	`map $http_cookie $ab_test { default 0; "~*ab_test=1" 1; }` + `if ($ab_test = "1") { return 302 ... }`
禁止循环	确保 443 端口不再重定向自己
验证跳转	`curl -I http://example.com` 查看 `Location` 头

记住：最好的重定向，是用户根本感觉不到它存在。

你配置的每一行 Nginx，都在为这个世界减少一次点击，节省一秒等待。

以上就是Nginx中301与302重定向的配置指南的详细内容，更多关于Nginx重定向的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

Nginx配置https的实现
本文主要介绍了Nginx配置https的实现，文中通过示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
2021-11-11
Nginx 站点垂直扩容的几种优化方案
本文主要介绍了Nginx 站点垂直扩容的几种优化方案,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
2026-01-01
Nginx高可用Keepalived的具体使用
Keepalived是一种实现高可用的软件,基于VRRP协议,可以自动将虚拟IP地址切换到备用服务器,具有一定的参考价值,感兴趣的可以了解一下
2024-12-12
Nginx跨域访问场景配置和防盗链详解
这篇文章主要介绍了Nginx跨域访问场景配置和防盗链详解,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
2019-07-07
Nginx中的文件下载服务器详解
利用Nginx的诸多内置指令可实现自动生成下载文件列表页、限制下载带宽等功能,这篇文章给大家介绍Nginx中的文件下载服务器功能,感兴趣的朋友一起看看吧
2024-06-06
在Docker中实现Nginx平滑重启的几种方法
关于平滑重启的意思,就是指已经连接到nginx的请求将继续使用旧的配置,待客户端服务完成后,旧的工作进程将关闭,下次请求将采用新的配置,本文给大家介绍了在Docker中实现Nginx平滑重启的几种方法,需要的朋友可以参考下
2025-09-09
详解Nginx配置WebSocket(支持wss与ws连接)
本文主要介绍了详解Nginx配置WebSocket(支持wss与ws连接),文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
2025-09-09
使用Centos配置web proxy(nginx代理)
本文介绍了如何在Webproxy上安装和配置Nginx,主要内容包括安装Nginx、配置SSL证书、创建proxy配置文件、设置缓存记录真实客户端IP、重启Nginx、创建数据库、测试缓存和配置监控脚本
2025-12-12
Nginx配置SSL和WSS步骤介绍
大家好，本篇文章主要讲的是Nginx配置SSL和WSS步骤介绍，感兴趣的同学赶快来看一看吧，对你有帮助的话记得收藏一下，方便下次浏览
2021-12-12
Nginx配置为HTTPS的完整步骤(支持 SSL/TLS 加密)
Nginx是一个高性能的HTTP和反向代理web服务器,是运维中十分常用的中间件,HTTPS协议简单来说就是HTTP协议和SSL/TLS协议的组合,这篇文章主要介绍了Nginx配置为HTTPS(支持 SSL/TLS 加密)的相关资料,需要的朋友可以参考下
2025-11-11

Nginx中301与302重定向的配置指南

目录

什么是 HTTP 重定向？

Nginx 中配置 301 与 302 重定向的语法

推荐方式：return 301/302

不推荐方式：rewrite ... redirect

场景一：域名跳转 —— 从 HTTP 到 HTTPS

场景描述

Nginx 配置方案

关键参数解析

Java 客户端测试示例

场景二：域名跳转 —— 从非 www 到 www（或反之）

场景描述

Nginx 配置方案

为什么这样配置？

场景三：路径重定向 —— 旧链接迁移

场景描述

Nginx 配置方案

正则表达式说明

Java 测试代码：验证路径重定向

场景四：临时维护页（302）与灰度发布

场景描述

Nginx 配置方案

更优方案：Java 后端控制 302 重定向

场景五：多域名统一跳转（泛域名重定向）

Nginx 配置方案

解析

常见错误与避坑指南

错误 1：循环重定向

错误 2：忘记保留 $request_uri

错误 3：使用 rewrite 代替 return

❌

高级技巧：基于用户 Agent、IP、Cookie 的智能重定向

场景：移动端用户跳转到 M 站

场景：根据 Cookie 控制 A/B 测试

Java + Nginx 联动：动态设置 Cookie

性能对比：return vs rewrite vs proxy_pass

实战：完整 Nginx 配置模板（生产可用）

Java 服务如何配合 Nginx 重定向？

Java Spring Boot 示例

为什么不用 Nginx？

SEO 与搜索引擎优化建议

301 是 SEO 的黄金标准

302 的 SEO 风险

建议

安全与监控建议

1. 记录重定向日志

2. 避免开放重定向漏洞（Open Redirect）

3. 使用 HSTS 强化 HTTPS

性能监控与压测工具推荐

总结：何时用 301？何时用 302？

最终建议：构建你的重定向策略清单

结语：重定向不是小事，它是用户体验的隐形桥梁

附录：快速参考速查表

相关文章

最新评论

大家感兴趣的内容

最近更新的内容

常用在线小工具