负载均衡常被分成四层和七层，这个说法来自OSI参考模型。四层工作在传输层，只看IP地址和端口；七层工作在应用层，能解析HTTP、HTTPS这类应用协议。两者名称差不多，但转发行为、能做的事、性能开销和排障方式差别很大。如果一开始没有想清楚该用哪种监听或代理，上线后很容易遇到后端拿不到真实客户端IP、健康检查误判、会话保持失效、证书配置混乱等问题。把四层与七层的边界、选型思路和常见坑点一次性说清楚，可以避免很多不必要的返工。

一、四层与七层的核心区别在哪里

负载均衡所谓的四层和七层，本质是它在TCP/IP协议栈中的工作位置。四层对应传输层，核心处理对象是TCP和UDP报文。四层负载均衡设备或软件在收到客户端连接请求后，只会解析源IP、目的IP、源端口、目的端口，然后根据预设策略从后端服务器列表中选择一台，把报文转发过去。它不会查看HTTP请求行、请求头或任何应用层内容，所以也常被称为基于连接的负载均衡。

七层对应应用层，代表性协议是HTTP、HTTPS、HTTP/2、gRPC等。七层负载均衡必须先与客户端完整建立TCP连接，读取并解析HTTP请求内容，再根据URL路径、Host头、User-Agent、Cookie、HTTP方法等字段决定转发给哪个后端。它还可以在转发前修改请求头、压缩响应、返回静态内容或直接拒绝请求。由于能感知业务语义，七层负载均衡在Web架构中承担的角色更接近反向代理或网关。

打个比方，四层像快递分拣中心只看包裹外箱上的收件地址和电话，不拆箱；七层则像拆开包裹检查里面的订单详情，再决定派给哪个仓库处理。这个差异直接决定了性能开销和功能边界，也决定了后续健康检查、会话保持、SSL处理等设计方式。

二、选型怎么做：依据场景和架构需求判断

如果流量是MySQL、Redis、PostgreSQL、MQTT、RDP等非HTTP协议，四层负载均衡几乎是唯一选择，因为七层解析不了这些协议。即便流量是HTTP，也需要看具体目标。只想做TCP连接级分发、追求更高吞吐和更低延迟时，四层更合适。四层不解析业务报文，CPU消耗低，在相同硬件配置下通常能支撑更高连接数和转发速率，适合做入口层的大流量分发。

七层则适合需要按内容路由的场景，例如把/api/开头的请求转发到应用集群，把/static/开头的请求交给静态资源服务器，或者按Cookie中的灰度标识把用户导向新版本。七层还能集中处理SSL证书、WAF防护、限流熔断、请求重写、跨域头注入等中间件逻辑。如果系统采用微服务或前后端分离架构，七层负载均衡基本是必备能力。

实际生产环境经常采用混合结构：外层用四层负载均衡做高性能入口，把流量均匀交给后方的多个七层网关；七层网关再根据业务规则分发到具体服务。这样既能扛住突发连接，又能保留细粒度控制。云服务里常见的做法是四层NLB加七层ALB，或者自建LVS/Keepalived加Nginx/OpenResty组合。

下面这段Nginx配置展示七层HTTP负载均衡如何按路径转发：

http {
    upstream app_backend {
        server 10.0.0.11:8080 weight=3;
        server 10.0.0.12:8080 weight=1;
    }
    server {
        listen 80;
        server_name www.ipipp.com;
        location /api/ {
            proxy_pass http://app_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_connect_timeout 3s;
            proxy_read_timeout 30s;
        }
        location /health {
            return 200 "ok";
        }
    }
}

四层TCP转发的Nginx stream配置则简单很多，它不关心HTTP路径，只按IP和端口转发：

stream {
    upstream mysql_backend {
        server 192.168.1.10:3306 max_fails=2 fail_timeout=10s;
        server 192.168.1.11:3306 backup;
    }
    server {
        listen 3306;
        proxy_pass mysql_backend;
        proxy_connect_timeout 5s;
        proxy_timeout 60s;
    }
}

从配置可以看出，七层配置包含HTTP语义、路径匹配和请求头修改，而四层只关注连接和超时参数。如果需求只涉及TCP端口转发，四层更简单；如果需求涉及URL分流、Header改写或SSL卸载，必须上七层。

三、避坑建议：健康检查、真实IP、会话保持与SSL

第一个容易出错的地方是健康检查。四层健康检查通常只探测端口是否可连通，比如TCP三次握手成功就认为后端正常。但应用进程可能已经卡死，端口仍由操作系统监听，此时四层健康检查无法发现问题。对HTTP服务应优先使用七层健康检查，配置一个独立路径例如/healthz，让负载均衡检查响应状态码是否200。健康检查路径不要依赖数据库、Redis等外部资源，否则可能因为依赖抖动导致整批后端被摘除。

第二个坑是后端拿不到客户端真实IP。四层负载均衡若采用NAT模式会替换源地址，后端看到的是负载均衡器IP；七层如果不主动设置X-Real-IP和X-Forwarded-For，后端同样只能拿到代理IP。日志分析、风控和限流都会受影响。设置X-Forwarded-For后，还要确保后端框架信任该头，否则攻击者可以伪造。更严谨的方案是在可信代理链上覆盖该头，而不是直接拼接用户传入的值。

第三个坑是会话保持。四层负载均衡常用源IP哈希，但客户端经过NAT或代理后源IP相同，可能造成流量倾斜；七层则可以使用Cookie植入或Cookie关键字做会话保持，对用户粒度更准。不过在使用Cookie保持时，要提前确认后端应用是否依赖会话共享，如果会话只存在单机内存，某个后端宕机会导致用户登录态丢失。WebSocket、HTTP/2长连接需要七层监听开启相应支持，并调长读写超时，否则连接会被空闲策略误断。

SSL证书处理也需要提前规划。四层做SSL透传时证书部署在后端，七层做SSL卸载时证书集中在负载均衡器。集中管理证书方便续期，但负载均衡器会看到明文流量，安全边界要清楚。如果多个域名共用七层监听，需要启用SNI并配置多证书，避免证书不匹配告警。最后，七层负载均衡不是越重越好，路径正则、Body检查、大响应缓存等都会显著增加CPU与内存消耗，上线前最好用实际流量压测，观察P99延迟和错误率。