https重定向必须在负载均衡上游完成，即在listen 80的server块中用return或rewrite强制跳转；负载均衡应在nginx终止tls后以http转发至后端，确保连接复用与证书统一管理。
HTTPS 重定向和负载均衡在 Nginx 中不是孤立配置，而是需要协同设计的两个关键环节：重定向确保所有流量走加密通道，负载均衡决定加密流量最终分发到哪台后端。二者配合不当，容易出现循环重定向、证书不匹配、连接复用失效等问题。
HTTPS 重定向必须在负载均衡上游完成
重定向逻辑（如 HTTP → HTTPS）应放在 server { listen 80 } 块中，且不能出现在 location 内部或代理之后。它的作用是把用户原始请求“拦下来”，强制跳转，而不是转发给后端处理。
- 正确写法：用
return 301 https://$host$request_uri;或rewrite ^(.*)$ https://$host$1 permanent;直接响应客户端 - 错误做法：在
location /里对proxy_pass的结果做重定向——这已进入反向代理流程，后端返回的 301 会直接透传，无法统一控制 - 注意：重定向目标域名必须与 SSL 证书绑定的域名一致，否则浏览器会报证书无效
负载均衡器需明确区分协议层级
Nginx 通常作为 TLS 终止点（Termination），即它解密 HTTPS 请求，再以明文 HTTP 转发给后端服务。这种架构才能启用连接池、复用 keepalive、统一管理证书。
- 推荐模式：
client ⇄ Nginx(HTTPS) ⇄ backend(HTTP)，upstream 指向后端 HTTP 地址（如10.0.0.10:8080） - 避免直连后端 HTTPS：
proxy_pass https://backend会导致每次请求重建 TLS 握手，无法复用连接，性能下降明显 - 若后端必须 HTTPS（如内网强加密要求），则需额外配置
proxy_ssl_*系列指令，并启用keepalive，但调试复杂度高、复用率低
证书与 upstream 引用必须严格对应
SSL 配置只作用于 Nginx 监听 443 端口的 server 块；而负载均衡逻辑由 upstream 定义，并在该 server 的 location 中通过 proxy_pass 引用。两者属于不同配置层级，但必须语义一致：
-
server_name值要与证书中的 CN 或 SAN 域名完全匹配 -
proxy_pass http://my_upstream中的my_upstream必须提前定义在http块顶层，不能嵌套在 server 内 - 如果使用多个域名共用一套证书（如泛域名或 SAN 证书），可复用同一组 upstream；不同证书需分开 server 块，但可共用同一个 upstream
健康检查与会话保持影响重定向路径
当启用 ip_hash 或 sticky 会话保持时，首次重定向后的请求会被固定到某台后端；若该后端宕机，Nginx 默认会尝试其他节点，但客户端浏览器仍持有原重定向缓存（301），可能造成短暂不可达。
- 建议搭配
max_fails和fail_timeout实现快速故障剔除 - 对关键业务，可考虑用
least_conn替代ip_hash，更利于连接负载均衡 - 避免在重定向逻辑中硬编码 IP 或端口，全部交由 upstream 管理，便于横向扩展
