Nginx 四层 TCP 与七层 HTTP 转发实战指南

本文档主要介绍 Nginx 中四层 TCP 转发 和七层 HTTP 转发的核心区别、配置示例、适用场景及选型建议，基于实际业务配置案例总结，适用于运维人员、开发人员在 Nginx 代理配置时参考，帮助快速选择符合业务需求的转发模式。

一、核心概念基础

Nginx 作为高性能的代理服务器，支持基于TCP/IP 网络模型不同层级 的转发能力，核心分为四层 TCP 转发和七层 HTTP 转发，两者的本质差异在于工作层级 和协议解析能力：

1. 四层 TCP 转发 ：工作在传输层（TCP/UDP） ，仅解析网络报文的 IP、端口信息，不深入应用层协议内容，属于纯报文转发；
2. 七层 HTTP 转发 ：工作在应用层（HTTP/HTTPS/WebSocket），可完整解析 HTTP 协议的请求头、查询参数、URL 路径、Cookie 等内容，支持基于应用层信息的复杂转发控制。

二、四层 TCP 转发详解

2.1 核心原理

基于 Nginx 的stream核心模块实现，仅对 TCP/UDP 协议的报文进行转发，不解析应用层数据（如 HTTP、HTTPS 内容）。针对 HTTPS 转发场景，可通过ssl_preread on指令解析 SSL/TLS 握手阶段的 SNI（服务器名称指示）信息，实现基于域名的 TCP 转发，无需配置 SSL 证书，直接透传加密报文到后端。

2.2 完整配置示例

nginx

# 四层TCP转发核心配置，需写在http块同级，不可嵌套在http内
stream {
    # 定义后端上游服务池，支持多实例负载均衡/高可用
    upstream ndp_backend {
        server 1.1.1.1:443;
        server 2.2.2.2:443;
    }

    upstream jira_backend {
        server jira.xxx.net.ctacdn.cn:443;
    }

    # 基于SNI域名映射后端服务池
    map $ssl_preread_server_name $backend_server {
        ndp.xxx.ai      ndp_backend;  # 域名1映射对应上游
        jira.xxx.net    jira_backend; # 域名2映射对应上游
        default         "";           # 默认无匹配，拒绝转发
    }

    # 监听443端口，处理TCP转发请求
    server {
        listen 443;                  # 监听TCP 443端口
        ssl_preread on;              # 启用SNI域名解析，必须配置
        proxy_pass $backend_server;  # 转发到映射的后端服务池
        proxy_connect_timeout 15s;   # 与后端建立连接超时时间
        proxy_timeout 3600s;         # 转发会话超时时间
        tcp_nodelay on;              # 禁用Nagle算法，提升实时性
    }
}

2.3 关键特性

1. 配置简洁，无需关注应用层协议细节；
2. HTTPS 转发无需配置 SSL 证书，避免证书重复部署；
3. 转发性能高，仅做 TCP 报文透传，无应用层解析开销；
4. 支持基于 SNI 域名、端口的简单转发规则，不支持 URL、参数等细粒度控制；
5. 纯报文转发，无应用层处理能力，不支持缓存、Rewrite、请求头修改等操作。

2.4 适用场景

1. 纯 TCP/UDP 协议转发场景（如 HTTPS、MySQL、Redis、SSH 等）；
2. HTTPS 转发需求，希望避免在 Nginx 端配置证书，直接透传加密流量；
3. 追求极致转发性能，无复杂应用层处理需求；
4. 简单的多域名 / 多端口负载均衡，无需细粒度路由控制；
5. 多后端服务的高可用容灾，仅需基础的流量转发。

三、七层 HTTP 转发详解

3.1 核心原理

基于 Nginx 的http/core核心模块实现，工作在应用层，可完整解析 HTTP/HTTPS 协议的所有内容（包括 URL 路径、查询参数、请求头、Cookie、请求体等）。针对 HTTPS 场景，需在 Nginx 端配置 SSL 证书完成解密，再对明文 HTTP 请求进行处理和转发，支持基于应用层信息的精细化转发控制和业务处理。

3.2 完整配置示例

nginx

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

    # 七层HTTP转发核心配置，基于server/location块实现
    server {
        listen       80;        # 监听HTTP 80端口
        server_name  _;         # 匹配所有域名/IP请求

        # 基于URL路径的转发控制，可配置多个location实现不同路由规则
        location / {
            # 应用层变量初始化，处理查询参数/Cookie
            set $arg_port $arg_port;
            set $cookie_proxy_port $cookie_proxy_port;
            
            # 基于查询参数的业务处理：存入Cookie
            if ($arg_port != "") {
                add_header Set-Cookie "proxy_port=$arg_port; Path=/; HttpOnly; SameSite=Lax; Max-Age=86400" always;
            }

            # 转发到后端上游服务
            proxy_pass  http://10.10.10.10:8090;
            # 应用层请求头修改，透传客户端真实IP
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            proxy_set_header Connection "";
            # WebSocket协议升级支持（应用层协议扩展）
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

            # 超时配置
            proxy_connect_timeout 15s;
            proxy_send_timeout 3600s;
            proxy_read_timeout 3600s;
            tcp_nodelay on;
        }

        # 日志配置，记录应用层请求详情
        access_log  logs/access.log;
        error_log   logs/error.log warn;
    }
}

