upstream块必须定义在http上下文中，不可置于server块内，否则启动报“unknown directive 'upstream'”；其名称需与proxy_pass严格一致，server地址须显式写IP和端口，轮询为默认策略，weight控制流量分配，backup仅故障时启用，健康检查依赖被动失败机制。
Upstream块必须定义在http上下文中
直接写在server块里会报错，Nginx启动时提示 unknown directive "upstream"。Upstream是HTTP级别的配置，所有后端服务器的抽象都在这里声明，和具体的location或server无关。
正确位置示例：
http {
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
server {
location / {
proxy_pass http://backend;
}
}
}
- upstream名称（如
backend）要和proxy_pass中引用的名称严格一致，区分大小写 - 每个
server行末不加;以外的符号，比如不能写server 127.0.0.1:3000 weight=2;后面多一个逗号 - IP和端口必须可达，Nginx启动时不会校验连通性，但第一次请求失败会记录
no live upstreams错误
轮询是默认策略，无需额外关键字
只要没写ip_hash、least_conn或hash $request_uri这类指令，Nginx就自动按顺序轮流分发请求——不是严格“1-2-1-2”，而是基于连接数动态调整的加权轮询（weight=1时等效于简单轮询）。
- 如果某台服务器响应超时或返回502/503/504，Nginx会临时将其标记为
down，跳过它，持续约10秒（由fail_timeout控制） - 想让某台机器承担更多流量，加
weight=2；设为weight=0相当于禁用该节点 - 避免误加
backup——它只在其他节点全挂时才启用，不是用来做“备用轮询”的
proxy_pass必须带协议和upstream名，不能省略斜杠
proxy_pass http://backend; 是对的；proxy_pass http://backend（结尾无分号）语法错误；proxy_pass http://backend/（末尾有斜杠）会导致URI重写行为变化，容易引发后端路径错乱。
- 如果后端服务监听的是非标准端口（如
3000），必须显式写出：server 127.0.0.1:3000 - 不要用
localhost代替127.0.0.1——DNS解析失败时可能拖慢故障转移 - 若上游服务需要Host头透传，补上
proxy_set_header Host $host;，否则默认发的是upstream name
健康检查得靠第三方模块或外部工具
开源版Nginx的upstream本身不支持主动心跳检测，max_fails和fail_timeout只响应被动失败（即请求打过去被拒绝或超时）。这意味着：一台进程僵死但端口仍通的服务，会被持续转发流量。
- 常见解法是配合
nginx-plus（商业版）或nginx-upstream-check-module（需重新编译） - 轻量替代：用systemd或supervisor监控后端进程，异常时自动
curl -X POST http://localhost/api/upstream/disable?server=192.168.1.10:8080（需自建API） - 日志里盯紧
upstream timed out和connection refused，这是发现“假存活”节点的第一线索
proxy_http_version 1.1和proxy_set_header Connection ''这两项——缺了它们，长连接复用率低，轮询看起来“不均匀”。 
