Layer 4 vs Layer 7 Load Balancing: Choosing LVS, Nginx, and Cloud SLB

Background: Three Real-World Failure Scenes

The article opens with three production incidents that illustrate the cost of misplacing load-balancing functions:

Scene 1 – LVS DR mode misconfiguration: After adding LVS DR in front of Nginx, ~50% of requests timed out. Backend Nginx responded directly to clients (bypassing LVS on return path), but the backend lo interface lacked the VIP and arp_ignore / arp_announce were not set. The backend ARP-announced the VIP, causing the switch to send VIP traffic to a backend instead of LVS. ipvsadm health checks only test port reachability, not ARP-layer correctness.

Scene 2 – Nginx Layer 7 CPS bottleneck: An API gateway handled 8k QPS normally; during a promotion QPS rose to 20k. Nginx CPU was only 40%, but clients saw connection timeouts. ss -s showed ~30k TIME_WAIT sockets; nstat revealed rapid growth of TcpExtListenOverflows. Root cause: clients used short connections (no keep-alive), so CPS ≈ QPS = 20k. The accept queue and port space were exhausted. The fix is architectural: move new-connection handling to Layer 4 (LVS or cloud NLB), where CPS cost is far lower.

Scene 3 – Cloud SLB health-check misalignment: A cloud CLB Layer 7 listener used HEAD /health probes, but the backend Nginx location = /health only allowed GET, returning 405. SLB treated 405 as unhealthy and removed two of three backends. Health-check path, method, and expected status code must exactly match the backend implementation.

These scenes share a common lesson: selection is not about "which is stronger" but about "which layer should do which job".

Core Concept: Where Does the Client TCP Connection Terminate?

All load balancer differences reduce to one question: Where does the client's TCP connection terminate?

Non-terminating (packet forwarding): LVS DR/TUN/NAT, cloud NLB, Nginx stream. The LB rewrites only MAC/IP headers; client and server share a single TCP connection. Pros: extreme speed, low resource use, protocol-agnostic. Cons: no visibility into URL, headers, cookies; cannot do path-based routing, rewriting, or TLS offload (except SNI sniffing at Layer 4).

Terminating (proxying): Nginx HTTP, cloud CLB Layer 7/ALB, Ingress controllers. The LB maintains two separate TCP connections (client↔LB, LB↔backend). Pros: full HTTP visibility, routing, rewriting, caching, TLS termination. Cons: consumes CPU/memory for two connection stacks; must handle backend connection pools, timeouts, real-IP propagation.

Understanding this distinction makes every subsequent comparison derivable rather than memorized.

Capability Matrix & Decision Tree

A detailed table maps requirements to the required layer:

URL/Header/Cookie routing → Layer 7 required

TLS offload → usually Layer 7 (Layer 4 can do SNI-based routing)

Transparent TCP proxy (MySQL, Redis) → Layer 4

Extreme CPS / million concurrent connections → Layer 4

Response compression/rewriting → Layer 7

Real client IP preservation → Layer 4 naturally preserves; Layer 7 needs X-Forwarded-For or Proxy Protocol

WebSocket long connections → both work; choose based on need for Layer 7 routing

The decision tree (Section 4.2) guides selection:

Need URL/Header/Cookie routing? → Must use Layer 7.

On cloud, want zero ops → ALB / CLB Layer 7

Need fine-grained control (rewrite, rate-limit, cache, canary) → Nginx

Already on Kubernetes → Ingress Controller (underlying Nginx/Traefik/Envoy)

No Layer 7 routing needed → Layer 4 suffices.

CPS or concurrency exceeds Nginx capacity (>50k CPS or >100k concurrent) → Cloud NLB or self-hosted LVS DR + keepalived

Need non-HTTP protocol pass-through → If TLS offload/SNI routing needed → Nginx stream; else pure pass-through → LVS / NLB

Scale modest (<10k CPS) → Nginx Layer 7 alone is enough; don't prematurely add LVS

Five Reference Architectures

Small monolith (DAU <100k): DNS → Nginx (2 nodes, Keepalived VIP) → App (3-5 nodes). Nginx does Layer 7 routing + TLS. No LVS needed.

Medium-large self-hosted (CPS >30k): DNS → LVS DR (2 nodes, keepalived) → Nginx (4-8 nodes) → App. LVS handles CPS; Nginx handles Layer 7 logic.