3.3 关键特性

1. 工作在应用层，可完整解析 HTTP 协议所有内容，支持精细化转发控制；
2. 支持基于 URL 路径、查询参数、Cookie、请求头的个性化转发规则（多 location 块）；
3. 丰富的应用层处理能力：Rewrite 重写、请求头 / 响应头修改、Cookie 处理、变量运算等；
4. 支持 HTTP 缓存、静态资源缓存、反向代理缓存，提升业务访问性能；
5. 支持 WebSocket、HTTP/2 等协议升级和扩展，适配现代 Web 业务；
6. 可记录详细的应用层访问日志，便于问题排查和业务统计；
7. HTTPS 转发需在 Nginx 端配置 SSL 证书，解密后再处理转发。

3.4 适用场景

1. HTTP/HTTPS/WebSocket 协议的 Web 业务转发（如前端页面、接口服务、微服务等）；
2. 复杂的转发规则需求：如不同 URL 路径映射不同后端、基于参数 / Cookie 的个性化转发；
3. 需要应用层处理能力：如 Rewrite 重写 URL、修改请求头 / 响应头、Cookie 管理、鉴权校验等；
4. 希望通过 Nginx 实现缓存功能，减轻后端服务压力（如静态资源缓存、接口结果缓存）；
5. 需要透传客户端真实 IP、实现基于域名的虚拟主机配置；
6. 微服务架构下的 API 网关层，需做请求转发、协议转换、流量控制等；
7. 需对 HTTP 请求做精细化日志记录、监控统计的场景。

四、四层 TCP 与七层 HTTP 转发核心差异对比表

对比维度	四层 TCP 转发	七层 HTTP 转发
工作网络层级	传输层（TCP/UDP）	应用层（HTTP/HTTPS/WebSocket）
核心依赖模块	stream	http/core
协议解析能力	仅解析 IP、端口，不解析应用层内容	完整解析 HTTP 协议（URL、参数、头、Cookie 等）
HTTPS 处理方式	无需配置证书，ssl_preread 解析 SNI 后透传加密流量	需配置证书解密，处理明文 HTTP 后转发
转发控制粒度	基于端口、SNI 域名的粗粒度控制	基于 URL、参数、Cookie、请求头的细粒度控制
应用层处理能力	无，纯报文转发	支持 Rewrite、头修改、Cookie 处理、鉴权等
缓存能力	不支持	支持静态资源、反向代理缓存
性能表现	性能高，无解析开销	性能略低，存在应用层解析开销
典型配置单元	stream 块、upstream 块、server 块	http 块、server 块、location 块
协议支持范围	支持所有 TCP/UDP 协议（HTTP、MySQL、Redis 等）	主要支持 HTTP/HTTPS/WebSocket 及相关扩展协议
日志记录能力	仅记录 TCP 连接日志，无应用层详情	可记录完整 HTTP 请求日志（URL、参数、状态码等）

五、选型建议

5.1 优先选择四层 TCP 转发的场景

1. 非 HTTP 协议的 TCP/UDP 转发（如 MySQL、Redis、SSH、FTP 等）；
2. HTTPS 转发需求，希望简化 Nginx 配置，避免证书部署和维护；
3. 追求极致的转发性能，业务无任何应用层处理需求；
4. 仅需基础的负载均衡 / 高可用，无需细粒度的路由和转发控制；
5. 多后端服务的流量透传，Nginx 仅做 "转发通道"，业务逻辑由后端统一处理。

5.2 优先选择七层 HTTP 转发的场景

1. 纯 HTTP/HTTPS/WebSocket 的 Web 业务、微服务、API 接口转发；
2. 业务需要基于 URL、参数、Cookie 实现个性化的转发规则；
3. 需通过 Nginx 实现 Rewrite、请求头修改、Cookie 管理等应用层操作；
4. 希望利用 Nginx 的缓存能力减轻后端压力，提升业务访问速度；
5. 需透传客户端真实 IP、实现虚拟主机、做精细化日志记录；
6. 微服务架构中的 API 网关，需完成请求转发、协议转换、流量控制、鉴权等功能；
7. 需对 HTTP 请求做监控、统计、限流的场景。

5.3 混合使用建议

实际生产环境中，可结合两者优势混合使用：

1. 前端通过四层 TCP 转发做 HTTPS 流量透传（免证书），实现多域名的粗粒度转发；
2. 后端通过七层 HTTP 转发处理明文 HTTP 请求，实现细粒度的路由、缓存、应用层处理；
3. 数据库 / 中间件服务用四层 TCP 转发 做高可用负载均衡，Web 服务用七层 HTTP 转发做精细化控制。

六、总结

1. 四层 TCP 转发的核心优势是配置简单、性能高、协议支持广，适合纯流量透传和简单负载均衡，短板是无应用层处理能力；
2. 七层 HTTP 转发的核心优势是解析能力强、功能丰富、控制精细，适合 Web 业务的复杂转发和处理，短板是配置相对复杂、HTTPS 需配置证书、性能略低；
3. 两者的选型核心是基于业务协议类型和处理需求：非 HTTP 协议、纯透传、追求性能选四层；HTTP 协议、需要应用层处理、精细化控制选七层；
4. Nginx 同时支持四层和七层转发，可根据业务架构灵活搭配，最大化发挥其高性能代理的优势。