nginx -t 报错“syntax is not ok”通常因括号不匹配、分号遗漏或中文标点导致，需用grep检查大括号数量、确认server行末分号、清理crlf/全角字符；若提示server_names_hash_max_size不足，则需在http块中增大该值。
nginx -t 报错 syntax is not ok 怎么快速定位
配置文件语法错误是负载均衡起不来的最常见拦路虎，nginx -t 一跑就失败，但错误提示常只说“in /etc/nginx/conf.d/upstream.conf:12”，却不告诉你哪一行写错了。根本原因往往是括号没配对、分号漏写、或用了中文标点。
- 先用
grep -n "}" /etc/nginx/conf.d/*.conf和grep -n "{" /etc/nginx/conf.d/*.conf对比大括号数量是否一致 - 检查
upstream块里每个server行末尾必须有分号，比如server 192.168.1.10:8080 weight=3;，少分号就会报错 - 复制粘贴配置时特别注意：Windows 换行符（CRLF）或全角空格/冒号会导致解析失败，建议用
dos2unix或在 Vim 中执行:set ff=unix - 若提示
could not build the server name hash，不是语法错，而是server_names_hash_max_size太小，需在http块里加一行server_names_hash_max_size 512;
后端服务器明明开着，但 nginx 日志狂打 connect() failed (111: Connection refused)
这说明 Nginx 能解析 IP，也能发包，但目标端口压根没人监听——不是网络不通，是服务没绑对地址或端口。
- 别只查
ps aux | grep java，要确认进程实际监听的地址：运行ss -tuln | grep :8080，看输出里是不是*:8080（表示监听所有网卡）；如果是127.0.0.1:8080，那从 Nginx 所在机器连不上，得改成0.0.0.0:8080或具体内网 IP - Java 应用常见坑：
spring.servlet.context-path不影响端口监听，但server.address默认是localhost，必须显式设为0.0.0.0 - 防火墙可能放行了 ping 却封了端口：用
telnet 192.168.1.10 8080直接测端口连通性，比 ping 更准 - Docker 容器场景下，检查是否用了
host网络模式，或ports是否正确映射（如-p 8080:8080），容器内服务监听的仍是0.0.0.0:8080
健康检查一直把好节点踢掉：503 Service Temporarily Unavailable
这不是 Nginx 配置错了，而是它“以为”后端挂了。默认 health_check 或 check（第三方模块）会发 HEAD / 请求，如果后端返回非 2xx 状态码或超时，就标记为 down。
- 先手工模拟健康检查请求：
curl -I http://192.168.1.10:8080/，看是否真返回 200。Spring Boot 默认 Actuator 的健康端点是/actuator/health，不是根路径 - 调整超时参数：在
upstream块中加max_fails=3 fail_timeout=30s，避免单次抖动就被剔除 - 自定义健康检查路径：用
location /health { return 200 'OK'; }配一个轻量 endpoint，再在 upstream 里配health_check uri=/health - 若用的是
nginx-plus或商业版，注意match块里正则是否写错，比如匹配响应体时误写了body ~ "up"，但实际返回是{"status":"UP"}
流量始终打不到某台服务器：weight 设了却没效果
权重（weight）只在轮询（round-robin）策略下生效，且前提是所有服务器都处于 up 状态。一旦某台被健康检查标记为 down，它的 weight 就完全失效。
- 运行
nginx -T 2>/dev/null | grep -A 5 "upstream.*myapp"查看当前生效的 upstream 配置，确认 weight 值是否被正确加载 - 检查是否误启用了
ip_hash或hash $request_uri：这两种策略会强制同一客户端/请求路径总打到同一台，weight 完全不起作用 - 验证流量分配：在每台后端加日志打印请求来源 IP（Nginx 默认透传
X-Real-IP），或用tcpdump -i any port 8080 -c 20 -w dump.pcap抓包分析真实分发比例 - 注意权重是相对值：设
server a:8080 weight=10和server b:8080 weight=1，并不意味着 10:1 流量比，而是约 91% vs 9%，实际受连接复用、keepalive 影响会有偏差
真正容易被忽略的是：Nginx 的 upstream 状态是内存中的，reload 配置不会清空历史健康状态。哪怕你改对了后端地址，只要之前它被标记为 down，就得等 fail_timeout 过期或手动触发 nginx -s reload 后再等一次健康检查通过。临时救急可加 down 参数强制上线，但治标不治本。