Standard cloud: DNS → Cloud SLB (Layer 4 or 7) → ECS/K8s NodePort → Pod. Do not self-host LVS in cloud; VPC/security-group/ARP proxy make DR behavior unpredictable.

Kubernetes ingress: DNS → Cloud SLB (Layer 4) → Ingress Controller (NodePort/LoadBalancer) → Service → Pod. Avoid Service type=LoadBalancer per service (creates many SLB instances); prefer one Ingress + one SLB.

Multi-cloud/hybrid active-active: DNS/GSLB (geo-routing) → Per-datacenter SLB/LVS → Local Nginx → App. Do not do cross-datacenter Layer 4 forwarding; latency and failure domains are uncontrollable.

When to Add a Layer

Signals that the current layer is insufficient:

Layer 7 overwhelmed: CPS nearing 30-50k per node with rising TcpExtListenOverflows; TIME_WAIT >20k and port exhaustion; Nginx CPU high in system ( sy) and softirq ( si); connections approaching worker_connections × worker_processes.

Layer 4 insufficient: Need URL-based canary but only have Layer 4; need HTTP status-code routing; need header rewriting for real IP (Layer 4 can only use Proxy Protocol).

Cloud SLB insufficient: Need custom health-check logic (e.g., JSON field check); complex rewrite rules; rate limiting beyond cloud SLB capabilities; spec limits hit and cannot upgrade.

Adding a layer is not an "upgrade" but a "gap fill": missing Layer 7 → add Layer 7; missing Layer 4 performance → add Layer 4. No single component does everything.

Hands-On: LVS DR + Keepalived

Environment & Pre-checks

OS: Rocky Linux 9.4 (kernel 5.14). Topology: same Layer 2 network (DR requirement). Directors: 10.20.0.11/12 (primary/backup), VIP 10.20.0.100. Real Servers: 10.20.1.11/12/13:80. Gateway: 10.20.0.1.

Pre-checks: verify ip_vs module loaded ( lsmod | grep ip_vs), ipvsadm installed, both directors in same L2 ( ip route get 10.20.1.11 shows dev eth0), VIP free ( arping -D -I eth0 -c 3 10.20.0.100 no reply), firewall allows VRRP (protocol 112) and business ports.

Real Server Configuration (Critical for DR)

ARP suppression: Set net.ipv4.conf.all.arp_ignore=1, net.ipv4.conf.all.arp_announce=2 (and per-interface) via /etc/sysctl.d/99-lvs-rs.conf; run sysctl --system. Purpose: backend "owns VIP but does not answer ARP".

VIP on loopback: ip addr add 10.20.0.100/32 dev lo label lo:0 (mask must be /32 to avoid route pollution). Persist via /etc/sysconfig/network-scripts/ifcfg-lo:0 (RHEL) or netplan (Ubuntu).

Verify: ip -4 addr show lo shows VIP/32; from another host arping -c 3 -I eth0 10.20.0.100 should get no reply from backend; curl http://10.20.0.100/ from backend itself works.

Director Configuration

Manual test first: ipvsadm -A -t 10.20.0.100:80 -s wrr; add backends with -g (DR/gatewaying) ipvsadm -a -t 10.20.0.100:80 -r 10.20.1.11:80 -g -w 100. Verify ipvsadm -Ln shows Forward: Route.

Production uses keepalived for VIP failover and health checks. Key config points: state BACKUP on both + nopreempt prevents dual-master. virtual_router_id unique per VRRP group in same L2. auth_pass ≤8 chars, file mode 600. lb_kind DR maps to ipvsadm -g. persistence_timeout 0 disables sticky sessions; if needed, set to session TTL (e.g., 300) but expect uneven load.

Health checks: TCP_CHECK only tests port; for HTTP status-code validation use HTTP_GET with url { path /healthz status_code 200 }.

Start keepalived ( systemctl enable --now keepalived); confirm VIP on eth0 and ipvsadm -Ln --stats shows rules.

Validation & Troubleshooting

Forwarding test: loop curl -H 'Host: www.example.com' http://10.20.0.100/whoami; expect round-robin hostnames.

IPVS stats: ipvsadm -Ln --stats shows balanced Conns; ipvsadm -Lnc shows established connections.

Packet capture: on director, tcpdump -i eth0 -nn -e 'tcp port 80 and host 10.20.0.100' shows destination MAC rewritten to backend MAC, destination IP remains VIP. On backend, reply packets go directly to client (source IP = VIP).

Common failures and fixes:

