低配测试机应设 weight=1 或 2，主力节点设 weight=10 或更高，确保其流量占比 5%–15%，并配置更严苛的健康检查（max_fails=2, fail_timeout=15s）与 slow_start=30s，避免过载。
给低配测试机分配较低权重，核心是让它的 weight 值明显小于其他生产节点，同时确保它仍能被正常探测和承接少量流量——既压测验证功能，又不拖垮整体服务。
明确低配机的定位和合理权重范围
低配测试机通常用于灰度验证、接口联调或轻量监控，不是主力承载节点。它的 weight 不宜为 0（会完全隔离，失去验证意义），也不宜接近主力节点（如主力设为 10，它设成 8 就失去区分度）。常见做法是：
- 主力服务器 weight 设为 10 或更高（如 10、20），便于后续微调
- 低配测试机 weight 设为 1 或 2，占比控制在 5%–15% 区间（例如 10:1 → 约 9%；10:2 → 约 17%）
- 若需近乎“只收日志不接业务”，可设 weight=1 并配合 max_fails=1 fail_timeout=10s，让它在首次异常后快速临时剔除
配置示例与关键写法
在 http 块中定义 upstream，把测试机单独标出，注意语法严谨：
server 192.168.1.100:8080 weight=10; # 主力 A
server 192.168.1.101:8080 weight=10; # 主力 B
server 192.168.1.200:8080 weight=1; # 低配测试机
}
- weight 必须紧贴 server 行末，不能换行，不能加中文标点或空格以外符号
- 不要和
backup、down同时使用——它们互斥，加了 backup 就不参与常规轮询 - 低配机可额外加
slow_start=30s，避免刚上线就涌进大量请求
配套必须开启健康检查
低配机稳定性弱，仅靠 weight 无法规避故障。必须启用基础健康检查，防止它挂了还持续转发：
upstream app_backend {server 192.168.1.100:8080 weight=10 max_fails=3 fail_timeout=30s;
server 192.168.1.101:8080 weight=10 max_fails=3 fail_timeout=30s;
server 192.168.1.200:8080 weight=1 max_fails=2 fail_timeout=15s;
}
- 对低配机适当收紧策略：
max_fails=2、fail_timeout=15s，更快识别异常 - 所有节点都应返回一致的健康接口（如
/health），并在 location 中用proxy_next_upstream error timeout http_500;配合重试
上线后盯住三项实际指标
权重只是理论比例，真实效果要看运行数据：
- 查 access 日志或 Prometheus 的
nginx_upstream_requests_total，确认低配机请求数占比是否落在预设区间（如 weight=1 对比两个 weight=10，目标 ≈ 4.5%） - 对比
$upstream_response_time，若低配机 P95 延迟超主力节点 2 倍以上，说明它已不堪负荷，需降权或下线 - 观察错误率，
upstream_status中 5xx 比例突增，往往意味着低配机资源打满或应用未适配
