nginx代理在集群内部的核心作用是轻量、稳定、可控的流量分发层，而非替代服务发现；它通过独立upstream分组、被动健康检查（max_fails=3 fail_timeout=30s）、基于路径/head/参数的动态路由、关键头透传、长连接复用、关闭缓冲、按后端限流及详细日志等机制实现高效精准调度。
Nginx 代理用于集群内部流量调度，核心不是替代服务发现，而是做轻量、稳定、可控的流量分发层。它不管理实例生命周期，但能高效承接上游（如 API 网关、Sidecar 或客户端）发来的请求，并按预设规则路由到后端服务集群。
明确 upstream 分组与节点健康策略
每个微服务或功能模块应有独立 upstream 块，避免混用：
- 节点地址可写 IP:Port，也可用 DNS 名（如
order-service.default.svc.cluster.local），前提是 resolver 配置正确 - 统一启用被动健康检查：
max_fails=3 fail_timeout=30s，让异常节点自动摘除 - 若需主动探测（如 HTTP 200 检查），需搭配
nginx-upstream-check-module或 OpenResty 的lua-resty-upstream-healthcheck - 不建议在集群内用
ip_hash（客户端多为 Pod IP，易漂移），优先选least_conn或加权轮询
基于路径、Header 或变量动态路由
内部调用通常携带业务标识，Nginx 可据此精准分流：
- 按路径前缀：
location /api/order/ { proxy_pass http://order_upstream; } - 按请求头识别环境：用
map $http_x-env $backend { "prod" "prod_upstream"; "staging" "staging_upstream"; }，再proxy_pass http://$backend; - 按参数区分灰度：
map $arg_v $route { "v2" "v2_upstream"; default "v1_upstream"; }
透传关键上下文并控制连接行为
内部链路对延迟和一致性更敏感，需精细化配置：
- 必须透传原始调用方信息：
proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Request-ID $request_id;（配合$request_id变量生成） - 启用长连接复用：upstream 中配置
keepalive 64;，并在 location 内加proxy_http_version 1.1; proxy_set_header Connection ''; - 关闭缓冲以支持流式响应：
proxy_buffering off;（适用于 gRPC-web、SSE 或实时日志接口）
统一限流与可观测性接入
集群内部调用也需防雪崩，但策略应区别于外网：
- 按服务名限流：
limit_req_zone $upstream_addr zone=svc_order:10m rate=500r/s;（针对后端地址而非客户端） - 记录转发详情：
log_format upstream_log '$remote_addr - $upstream_addr [$time_local] "$request" $status $upstream_response_time'; - 开启
proxy_next_upstream error timeout http_502 http_503;，自动重试失败请求，提升容错率