Timeout, no backend logs: Backend missing VIP on lo or arp_ignore not applied. Kernel drops packets destined to VIP not on local interface. Check rp_filter (set to 2 or 0 on eth0).

VIP failover but traffic breaks: VRRP multicast blocked (common in cloud). Switch to unicast: unicast_src_ip + unicast_peer in keepalived.

Severe backend imbalance: wrr degrades with long-lived connections. Use lc (least connections) or wlc. Verify with ipvsadm -Lnc | awk 'NR>1 {print $6}' | sort | uniq -c.

Port mapping fails: DR mode does not translate ports. Backend must listen on same port (or use iptables REDIRECT locally). Use NAT mode or Layer 7 proxy for port translation.

Hands-On: Nginx Layer 7

Upstream & Connection Pool

Use least_conn for variable latency; keepalive 128 per worker (8 workers → 1024 idle connections max); keepalive_timeout 55s slightly below backend idle timeout; keepalive_requests 1000; keepalive_time 600s. Must set proxy_http_version 1.1 and proxy_set_header Connection "" to enable keepalive.

Passive Health Check Limitations & Workarounds

Open-source Nginx only has passive checks ( max_fails=3 fail_timeout=10s + proxy_next_upstream). Limitations: only marks down after failed requests (first 3 users see errors); no probing when traffic absent.

Three workarounds:

OpenResty + lua-resty-upstream-healthcheck : Active HTTP probes in init_worker_by_lua_block, updates upstream down flag via shared dict. Note: each worker spawns checker; use lua-resty-lock or ngx.timer.every to limit probe rate.

nginx_upstream_check_module (Taobao): Adds check interval=3000 rise=2 fall=3 timeout=1000 type=http in upstream block. Requires recompiling Nginx.

Layer 4 active probing: Place LVS+keepalived ( HTTP_GET) or cloud NLB in front of Nginx; let Layer 4 handle node removal. This is the cleanest separation of concerns.

Layer 7 Routing & Canary

Use split_clients + map to select upstream by variable. However, proxy_pass http://$upstream_group with variable disables connection pooling (connections grow linearly with QPS). Better: two static upstreams + two location prefixes ( /api/ and /api-canary/), with traffic split at higher layer (DNS weight, Layer 4 weight, or separate canary entry).

gRPC, WebSocket, SSE

gRPC: grpc_pass grpc://backend; requires http2 on; set grpc_read_timeout / grpc_send_timeout for streaming.

WebSocket: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; long proxy_read_timeout. Upstream keepalive not reused for upgraded connections.

SSE: proxy_buffering off; proxy_cache off; chunked_transfer_encoding on; add_header X-Accel-Buffering no.

Real IP Propagation

For Layer 7 SLB: set_real_ip_from 100.64.0.0/10 (SLB CIDR); real_ip_header X-Forwarded-For; real_ip_recursive on. For Layer 4 + Proxy Protocol: listen 80 proxy_protocol; real_ip_header proxy_protocol. Warning: enabling Proxy Protocol requires all clients (including health checks) to send the header; otherwise Nginx returns 400.

Hands-On: Cloud SLB Integration

Product Selection

HTTP API with path/header routing → ALB (full Layer 7, elastic).

TCP pass-through (MySQL, Redis, MQTT) → NLB (Layer 4, high perf, static IP).

Legacy mixed Layer 4/7, minimal change → CLB (fixed specs, basic Layer 7).

Fixed public IP, massive concurrency → NLB.

WAF, cert management, canary → ALB.

Anti-pattern: using Layer 4 listener + backend Nginx for URL routing, then adding session persistence at Layer 4 to compensate — pushes Layer 7 work to Layer 4, making both layers harder to maintain.

Health Check Parameters (Layer 7 HTTP)

Recommended: path /healthz (dedicated handler, no downstream calls), method GET, expected status 200 (or 2xx/3xx), timeout 3-5s, interval 5-10s, unhealthy threshold 3, healthy threshold 2. Common misjudgments: path missing (404), method mismatch (HEAD vs GET → 405), dependency checks in health endpoint causing cascade failure, probe interval too short (2s) causing flapping during GC.

Three health-check design principles: (1) Probe liveness, not depth — don't check DB/cache in health endpoint; (2) Thresholds absorb jitter — unhealthy≥3, healthy≥2, interval≥5s; (3) Dedicated probe path — /healthz bypasses auth, rate-limiting, business logging.

Real IP on Cloud

