如何将Nginx与Azure Application Gateway集成实现多层流量转发？

在混合云架构中，把Nginx作为后端服务入口、Azure Application Gateway作为对外统一接入层，能够同时利用云厂商的WAF能力和自建Web服务器的精细路由。这种组合并不是简单串联，而是要在请求头传递、超时与健康检查上做对齐。很多团队在初期只配通了转发，却忽略了后端Nginx拿到的客户端IP全是网关内网地址，导致限流和审计失效。

网络拓扑与请求流向设计

最典型的拓扑是客户端请求先到达Azure Application Gateway，由其完成TLS终结、WAF检测以及基于路径的路由，然后再以HTTP或重新加密的HTTPS转发给后端池中的Nginx实例。Nginx在这里通常不暴露公网，只监听内部负载均衡器的IP或者Application Gateway后端池指定的端口。这样的好处是安全边界清晰，证书只在网关和Nginx两处管理，运维复杂度可控。

如果业务需要在Nginx再做一次七层虚拟主机分发，就要注意Application Gateway的后端探测配置。默认的健康探测会请求固定路径，若Nginx对未知Host返回444或400，探测就会失败从而摘除节点。应当在Nginx中配置一个专用健康检查站点，或者在默认server块里放行网关探测请求，避免误判。

另一种反向拓扑是把Nginx放在Application Gateway之前，用于做边缘缓存和限流，再转发给网关。这种场景较少，因为网关本身已具备层七能力，前置Nginx多数为了弥补网关在重写规则上的僵硬。无论哪种拓扑，核心原则都是明确每一跳的TLS状态和头信息传递责任，不能让两层都去重写同一批Header而造成冲突。

关键配置映射与代码示例

在Azure侧，Application Gateway的HTTP设置里需要开启Custom Probe，指定向后端Nginx发送的健康检查路径，例如/healthz。同时，在重写规则中把X-Forwarded-For、X-Forwarded-Proto正确传递。Nginx则需要信任网关的内网IP段，并从这些头中提取真实客户端地址。下面是一段典型的Nginx配置片段，展示如何根据网关传来的头设置真实IP并做简单路由。

# 信任Application Gateway子网，例如10.0.0.0/16
set_real_ip_from 10.0.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

server {
    listen 80;
    server_name app.internal;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        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_set_header X-Forwarded-Proto $scheme;
    }

    location /healthz {
        return 200 'ok';
        add_header Content-Type text/plain;
    }
}

上面的配置中，set_real_ip_from告诉Nginx哪些上游IP发来的请求可以改写客户端地址。如果不配置，$remote_addr永远是网关的私网地址。对于HTTPS重加密场景，Nginx还要配置服务器证书，并且Application Gateway后端设置里选择HTTPS协议与对应探测端口。证书建议用内部CA签发，避免公网证书在内部跳转时增加额外校验负担。

在重写与缓冲方面，Application Gateway对大请求体有默认限制，Nginx的client_max_body_size也要与之匹配。若网关限制为8MB而Nginx允许20MB，超大会在网关层被拒；反之若Nginx过小，则正常请求在后端就被断掉。建议统一在配置管理系统中用变量控制这两个值，发布前做对比校验。

常见故障与排查思路

集成后最高频的问题是真实IP丢失和会话保持失效。真实IP丢失通常因为Nginx未正确设置real_ip模块，或者网关没有传X-Forwarded-For。排查时可在Nginx日志格式中加入$http_x_forwarded_for与$remote_addr对比，若前者为空则是网关侧未开启，若前者有值但应用仍读不到，则是应用框架没有读取代理头。

会话保持方面，Application Gateway提供基于Cookie的亲和性，而Nginx也有自己的ip_hash或sticky模块。两层同时开启亲和性并不会出错，但会增加排障难度。推荐只在网关层做亲和，Nginx后端保持无状态，这样某台Nginx重启不会让用户掉登录。若必须在Nginx做，请确保网关没有覆盖掉后端设置的Cookie域。

还有一个隐蔽问题是超时链。网关的Request timeout若短于Nginx的proxy_read_timeout，用户会收到网关返回的502而非后端真实慢响应。应使用日志关联请求ID：Application Gateway可在重写规则里注入X-Request-Id，Nginx用$request_id记录，这样两端日志能精准对应同一请求，快速定位是哪一段丢弃了连接。

性能与成本权衡

引入Application Gateway必然带来额外计费，包括固定实例费和数据处理费。若业务流量不大，双层结构可能让成本翻倍。此时可以评估是否用Nginx加ModSecurity直接替代WAF层，或者仅对核心路径走网关。对于高合规要求场景，网关的托管规则集更新比自建快，仍建议保留。

性能上，两层代理会增加单次RTT和TLS计算。若网关到Nginx使用HTTP，可省去一次加解密；若用HTTPS重加密，建议在Nginx开启ssl_session_cache减少握手。压力测试时应模拟网关健康探测并发，避免探测流量在生产峰值期拖垮Nginx的/healthz接口。

总体来看，Nginx与Azure Application Gateway集成是一项配置工程而非开发任务。只要厘清每层的职责边界，处理好头信息与超时，就能构建出既满足云安全又能灵活定制的流量入口。后续迭代中，建议把网关规则和Nginx配置纳入同一套GitOps流水线，避免人工改动导致两层不一致。

NginxAzure_Application_Gateway流量转发修改时间：2026-08-16 12:56:31