Nginx怎么配置反向代理 Nginx多站点负载均衡设置详解-LINUX-PHP中文网

nginx实现反向代理与多站点负载均衡的核心是三步：定义upstream（须在http{}顶层）、配置server块（含正确server_name与listen）、proxy_pass精准指向upstream名称；任一缺失或错位将导致502或路由错误。

nginx怎么配置反向代理 nginx多站点负载均衡设置详解

直接说结论：Nginx 实现反向代理 + 多站点负载均衡，核心就三件事——定义 upstream、写好 server 块、确保 proxy_pass 指向正确。漏掉任意一个，要么 502，要么请求全发错地方。

upstream 块必须放在 http{} 顶层，不能嵌套在 server{} 里

很多人把 upstream 写在某个 server 块内部，结果 reload 时 nginx 报错：unknown directive "upstream"。这是因为 upstream 是全局块指令，只允许出现在 http{} 范围内（通常在 nginx.conf 的 http 段开头或单独 include 的文件中）。

正确位置示例：

http {<br>    upstream api_backend {<br>        server 10.0.1.10:3000;<br>        server 10.0.1.11:3000;<br>    }<br>    upstream web_backend {<br>        server 10.0.1.20:8080 weight=2;<br>        server 10.0.1.21:8080;<br>    }<br>    include /usr/local/nginx/conf/vhosts/*.conf;<br>}

错误写法：server { upstream xxx { ... } } —— 这会导致语法错误，且无法被任何 proxy_pass 引用
如果后端是域名（如 backend.example.com），记得加 resolver，否则 DNS 变更后不会自动刷新；内网 IP 更推荐直接写 IP，避免解析开销

server_name 和 proxy_pass 必须严格匹配域名与 upstream 名称

配置多站点时，常见问题是所有域名都打到同一组后端，或者某域名完全 404/502。根本原因往往是 server_name 拼写错误、空格没删干净，或 proxy_pass 后面的 upstream 名和定义不一致（比如定义了 upstream app_v2，却写了 proxy_pass http://app_v1）。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

server_name 支持多个值，但中间不能有空格，用空格分隔会被当成不同参数：server_name a.com www.a.com; ✅，server_name a.com, www.a.com; ❌（逗号会触发语法错误）
proxy_pass 后跟 upstream 名时，**不能带路径**：proxy_pass http://web_backend; ✅，proxy_pass http://web_backend/; ❌（后者会触发“upstream cannot have URI”错误）
若需重写路径（比如把 /api/ 代理到后端根路径），用 rewrite 或在 location 中控制，不要靠 proxy_pass 尾部斜杠“偷懒”

健康检查不能只靠默认轮询，得加 timeout 和 max_fails

默认的轮询策略下，只要 upstream 里某个 server 进程卡住或响应极慢，nginx 仍会持续转发请求过去，导致用户端超时堆积。这不是负载均衡，是“负载堆积”。

必须显式设置：

upstream api_backend {<br>    server 10.0.1.10:3000 max_fails=3 fail_timeout=30s;<br>    server 10.0.1.11:3000 max_fails=3 fail_timeout=30s;<br>    keepalive 32;<br>}

max_fails 和 fail_timeout 配合使用：连续失败 max_fails 次后，在 fail_timeout 秒内不再选该节点；不设的话，失败一次就永久剔除（或永不剔除）
proxy_connect_timeout、proxy_read_timeout 要比后端服务的预期响应时间略长，但别设成 60s 默认值——对 API 服务建议 10–15s，对文件上传可放宽到 300s；设太短容易误判，太长拖垮整体响应

include 多配置文件时，注意文件名顺序和重复 listen 端口

用 include /path/*.conf 管理多站点时，实际加载顺序取决于系统 glob 排序（通常是字典序），不是创建时间。如果两个 .conf 文件都写了 listen 80 且 server_name 有重叠（比如都写了 example.com），后加载的那个会覆盖前一个，但 nginx 不报错，只静默生效——这是线上最隐蔽的配置丢失原因。

命名建议带序号或环境前缀：01-api.conf、02-web.conf，避免 a.conf 和 z.conf 因排序不可控
每个 server 块开头加注释说明用途，例如：# example.com → web_backend (v2)，方便快速定位
上线前务必执行：nginx -t 检查语法 + nginx -T | grep "server_name\|listen" 确认所有域名是否被正确加载

真正难的不是写对第一版配置，而是当新增第三个域名、切换 HTTPS、或后端从 HTTP 升级到 gRPC 时，能否快速判断哪一行参数要动、哪一块依赖要同步更新。这些细节藏在 upstream 定义范围、proxy_pass 的 URI 规则、以及 include 的加载时序里——漏看一眼，就可能让流量绕过负载均衡直奔单点。