Three methods: (1) X-Forwarded-For (Layer 7 SLB adds header); (2) Proxy Protocol (Layer 4 SLB prepends binary header; Nginx needs listen proxy_protocol + real_ip_header proxy_protocol); (3) TOA kernel module (vendor-specific, restores source IP in kernel, app unaware). Proxy Protocol caveat: health checks bypassing SLB will fail (no PP header); run checks via SLB or open separate non-PP port.

Session Persistence on Cloud

Prefer Cookie-based (Layer 7) over source-IP (Layer 4) because NAT environments concentrate many users behind few IPs. Set reasonable timeout (e.g., 30 min) to avoid long-term binding.

Layered Architecture: Put Each Job in the Right Layer

Standard Four-Layer Chain

User → DNS/GSLB (geo, carrier, weight) → Cloud SLB / Self-hosted LVS (Layer 4: CPS, concurrency, VIP, cross-AZ) → Nginx (Layer 7: routing, TLS, rate-limit, canary, real IP) → App / Ingress / Service

Per-Layer Responsibilities

DNS/GSLB: geo routing, DR failover, coarse weights. NOT: second-level health-check failover (TTL limits).

Layer 4 (LVS/NLB): high CPS, high concurrency, VIP, cross-AZ HA. NOT: URL routing, header rewriting, status-code inspection.

Layer 7 (Nginx/ALB): routing, TLS, rate-limit, canary, cache, compression. NOT: million concurrent connections, database proxying.

Application: business logic, idempotency, circuit-breaking. NOT: TLS termination, session stickiness.

Common mistake: configuring session persistence at both Layer 4 and Layer 7 → user pinned to specific Nginx, which pins to specific app instance; scaling/failover becomes complex.

Cloud + Self-Hosted Combos

All-cloud: DNS → ALB (Layer 7) → ECS/K8s; or DNS → NLB (Layer 4) → Self-hosted Nginx → App.

Hybrid: DNS/GSLB → Per-datacenter entrance (cloud SLB or LVS) → Local Nginx → App. No cross-DC Layer 4 forwarding.

Kubernetes: DNS → Cloud SLB (Layer 4) → Ingress Controller (DaemonSet/Deployment) → Service → Pod. Avoid per-Service type=LoadBalancer (creates many SLBs).

Troubleshooting Advantage of Layering

Layering enables per-hop latency breakdown:

# Client → SLB
curl -o /dev/null -s -w 'dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}
' https://api.example.com/
# SLB → Nginx (Nginx request_time)
# Nginx → App (upstream_response_time)
# App internal (APM/logs)

Four-segment timing pinpoints the problematic layer instantly.

Capacity & Performance Estimation

Three Formulas

