浏览器301重定向响应流程分析

浏览器在访问 HTTP 协议非 HTTPS 的站点时，通常会发生 301 重定向，那么整个请求响应流程是怎样的？接下来我们深入分析一下。

分析

首先，我们明白，这是一个 HTTP 层面的行为，底层依赖 TCP 协议进行可靠传输。

前置知识
HTTP 端口为 80，HTTPS 端口为 443 301 是 HTTP 响应状态码，表示永久重定向，即请求的资源已永久移动到新的位置。

理论分析

一、初始请求阶段

1
用户输入URL → DNS解析 → TCP三次握手 → 发送HTTP请求

用户输入 URL：用户在浏览器地址栏输入一个 URL（比如 http://example.com ）并按下回车。
DNS 解析：浏览器解析 URL 中的域名，通过 DNS 获取对应的 IP 地址。如果涉及到重定向，可能在 DNS 层面就有 CNAME 等记录。
建立 TCP 连接：浏览器根据 IP 地址和端口 (默认 80 或 443）与服务器建立 TCP 连接。这一步是 TCP 协议的工作，包括三次握手。
发送 HTTP 请求：通过已建立的 TCP 连接，浏览器发送 HTTP 请求。例如，一个 GET 请求到根路径/。

客户端请求报文示例：

1
2
GET / HTTP/1.1
Host: example.com

二、服务器响应阶段

1
服务器处理 → 判断需重定向 → 生成301响应 → 通过TCP回传

服务器处理请求：服务器收到请求后，判断是否需要重定向到新的 URL。
服务器发送一个 HTTP 响应，状态码为 301，并在响应头中包含 Location: https://example.com（假设跳转到 HTTPS)。

服务器响应示例：

1
2
3
4
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
Content-Type: text/html
Content-Length: ...

服务器是如何判断的呢？以 Nginx 为例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
server {
    listen 80;
    server_name example.com;
    
    # 对HTTP请求重定向到HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    
    ssl_certificate /path/to/cert;
    ssl_certificate_key /path/to/key;
    
    location / {
        root   html;
        index  index.html;
    }
}

三、浏览器处理阶段

1
收到301响应 → 解析新URL → (可能的新TCP连接) → 发送新请求

浏览器处理重定向：浏览器收到 301 响应后，会从响应头中读取 Location 字段，获取新的 URL，然后自动向这个新 URL 发起新的请求。注意：对于 301 状态码，浏览器通常会缓存重定向信息，下次访问原 URL 时直接跳转到新 URL，而不必再向原 URL 发送请求。
向新 URL 发起请求：浏览器使用新 URL，可能重新进行 DNS 解析（如果域名变了）、建立 TCP 新连接（如果需要），然后发送 HTTP 请求。
服务器响应新请求：服务器返回正常的 200 状态码响应和网页内容。
浏览器渲染：浏览器收到响应后，渲染页面。

如果是 HTTP 到 HTTPS 的重定向：

1
http://example.com:80 → 301 → https://example.com:443

必然会新建 TCP 连接，增加 TLS 握手。

TCP 协议层的分析

TCP 连接管理分析

sequenceDiagram
    Client->>Server: SYN (原始请求连接)
    Server->>Client: SYN-ACK
    Client->>Server: ACK + HTTP请求
    Server->>Client: 301响应
    alt 同一主机/端口
        Client->>Server: 重用连接发送新请求
    else 不同主机/端口
        Client->>Server: FIN (关闭连接)
        Client->>NewServer: 新建TCP连接
    end

另外，顺便一提，对性能的影响：

额外 RTT：每次新建 TCP 连接增加 1 个 RTT（三次握手）
TLS 成本：HTTPS 重定向增加 TLS 握手（2-3 个 RTT）

调试分析

我们可以使用工具，进行直观的分析。

使用 cURL 工具追踪

1
curl -v -L http://example.com  # -L自动跟随重定向

输出显示 TCP 连接建立、请求响应全过程。

这里以访问 baidu.com 为例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
curl -v -L http://baidu.com
* Host baidu.com:80 was resolved.
* IPv6: (none)
* IPv4: 110.242.74.102, 124.237.177.164, 111.63.65.247, 111.63.65.103
*   Trying 110.242.74.102:80...
* Established connection to baidu.com (110.242.74.102 port 80) from 192.168.68.228 port 12061 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: baidu.com
> User-Agent: curl/8.16.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Location: http://www.baidu.com/
< Date: Sat, 20 Dec 2025 10:15:39 GMT
< Content-Length: 56
< Content-Type: text/html; charset=utf-8
* Ignoring the response-body
* setting size while ignoring
< 
* Connection #0 to host baidu.com:80 left intact
* Issue another request to this URL: 'http://www.baidu.com/'
* Host www.baidu.com:80 was resolved.
* IPv6: (none)
* IPv4: 220.181.111.232, 220.181.111.1
*   Trying 220.181.111.232:80...
* Established connection to www.baidu.com (220.181.111.232 port 80) from 192.168.68.228 port 12064 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: www.baidu.com
> User-Agent: curl/8.16.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Content-Length: 2381
< Content-Type: text/html
< Pragma: no-cache
< Server: bfe
< Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
< Date: Sat, 20 Dec 2025 10:15:39 GMT
< 
<!DOCTYPE html>
<!--STATUS OK--><html> <head><meta http-equiv=content-type content=text/html;charset=utf-8><meta http-equiv=X-UA-Compatible content=IE=Edge><meta content=always name=referrer><link rel=stylesheet type=text/css href=http://s1.bdstatic.com/r/www/cache/bdorz/baidu.min.css><title>百度一下，你就知道</title> </html>
* Connection #1 to host www.baidu.com:80 left intact

Chrome DevTools 观察

Network 面板查看“状态”一列显示 HTTP 状态码，“连接 ID"字段查看 TCP 连接重用情况。

总结

通过分析 HTTP 301 重定向流程，我们进一步了解 HTTP 通信交互流程，HTTP 协议基于请求-响应模式，底层基于 TCP 协议提供可靠性的通信。理解和掌握这些机制，能帮助我们遇到问题时，能有一个清晰的解决方向。