轮询和ip_hash是Nginx原生负载均衡策略：轮询为默认策略，需明确定义upstream块且server权重默认为1；ip_hash用于会话保持，但禁用weight等参数，不支持自动故障转移，IPv6和代理场景需特殊处理。
轮询和 ip_hash 是 Nginx 原生支持的两种最常用负载均衡策略，无需安装额外模块，但配置位置、参数含义和行为差异容易混淆——尤其当 ip_hash 和 weight 同时出现时会直接报错。
轮询（round robin）是默认策略，但必须显式写进 upstream 块里才生效
很多人以为不写任何算法就是“轮询”，其实没错，但实际部署中必须把后端列表明确放在 upstream 块内，否则 proxy_pass 无法识别目标组。常见错误是漏掉 upstream 定义，或把 server 写在 http 外层。
-
upstream必须定义在http块内，不能嵌套在server或location中 - 每个
server行默认权重为1，不需要写weight=1 - 若某台后端临时下线，用
down标记即可：server 192.168.1.101:8080 down;，Nginx 会跳过它且不尝试连接 - 健康检查要靠
max_fails和fail_timeout配合，例如：server 192.168.1.102:8080 max_fails=2 fail_timeout=10s;
最小可用配置示例：
http {
upstream backend {
server 192.168.1.101:8080;
server 192.168.1.102:8080;
server 192.168.1.103:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
}
ip_hash 要求所有 server 行不能带 weight 参数
ip_hash 的核心作用是绑定客户端 IP 到固定后端，用于解决 session 一致性问题。但它和加权策略互斥：只要 upstream 块里写了 ip_hash，所有 server 行都不能出现 weight、max_fails、fail_timeout 等参数，否则 Nginx 启动会报错 nginx: [emerg] invalid parameter "weight" in ...。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
ip_hash本身不提供故障转移能力，如果某台后端宕机，对应哈希槽的请求会直接 502 —— 必须配合down手动剔除，或升级到较新版本（1.7.2+）支持自动踢出 - IPv6 地址会被截断前 64 位再哈希，可能造成多个 IPv6 客户端命中同一后端
- 使用 CDN 或代理时，
$remote_addr变成 CDN IP，此时需改用$http_x_forwarded_for，但需确保该 header 可信，否则可被伪造
正确写法：
upstream backend {
ip_hash;
server 192.168.1.101:8080;
server 192.168.1.102:8080;
server 192.168.1.103:8080;
}
reload 不等于热生效：配置语法错会导致整个 Nginx 拒绝服务
执行 nginx -s reload 时，Nginx 会先校验新配置语法，再启动新 worker 进程并优雅关闭旧进程。但一旦配置有误（比如 ip_hash 和 weight 并存），reload 会失败，且当前运行的旧配置仍有效 —— 这容易让人误以为“改了没用”。真正危险的是，有人顺手执行 systemctl restart nginx，结果因语法错误导致服务完全中断。
- 每次修改前务必运行
nginx -t，确认输出nginx: configuration file /etc/nginx/nginx.conf test is successful - 线上环境建议用
include把 upstream 单独拆到独立文件（如/etc/nginx/upstreams/backend.conf），便于灰度和 diff - 注意：
upstream块名区分大小写，proxy_pass http://Backend;和upstream backend { ... }不匹配
真实请求验证比日志更可靠，但要注意浏览器缓存干扰
用 curl 测试轮询时，连续跑 6 次不一定看到严格 101→102→103→101 循环，因为浏览器或工具可能复用连接（keepalive）、或服务端返回了 Set-Cookie 导致后续请求带 Cookie 被后端重定向，掩盖了 Nginx 分发逻辑。
- 验证轮询：用
curl -sI http://nginx-ip/ | grep Server查看响应头中的Server字段（需后端主动返回），或在每台后端首页写明服务器标识 - 验证 ip_hash：换不同公网 IP（手机热点、朋友电脑）访问，观察是否始终落到同一台；同一 IP 下多次请求应不变
- 避免本地测试失真：Linux 上用
curl --interface 127.0.0.2模拟不同源 IP（需提前配好 lo 别名）
最易被忽略的一点：Nginx 的负载均衡决策发生在请求进入 proxy_pass 的瞬间，不关心后端响应内容或耗时 —— 所以即使某台后端卡死，只要 TCP 握手成功，Nginx 就会把请求塞过去，直到超时。这需要靠 proxy_read_timeout 和上游健康检查共同兜底。