Concurrent connections (Little's Law): L = λ × W (L=avg connections, λ=QPS, W=avg latency in seconds). Example: 12k QPS × 0.18s = 2,160 concurrent (avg); using P99 0.8s → 9,600.

CPS: CPS = QPS / requests_per_connection (keepalive on) or CPS = QPS (keepalive off). This is the Layer 4 vs Layer 7 watershed.

Bandwidth: bps = QPS × avg_bytes × 8. Inbound = QPS × avg_req_bytes × 8; outbound = QPS × avg_resp_bytes × 8.

Worked Example

DAU 500k, peak QPS 12k, avg latency 180ms (P99 800ms), req 1.2KB, resp 8KB, keepalive 20 req/conn.

Concurrent: 12k × 0.18 = 2,160 (avg) / 9,600 (P99)

CPS: 12k / 20 = 600

Inbound bandwidth: 12k × 1.2KB × 8 = 115 Mbps

Outbound bandwidth: 12k × 8KB × 8 = 768 Mbps

Conclusion: CPS only 600 → Nginx alone sufficient; outbound 768 Mbps is the real bottleneck → need 10Gbps NIC or CDN. Most businesses are bandwidth- or backend-bound, not CPS-bound; blindly adding LVS wastes effort.

When CPS Is Truly High

Typical high-CPS scenarios: mobile short connections (HTTP/1.0 or no keepalive), high-frequency probes/monitoring, crawlers, internal RPC without connection pools, flash-sale connection storms. Only when CPS >30-50k and keepalive optimization exhausted should you add Layer 4 in front.

Load Testing Methodology

Tools: wrk (HTTP, keepalive), hey (simple concurrency), hping3 (Layer 4 CPS, test env only). Must collect simultaneously on target: sar -n DEV 1 (bandwidth), sar -n TCP,ETCP 1 (retransmits, connections), nstat -az | grep ListenOverflows, ss -s, top -H -p $(pgrep -d, nginx) (per-worker CPU).

Interpretation table:

QPS stalls, single core 100% → worker bottleneck → add workers or nodes.

QPS stalls, overall CPU <50% → connection or bandwidth limit → check ss, sar -n DEV.

High ListenOverflows → increase somaxconn and backlog.

High retransmits → bandwidth/link issue → check retrans/s in sar -n ETCP.

P99 ≫ P50 → queuing or GC → look upstream, not LB.

Testing discipline: non-production env preferred; if production, use maintenance window, time limit, kill switch, special header to distinguish test traffic.

Monitoring Metrics

Layer 4 (LVS/IPVS)

Key metrics from ipvsadm -Ln --stats and /proc/net/ip_vs_stats; node_exporter IPVS collector exposes node_ipvs_connections_total, node_ipvs_incoming_packets_total, node_ipvs_outgoing_packets_total, node_ipvs_incoming_bytes_total, node_ipvs_outgoing_bytes_total. Keepalived: monitor VRRP state via ip -4 addr show eth0 | grep VIP and journalctl; export via keepalived_exporter or black-box probe.

Layer 7 (Nginx)

Enable stub_status; key fields: Active connections, accepts, handled, requests, Reading, Writing, Waiting. Critical ratio: requests / accepts = connection reuse rate; <2 means keepalive ineffective → high CPS pressure. Alert on accepts - handled >0 (resource exhaustion).

Alert Rules (Prometheus Examples)

Examples include: IPVS connections >500k for 5m; Layer 4 inbound traffic drop >70% vs same time yesterday; Nginx active connections >40k; Nginx accept-handled gap >1/s; Upstream 5xx rate >1%. Thresholds must be derived from two-week baseline (P95 × 1.3-1.5), not guessed.

Dashboard Layout (Four Rows)

Ingress health: VIP existence, listener status, healthy backend count.

Traffic: QPS, in/out bandwidth, CPS, connection reuse rate.

Quality: status code distribution, P50/P90/P99, upstream latency, retransmit rate.

Capacity: connection watermark, CPU, memory, FD usage.

Keep panels ≤20; dashboards are for decision-making, not data archiving.

Troubleshooting Playbooks (Five Cases)

Case 1: VIP Pingable but All Requests Timeout

Symptom: ping VIP OK, curl VIP timeout, direct backend OK. Root cause: backend missing VIP on lo → kernel drops packets destined to VIP. ipvsadm health check used connect_port to backend real IP, so health passed but real traffic failed. Fix: add VIP/32 on lo + ARP suppression. Change health check to HTTP_GET against VIP or direct backend /healthz with Host validation.

Case 2: Intermittent 502 Under Load

Symptom: ~0.5% 502 in Nginx error log (

recv() failed (104: Connection reset by peer) while reading response header from upstream

). Root cause: Nginx keepalive_timeout default 60s > backend idle timeout 15s. Backend closes idle connection; Nginx reuses stale connection → RST. Fix: set keepalive_timeout 10s (< backend idle timeout) in upstream block. Verify 502 rate drops to zero; ss shows stable connection count.

Case 3: Severe Backend Imbalance

Symptom: 1 of 4 backends at 90% CPU, others at 30%. Root cause: ip_hash + many users behind same NAT egress → hash collision. Fix: switch to least_conn (Layer 7) or wlc (Layer 4); confirm session persistence truly needed; if yes, use Cookie not source IP. Verify: 100 sequential requests distribute ~25 each; CPU spread within 10%.

Case 4: Real IP All Show SLB Address

Symptom: App logs show client IP as 100.64.x.x (SLB CIDR). Root cause: Layer 4 SLB doesn't add XFF; backend Nginx not configured for Proxy Protocol. Fix options: (A) Switch to Layer 7 listener (auto XFF); (B) Enable Proxy Protocol on Layer 4 listener + Nginx listen proxy_protocol + real_ip_header proxy_protocol; (C) Install vendor TOA kernel module. Verify: external curl shows true client IP in app logs.

Case 5: 502 Spike After Nginx Upgrade

Symptom: Upgrade 1.24 → 1.30, 502 jumps from 0 to 3%. Root cause: Deprecated listen 443 ssl http2; syntax (changed in 1.25.1) or proxy_next_upstream / keepalive behavior changes. Fix: migrate to listen 443 ssl; http2 on;; re-verify keepalive_timeout. Pre-upgrade full-chain test in staging (TLS, HTTP/2, upstream keepalive) is mandatory.

Production Operations Checklist

Change Management

All config in Git; MR review required.

Pre-change: nginx -t / keepalived -t.

Change record: what, why, impact, verification steps, rollback commands.

Canary Deployment

Multi-node: update 1 node, observe 15 min, then roll out.

Multi-DC: update non-critical DC first.

Layer 4 changes (IPVS rules, VIP): maintenance window + business notification.

Layer 7 changes (Nginx reload): anytime (low peak preferred); note reload breaks WebSocket connections (clients must reconnect).

Permissions

keepalived.conf

600 root:root.

Nginx config dir 755, files 644, only ops group writable.

No app-team access to LVS/NLB management — Layer 4 mistake affects all services.

Cloud SLB changes audited via provider operation logs.

Maintenance Windows

Table mapping change type to recommended window and interruption risk (e.g., Nginx reload anytime/low peak, zero downtime except WebSocket; VIP switch window+notify, seconds-to-minutes impact; cert rotation 7-day advance, misconfig = full 443 outage).

Rollback Plans

Every change must answer: (1) Exact rollback command (written down), (2) Rollback time (≤5 min or have fallback), (3) Data loss/connection breakage? If yes, pre-communicate.

Layer 4 rollback: ipvsadm-save -n > /root/ipvs-$(date +%F-%H%M).bak; restore with ipvsadm -C && ipvsadm-restore < backup.

Layer 7 rollback:

cd /etc/nginx && git diff && git checkout -- conf.d/ && nginx -t && nginx -s reload

.

Security

Don't expose Layer 4 management ports (e.g., ipvsadm stats).

Nginx stub_status only on 127.0.0.1 or with allow/deny.

Health endpoint must not leak version/dependency details.

Proxy Protocol only for trusted sources (prevents source IP spoofing). X-Forwarded-For trust chain must be strict; otherwise rate-limiting, WAF, audit all break.

Documentation

Maintain three living docs: (1) Topology diagram (components, IPs, VIPs, owning teams), (2) Runbook (standard procedures: scale, drain, failover, rollback), (3) Incident playbooks (VIP unreachable, all backends down, cert expiry, SLB spec exhaustion). Update on every change; assign owner.

Summary in Four Sentences

Need to see HTTP content? You must use Layer 7. Invisibility means no routing, rewriting, canary — this is a capability boundary, not performance.

Need extreme CPS and massive concurrency? You must use Layer 4. Every Layer 7 parse costs CPU — a physical limit.

On cloud, prefer managed services; self-host only with clear justification. Self-hosted LVS ops cost (ARP, VRRP, kernel params, fire drills) far exceeds hardware cost.

Layering isn't about stacking components; it's about single-responsibility per layer. Layer 4 owns connections, Layer 7 owns content, App owns business. Mix them and nobody can locate faults.

The three opening incidents were not "wrong product choice" but "unclear layer boundaries": LVS backend didn't reply because DR's ARP requirements were ignored; Nginx couldn't handle CPS because connection management was placed at Layer 7; Cloud SLB dropped healthy nodes because health check wasn't aligned with backend. Clarify the boundary, and the choice becomes obvious.

Appendix: Pre-Launch Checklist

[ ] Peak QPS, avg/P99 latency, request/response sizes quantified
[ ] Concurrent connections, CPS, bandwidth calculated with 50% headroom
[ ] URL/Header/Cookie routing needed? (decides Layer 4 vs 7)
[ ] Non-HTTP protocol pass-through needed?
[ ] TLS termination layer decided; cert renewal process defined
[ ] Session persistence truly necessary? If yes, which method?
[ ] Health check path/method/status-code matches backend exactly
[ ] Health check source IP allowlisted on backends
[ ] Real IP propagation method chosen (XFF / Proxy Protocol / TOA)
[ ] Timeout chain aligned end-to-end (client < SLB < Nginx < App)
[ ] Backend connection pool idle timeouts match Nginx keepalive_timeout
[ ] Monitoring covers: connections, CPS, QPS, status codes, P99, retransmits
[ ] Alert thresholds based on baseline, not guesswork
[ ] Rollback commands documented in change ticket
[ ] Failure drills executed (node drain, VIP failover, backend stop)
[ ] Capacity specs confirmed (critical for cloud products)