四层与七层的本质差别
四层负载均衡只转发 TCP 或 UDP 连接，不改动载荷，性能高但看不到 HTTP 语义；七层负载均衡理解 HTTP，可以按路径、头部或 Cookie 路由，也能改写头部、做缓冲与鉴权。这个差别直接决定了几件事：后端看到的源地址是谁、超时发生在哪一层、日志里能记录什么、健康检查能查多深。排查前先确认手上是哪一层，否则会用错误的前提去找原因。
基本信息
| 四层 | TCP/UDP 透传，性能高，无 HTTP 语义；源地址取决于转发模式 |
|---|---|
| 七层 | 可路由、可改写、可鉴权；引入转发头、超时与缓冲策略 |
| 会话保持 | 四层按源地址或五元组，七层按 Cookie 或头部 |
| 健康检查 | 四层只查端口，七层可查具体 URL 与期望状态码 |
| 常见实现 | 云厂商的四层与七层监听、Nginx、HAProxy、LVS 等 |
典型使用场景
- 后端日志里全是负载均衡器地址：确认是否需要透传真实源地址
- 按路径分流不生效：确认用的是七层监听而非四层
- 出现 504：区分是负载均衡器等待上游超时还是后端自己超时
- 排查会话保持失效：区分按源地址保持和按 Cookie 保持的差异
- 评估健康检查误摘：检查深度是否足够、阈值是否过敏感
典型验证
典型验证
# 后端看到的源地址是谁：
ss -tn state established '( sport = :8080 )' | head -10
# 七层是否透传真实地址：
curl -sS -H 'X-Forwarded-For: 203.0.113.9' http://10.0.0.5/header | head -5
# 对比直连后端与经负载均衡的响应差异：
curl -sS -o /dev/null -w 'direct %{http_code} %{time_total}\n' http://10.0.0.5:8080/health
curl -sS -o /dev/null -w 'slb %{http_code} %{time_total}\n' https://www.example.com/health
# 读负载均衡器访问日志里的上游耗时字段，切开两侧责任：
tail -50 /var/log/nginx/access.log | awk '{print $NF}' | sort -n | tail差异对照
| 维度 | 四层 | 七层 |
|---|---|---|
| 转发依据 | 地址与端口 | 路径、头部、Cookie |
| 源地址可见性 | 后端看到负载均衡器 | 可透传真实地址或携带转发头 |
| 超时语义 | 连接级超时 | 连接、读取与空闲多级超时 |
| 日志能力 | 只有连接级指标 | 可记录 URL、状态码与上游耗时 |
| 健康检查深度 | 端口可用性 | 业务路径与内容校验 |
四层转发时后端看到的源地址是负载均衡器：要拿到真实源地址需要七层透传，或启用代理协议标记并由后端解析，两者都必须两端配置配合才生效。