反向代理运维需覆盖连接层、协议层和业务层三层监控，配置结构化日志与复合健康检查，并厘清其“对客户端装服务器、对后端装客户端”的双重角色，才能实现高可用与精准故障归因。
HTTP 反向代理不是配置完就能高枕无忧的中间件，它在真实生产环境中承担着流量入口、安全屏障和性能枢纽三重角色。系统性运维的关键，在于把协议行为、网络链路、服务状态和日志痕迹全部串起来看——而不是只盯着 Nginx 配置文件改 rewrite 规则。
理解通信链路中的真实角色切换
反向代理本质是“对客户端装服务器，对后端装客户端”。这个双重身份决定了它必须同时处理两段独立的 HTTP 会话：一段面向用户（含 TLS 终止、Host 头校验、IP 限速），一段面向上游服务（含连接复用、健康探测、超时重试）。运维时若只关注其中一端，就容易出现“请求能进不能出”或“响应返回但客户端收不到”的哑巴故障。
- 客户端到代理：重点检查 TLS 版本兼容性（如老安卓设备不支持 TLS 1.3）、HTTP/2 协议协商是否成功、Via 和 X-Forwarded-For 头是否被正确注入
- 代理到后端：确认 Keep-Alive 连接池是否复用、上游服务响应头是否带 Transfer-Encoding: chunked 导致流式解析异常、后端是否返回 100 Continue 而代理未透传
监控必须覆盖三层状态：连接层、协议层、业务层
仅看 CPU 和内存使用率无法定位反向代理问题。工业级监控需分层采集：
- 连接层：每秒新建连接数、TIME_WAIT 数量、上游连接失败率（connection refused / timeout）
- 协议层：5xx 错误中具体是 502（上游无响应）、503（上游拒绝）、504（代理等待超时）的分布；HTTP/1.1 与 HTTP/2 请求占比突变可能预示客户端升级或中间设备拦截
- 业务层：按 Host 或 upstream 分组统计平均响应时间、缓存命中率（X-Cache: HIT/MISS）、WebSocket upgrade 成功率
健康检查不能只靠 ping 或 HTTP 状态码
默认的 HTTP GET /health 检查极易漏判真实故障。例如后端服务进程存活但数据库连接池耗尽，或依赖的 Redis 响应延迟飙升，此时 /health 仍返回 200，但实际业务已不可用。
- 建议将健康检查路径设为轻量级复合探针：例如 /health?check=db&check=redis，由后端主动聚合关键依赖状态
- 反向代理侧需配置非幂等探测（如 use `proxy_next_upstream error timeout http_500`），避免将瞬时抖动放大为集群剔除
- 对长连接服务（如 gRPC 或 WebSocket），需单独配置 TCP 层心跳检测，而非依赖 HTTP 级探活
日志结构化是故障归因的核心前提
原始 access_log 往往缺失上下文。工业部署必须让每条日志携带可追溯的唯一标识，并对关键字段做标准化提取：
- 在请求入口注入 trace_id（如通过 X-Request-ID 头传递或自动生成），确保同一请求在代理、上游、下游日志中可串联
- 记录真实客户端 IP（X-Real-IP）、代理转发路径（Via）、上游服务地址（upstream_addr）、响应体大小（bytes_sent）、上游响应时间（upstream_response_time）
- 禁用纯文本日志轮转，统一输出 JSON 格式，便于接入 ELK 或 Loki 做字段级聚合分析（例如：统计某 IP 在 1 分钟内触发 503 的次数）
不复杂但容易忽略
