宿主机部署Nginx转发流量到多个容器化Nginx是否可行？有性能影响吗？

这种两层Nginx的转发方案完全可行，也是单服务器部署多容器Web应用的主流实践之一。
宿主机Nginx作为统一接入层，承担SSL卸载、全局路由分发、统一访问控制/限流等公共能力；各容器内的Nginx只负责对应应用的专属路由、静态资源处理、应用层规则配置，职责拆分清晰，后期扩容或者下架单个应用都不会影响其他服务。

• 配置维护成本升高：两层Nginx都存在路由规则逻辑，一旦出现路径重写、请求头传递、跨域配置不一致的情况，很容易出现404、502、请求信息丢失等问题，排查时需要同时核对两层配置，定位难度比单层Nginx高
• 网络管理复杂度上升：需要提前规划容器的网络方案，要么给每个容器固定映射本地端口供宿主机Nginx转发，要么把宿主机Nginx也加入Docker内部网络通过容器名通信，容器重启如果IP/端口变动会直接导致宿主机转发失败
• 不必要的HTTPS开销：如果没有特殊安全要求，宿主机到容器的内部通信建议走HTTP即可，不要在容器内的Nginx也配置HTTPS，否则会多出一层TLS握手开销，还需要额外维护容器侧的证书
• 日志排查效率低：访问日志会分别存储在宿主机Nginx和多个容器Nginx中，没有统一日志采集方案的情况下，出现请求异常需要跨多个日志源核对，排查效率低

• 常规低并发场景下几乎没有可感知的性能损耗：Nginx的反向代理性能极高，单层次的转发开销普遍在1ms以内，只要服务器CPU、内存资源充足，QPS在数千级以内的场景，用户完全感知不到两层转发的差异
• 高并发场景下会有额外的资源开销：当QPS达到万级以上时，两层TCP连接建立、请求转发的开销会被放大，整体会多消耗10%~20%左右的CPU资源，这种场景可以考虑将容器内Nginx的规则合并到宿主机Nginx，去掉中间转发层优化性能
• 唯一的大额开销是宿主机的SSL卸载环节，这是所有HTTPS接入方案的固定开销，和两层Nginx的架构无关

内容的提问来源于stack exchange，提问作者mr L