尧图网页设计 
看到“Nginx搭建负载均衡”这个标题我估计不少朋友的第一反应是这不就是个upstream加proxy_pass的事儿吗网上教程一抓一大把。但真到自己上手配置或者接手一个已经跑着的集群时问题就来了——为什么我的请求总是打到同一台机器上为什么后端一挂整个服务就502为什么配了HTTPS前端却一直报证书错误还有被问烂了的“welcome to nginx怎么解决”。这几年我在生产环境里前前后后折腾过不少Nginx的活儿从单机转发到多节点集群从简单的轮询到根据业务场景调整策略踩过的坑比写过的配置都多。这篇东西我不打算给你抄一段配置就完事而是把搭建负载均衡从设计思路、配置细节、坑点排查到扩展玩法完整地捋一遍。内容会覆盖反向代理和负载均衡的关系、upstream的几种算法怎么选、location的工作流机制、HTTPS转发那些容易踩的证书坑还包括本地开发环境多站点配置、用Nginx代理Ollama这类AI服务、容器部署、以及被问得最多的并发连接数优化和访问日志排查。适合刚入门想搞清楚原理的初学者也适合部署过但总被各种疑难杂症折磨的运维和开发朋友。1. 先把思路理清楚负载均衡到底在解决什么问题1.1 为什么偏偏是Nginx做后端或者运维的朋友应该都有这种经历业务量一上来一台Web服务器扛不住了CPU飙到百分之八九十数据库连接被打满用户开始反映页面打开慢。这时候最直接的办法就是加机器。但加完机器之后有个问题——用户请求到底访问谁总不能让用户自己去记一堆IP地址吧。所以我们需要一个入口把请求按照一定的策略分发到后面的多台服务器上这就是负载均衡。市面上能做负载均衡的东西不少硬件有F5软件有LVS、HAProxy云厂商也有现成的SLB产品。但Nginx在这中间有一个很特别的生态位——它本身就是Web服务器又能做反向代理配置起来门槛低性能也够硬。单机Nginx能轻松扛住几万并发连接配合keepalived还能做高可用。更关键的是它的配置语法非常直观改完reload一下就好不像某些重量级方案动辄要重启服务、改一堆参数。所以不管是小公司起步阶段还是已经有一定规模的生产环境Nginx基本都是首选。1.2 反向代理和负载均衡是一回事吗这两个概念经常被放在一起说但严格来讲是两回事。反向代理是站在服务器角度代替后端服务器接收客户端请求再把请求转发给内部的实际服务。对客户端来说它不知道也不关心后面到底有几台服务器它只认反向代理这个入口。而负载均衡是在反向代理的基础上多了一个“把请求分发到不同后端”的能力。你可以这么理解反向代理解决的是“隐藏内部结构”的问题负载均衡解决的是“如何分配压力”的问题。Nginx做负载均衡的时候两者通常是叠加使用的。你对外暴露一个域名或者端口Nginx接收请求后根据配置好的策略把请求转发到upstream里定义的某一台后端机器上。后端服务器响应的内容再经由Nginx返回给客户端。这个过程中Nginx既是代理又是分发器。还有一点需要理清Nginx做负载均衡的时候默认是七层负载均衡工作在HTTP层能拿到URL、请求头、Cookie这些应用层信息所以可以做非常灵活的转发策略。如果你想做四层负载均衡基于IP和端口转发Nginx也有stream模块可以选择。大部分Web场景用七层就够了四层一般留给数据库或者内网服务。2. 动手搭建之前的环境准备与基础配置2.1 Nginx的安装没有那么复杂环境准备这一步本身不难但很多初学者的坑恰恰出在最初的安装环节。我见到的常见问题包括用yum装了个老版本导致某些模块用不了编译安装时少了一堆依赖反复报错还有的装完根本起不来看一眼错误日志才发现是配置文件里的注释符号写错了位置。在不同系统上安装Nginx方法不太一样。在CentOS或者RHEL系列上官方推荐添加Nginx的yum仓库然后安装这样能拿到最新的稳定版。在Ubuntu或者Debian上直接用apt安装也可以但默认仓库里的版本可能偏旧想要新特性的话同样建议添加官方PPA或直接用源码编译。# CentOS / RHEL 系列 sudo yum install epel-release sudo yum install nginx # Ubuntu / Debian 系列 sudo apt update sudo apt install nginx装完之后验证一下版本和启动状态。这里我多说一句装完Nginx之后第一件事不是急着改配置而是先访问一下服务器IP看看能不能看到默认的欢迎页。如果连默认页都看不到说明安装或者网络层面有问题这时候去改负载均衡配置只会让问题更难排查。源码编译安装的话核心命令大致是这样wget https://nginx.org/download/nginx-1.26.2.tar.gz tar -zxvf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure --prefix/usr/local/nginx --with-http_ssl_module --with-stream make make install编译安装的好处是能灵活控制模块比如你想要stream模块做四层转发或者想加一些第三方模块编译安装是最合适的。缺点就是升级维护稍微麻烦一点。个人建议如果没有特殊需求直接用系统包管理器安装的Nginx就够用省心很多。2.2 配置文件结构先看懂再动手改很多人拿到Nginx之后第一件事就是打开nginx.conf然后被里面密密麻麻的配置项吓到。其实没那么复杂Nginx的配置是分层的核心结构可以概括为主配置文件负责全局设置http块里定义虚拟主机server每个server块里定义具体的location转发规则。以yum安装的Nginx为例主配置文件在/etc/nginx/nginx.conf。里面会有一行“include /etc/nginx/conf.d/*.conf;”这是把conf.d目录下所有的conf文件都加载进来。所以我强烈建议不要把所有配置都堆在nginx.conf里而是在conf.d目录下按项目建独立的配置文件比如web1.conf、api.conf这样每个服务的配置互不干扰出了问题也好排查。# 一个典型的server配置块长这样 server { listen 80; server_name example.com; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }理解这个结构是后续所有操作的地基。以后不管是配负载均衡、搞HTTPS、还是做多站点都是在server和location这两层做文章。3. 核心配置实战从单机转发到负载均衡集群3.1 upstream与proxy_pass的配合负载均衡的核心配置其实就两块一个upstream块定义后端服务器列表一个proxy_pass把请求转发到这个upstream。http { upstream backend_servers { server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; server 192.168.1.12:8080 backup; } server { listen 80; server_name example.com; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }这段配置里upstream定义了一个叫backend_servers的后端组包含三台服务器。第一台权重是3第二台权重是1意味着正常情况下每4个请求里有3个打到第一台1个打到第二台。第三台设置了backup参数意味着它是备用节点——只有前两台都挂了的时候才会转发到它。这里有个细节值得展开说一下proxy_set_header这几行配置非常关键。如果不把Host、X-Real-IP、X-Forwarded-For这些头传给后端后端程序拿到的客户端IP全是Nginx的IP日志里看不到真实访客有些依赖IP做限制的功能也会全部失效。尤其是X-Forwarded-For后面的程序如果要做访问频率限制或者风控判断这个头是必须的。3.2 负载均衡算法选型别无脑用轮询Nginx的负载均衡策略有好几种默认是轮询round-robin也就是按顺序轮流把请求分配到每台后端。但实际生产环境中轮询并不总是最优解。常用的策略有这么几种轮询默认每个请求按时间顺序逐一分配到不同的后端。适合后端服务器配置差不多的场景。加权轮询通过weight参数控制每台服务器的流量比例适合服务器性能有差异的情况。ip_hash按客户端IP的哈希结果分配同一个IP的请求会固定打到同一台后端。这个策略很适合需要Session粘滞的场景但缺点是如果某一台后端挂了它承载的那部分用户会受影响而且负载可能不均衡。least_conn把请求发给当前活跃连接数最少的后端。适合请求处理时间差异较大的业务。fair按后端服务器响应时间长短来分配响应快的优先分配。这个需要第三方模块支持默认没带。我在实际项目中用得最多的是加权轮询和ip_hash的组合逻辑——前端Nginx用加权轮询后端服务做无状态化Session放在Redis里这样既保证了负载均衡又不会因为请求打到不同机器导致用户登录状态丢失。如果业务确实有粘滞需求比如某些老系统Session放在本地那就只能用ip_hash了但得接受它带来的负载不均问题。upstream backend_servers { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; }还有一个参数容易被忽略fail_timeout和max_fails。这俩配合起来控制Nginx对后端健康状态的判断。比如配置max_fails2 fail_timeout30s意味着一台后端在30秒内如果有2次转发失败Nginx会认为它挂了接下来30秒内不再给它转发请求。这个机制能起到简单的健康检查效果但它是被动的——只有请求转发失败了才知道后端有问题。如果需要主动健康检查简单场景可以靠这个参数更精细的场景建议引入nginx_upstream_check_module或者直接用云负载均衡的主动探测。3.3 location匹配机制不搞清楚这个配置就是玄学location匹配是所有Nginx配置里面最容易被搞糊涂的地方。我见过不少朋友在location里写了一大堆规则结果访问的URL老是跑到别的地方去最后只能靠试错来猜。Nginx的location匹配规则其实是有一套严格优先级的。简单来说优先级从高到低是这样精确匹配。如果请求的URI和这个字符串完全一样直接命中。^~前缀匹配一旦命中就不再检查后续的正则。~和~*正则匹配。波浪号开头的区分大小写波浪号加星号的不区分。普通前缀匹配。按前缀的匹配程度选最长的那个。举个例子你的server里同时配置了location /和location /api/那么访问/api/login的时候会走location /api/因为普通前缀匹配时Nginx会选择匹配最长的前缀。但如果你的location /api/没有加^~同时配置文件里还有其他正则location那情况就变得复杂了——正则location会在所有普通前缀匹配都确定之后再进行一次检查如果正则匹配上了它会覆盖普通前缀的结果。这段逻辑用文字描述比较绕但在实际配置里我建议遵循一个原则能用和^~搞定的就不要用正则。比如静态资源目录直接写location ^~ /static/ { ... }这样命中之后就不会再去做正则匹配效率更高行为也更好预判。3.4 静态文件与动态请求分离前面说的都是将请求转发给后端的反向代理配置但有一个非常常见的性能优化手段值得单独提一下——静态文件直接由Nginx处理只有动态请求才转发给后端。做法其实就是在location里区分不同路径location /static/ { alias /data/project/static/; expires 7d; access_log off; } location / { proxy_pass http://backend_servers; }这样做的效果非常明显。图片、CSS、JavaScript这些静态资源不必经过后端应用服务器Nginx处理静态文件的性能远高于一般的应用服务器而且expires设置还能让浏览器缓存静态资源大大减少重复请求。我曾经接手过一个项目后端Tomcat的CPU负载一直很高排查后发现大量的静态资源请求都打到了Tomcat上做了这个分离之后CPU直接降了一半还多。4. 场景扩展从单机负载均衡到多环境多服务4.1 本地虚拟机多端口多站点配置做开发的时候经常遇到一个需求本地起了一堆服务想用自定义域名访问不同项目不想每次敲IP加端口。比如项目A在宿主机的8080端口项目B在8081项目C在8082你想通过a.local、b.local这种域名来访问。这个场景在Nginx里配置起来非常顺手。关键是两件事一是hosts文件里做域名解析二是Nginx里每个server块监听80端口但用不同的server_name区分。# /etc/nginx/conf.d/vhost.conf server { listen 80; server_name a.local; location / { proxy_pass http://127.0.0.1:8080; } } server { listen 80; server_name b.local; location / { proxy_pass http://127.0.0.1:8081; } }Windows上的hosts文件在C:\Windows\System32\drivers\etc\hostsLinux在/etc/hosts。加上这几行127.0.0.1 a.local 127.0.0.1 b.local很多人配置完发现不起作用原因一般是两个一是浏览器缓存了DNS解析结果换隐身模式试试就好二是Nginx的server_name和请求的Host头不匹配如果直接用IP访问Nginx只会走默认的第一个server块。这个方案调试起来非常方便而且和生产环境的域名转发行为是一致的本地验证通过了再上服务器能省不少事。4.2 HTTPS转发与证书校验的坑现在基本没有纯HTTP的服务了HTTPS是标配。但Nginx做HTTPS反向代理的时候有一堆小坑其中被问得最多的就是net::ERR_CERT_COMMON_NAME_INVALID。这个报错的含义是浏览器访问的域名和服务器返回的证书里的Common Name或者Subject Alternative Name不匹配。场景通常是这样——你的Nginx配置了443端口的HTTPS监听证书也配置好了浏览器直接访问Nginx是正常的但一旦请求经过Nginx转发到后端HTTPS服务后端返回的页面里引用的资源链接和证书域名不一致浏览器就会拦截。解决的思路分几种如果后端是HTTP服务Nginx这边只要配好证书就行转发的后端用proxy_pass http://浏览器和Nginx之间是HTTPSNginx和后端之间是HTTP这是最常见的架构。如果后端也是HTTPS而且不想跳过证书校验那需要给proxy_pass https://...加上proxy_ssl_server_name on;和proxy_ssl_name来传递正确的SNI。如果是为了调试方便直接跳过校验可以在location里加location / { proxy_pass https://backend_service; proxy_ssl_verify off; }但我不建议生产环境这么干。隐患很明显——中间人攻击的风险会大幅上升而且这类问题一旦出现线上排查比本地麻烦得多。还有一个值得注意的点配置HTTPS时旧客户端或者某些爬虫工具可能会用HTTP来访问你的443端口这时候最好配置一个HTTP跳转HTTPS的策略server { listen 80; server_name example.com; return 301 https://$host$request_uri; }4.3 用Nginx代理Ollama等AI服务最近AI相关的服务火得快不少朋友在自己的机器上跑起来了Ollama、CherryStudio这类工具。这里的典型需求是Ollama默认监听11434端口我想把它暴露给内网的其他电脑或者某个Web前端调用但不想让所有人直接访问原始端口更不想把API Key明文暴露在前端代码里。Nginx在这个场景里做一层代理既隐藏了Ollama的真实端口又可以在代理层拦截不受信任的请求。配置大概是这样的server { listen 11435; server_name _; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }如果是给CherryStudio这类前端工具用还需要考虑一个细节前端调用Ollama时通常会直接将服务的地址配到设置里。如果前端代码里写死了一个API Key而这个Key又被别人从浏览器里抠出来那等于没有防护。所以更稳妥的做法是在Nginx层面做一个简单的鉴权过滤比如要求请求头里带着自定义的Header才放行不满足条件的请求直接返回403。这样即使端口暴露了别人没有正确的Header也调用不了。4.4 容器部署Nginx时的配置挂载问题用Docker跑Nginx的场景现在也很普遍。基础命令大概是这样的docker run -d --name nginx-gateway \ -p 80:80 -p 443:443 \ -v /opt/nginx/conf.d:/etc/nginx/conf.d:ro \ nginx:stable很多朋友在挂载conf.d目录时碰到一个老坑容器起不来日志里报错说Nginx配置格式有问题。实际情况往往是你宿主机上的conf.d目录权限或者SELinux上下文不对容器内的Nginx没有权限读取。另外还要注意官方Nginx镜像里的nginx.conf本身就有一行include /etc/nginx/conf.d/*.conf;所以你挂载的conf.d目录里最好只放.conf后缀的配置文件别放乱七八糟的备份文件——Nginx会把所有.conf文件都当配置加载备份文件如果命名成.conf结尾大概率会报语法错误。在容器里跑Nginx还有一个容易忽略的点如果后端服务也在容器里并通过容器网络互通那么upstream里的server地址应该写容器服务名而不是127.0.0.1。比如后端容器叫app-service配置里就应该写upstream backend { server app-service:8080; }这个细节在docker-compose环境里尤其常见。你宿主机上明明访问得通但容器内访问127.0.0.1访问的是Nginx容器自己当然连不上后端的服务。5. 提升稳定性监控、调优与常见问题排查5.1 看到“Welcome to nginx”别慌“welcome to nginx怎么解决”这个问题在网上被搜索的次数非常惊人。这个页面本身说明Nginx已经安装成功并且正常工作了但你想访问自己的服务却发现一直停留在这个欢迎页原因基本可以归结为两类。第一类你压根没配置自己的server块或者配置了但没把浏览器实际访问的域名写进server_name。Nginx默认的欢迎页配置其实就藏在conf.d目录下的default.conf在Debian系的镜像里它监听80端口server_name是_兜底匹配所有访问。你新建的server块如果没有被正确加载或者加载顺序导致default.conf先匹配了请求就到默认页了。第二类你配置了server块但语法错误Nginx reload失败服务还是跑在旧配置上。解决思路很简单——先用nginx -t检查配置语法再nginx -s reload重载配置最后直接curl访问你的域名看响应头。nginx -t nginx -s reload curl -I http://your-domain.com这里额外提醒一句如果你的Nginx是通过apt安装的配置目录结构是/etc/nginx/sites-enabled不要直接在sites-enabled里改文件而是应该在sites-available里创建配置然后做软链接。这是Debian系在管理多站点时特有的风格硬在sites-enabled里改文件虽然也能生效但不符合习惯升级或者重装的时候容易乱。5.2 Nginx最大并发连接数的限制和调优“Nginx最大并发链接数老是用超”是很多站长朋友的真实痛点。首先要明白一个概念Nginx能承载的并发连接数不只取决于Nginx本身的配置还取决于操作系统内核的限制以及每个worker进程能打开的文件描述符数量。Nginx配置里有个经典的计算公式最大并发连接数 worker_processes × worker_connections。如果你设置了worker_processes为4worker_connections为1024那么理论上最大并发是4096。但这里有个隐藏的前提你的系统文件描述符限制要足够大。默认的ulimit通常只有1024Nginx一个连接就要占用一个文件描述符所以需要同步调大这两个限制worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 2048; use epoll; }worker_processes设为auto会让Nginx根据CPU核数自动调整。worker_connections设为2048的情况下四核机器的理论并发就是8192。同时还需要在系统层面修改文件描述符限制ulimit -n 65535这样改完之后之前“并发一高就超”的问题基本能缓解。但需要注意的是如果你的后端应用服务器处理能力有限把并发调得再高也没用请求只会积压在后端。负载均衡的意义不是让Nginx扛下所有压力而是把压力均匀地分散到后端的每一台机器上。5.3 Windows环境查看Nginx日志很多人在Windows上开发调试Nginx也是可以直接跑的。Windows版的Nginx日志默认在安装目录下的logs文件夹里access.log记录每次请求的详细信息error.log记录错误和警告。但Windows上查看日志文件有一个比较头疼的问题文件被Nginx进程占用用记事本打开有时候看不到实时更新的内容或者文件太大打不开。我之前用Windows调试Nginx时更喜欢用PowerShell加上Select-String做关键字检索。比如要看某个IP的访问记录Get-Content -Path C:\nginx\logs\access.log -Tail 100 | Select-String 192.168.1.100如果日志文件特别大直接完整读文件会卡死这种情况下用-Tail只看末尾最新的记录或者用日志分析工具来解析。有人问过有没有专门看Nginx日志的图形化工具Windows上的选择确实不如Linux那么丰富简单场景用命令行就够数据量大了建议还是把日志集中收集到ELK或者Loki里做可视化分析。5.4 各大常见问题排查速查表配置负载均衡之后日常运维会遇到一系列高频问题我整理了一个排查速查表现象可能原因解决思路502 Bad Gateway后端服务没启动或端口不对先curl后端地址确认服务是否正常504 Gateway Timeout后端处理时间太长Nginx等待超时调大proxy_read_timeout、proxy_send_timeout403 Forbidden目录权限不对或者SELinux拦截检查index文件是否存在目录是否有读权限请求总是打到同一台后端配置了ip_hash且来源IP固定确认业务是否需要粘滞否则改用轮询页面内容时而正常时而异常多台后端数据不一致Session串了排查Session共享方案或改ip_hash配置改了没生效忘记reload或语法检查失败nginx -t nginx -s reload上游日志里看不到真实IP缺少X-Forwarded-For等Header参考前面proxy_set_header的配置这些问题的共同排查思路其实就一句话先确认链路各环节是否正常。客户端到Nginx这一段用curl加-v看握手和响应头Nginx到后端这一段在Nginx的error.log里能看到具体报错后端应用本身的日志也不能漏。一层层排查下来大多数问题都能定位到具体环节。5.5 用Zabbix等工具监控Nginx的关键指标跑了负载均衡之后监控是必须跟上的。你不能等到用户投诉了才发现某台后端挂了。Nginx有一个自带的stub_status模块专门输出当前的连接状态数据。在server配置里加一个locationlocation /nginx_status { stub_status; access_log off; allow 127.0.0.1; deny all; }访问这个地址会返回类似这样的信息Active connections: 291 server accepts handled requests 16630948 16630948 31070465 Reading: 6 Writing: 179 Waiting: 106这里最值得关注的是三个数值Active connections表示当前活跃连接数Reading表示正在读取请求头的连接数Writing表示正在响应请求的连接数Waiting表示空闲连接数。如果Reading长期居高不下说明有慢客户端在拖累连接如果Writing很高说明后端响应速度可能有问题。Zabbix监控Nginx也是干这个事通过agent抓取stub_status的数值设置阈值报警。比如活跃连接数超过某个值就触发告警或者Writing持续超过某个阈值就检查后端负载。这样做的价值在于提前发现隐患而不是等问题爆了才去救火。除了连接数磁盘IO、网络流量、CPU负载这些系统指标也应该一起纳入监控毕竟Nginx再能扛底层资源被打满了一样会出问题。6. 安全加固与踩坑总结6.1 基础安全加固的几个必做项Nginx搞负载均衡之后安全性这块很多人会忽略。首先是版本问题,老版本Nginx可能存在一些已知漏洞建议安装最新稳定版并保持更新。其次是server_tokens这个配置默认情况下Nginx的响应头里会带版本号攻击者一看就知道你用的哪个版本方便针对性攻击。在nginx.conf的http块里加一行server_tokens off;这行配置能隐藏版本号付出的成本几乎为零建议所有环境都加上。还有一个容易被忽略的地方是备份文件。很多人在服务器上维护配置文件的时候习惯把旧配置文件改成nginx.conf.bak放在原目录里。如果这些备份文件落在Web可访问的目录下别人就能直接下载你的配置从而摸清你整个架构。这个风险在静态服务场景下尤其需要注意。配置文件要严格限制权限不要放在站点根目录下。6.2 从踩坑到形成自己的配置规范做Nginx配置这几年我最大的感受是配置本身不复杂复杂的是长期维护。刚开始我只是在nginx.conf里堆各种server和location到了后期整个文件乱得没法看改一处影响一大片。后来我总结了一套自己的配置规范分享出来供参考。第一一个服务一个文件。每个项目的server块单独放在conf.d/或者sites-available/下一个独立配置文件里命名清晰比如api-gateway.conf、blog.conf。第二公用的upstream和SSL配置抽出来放到子目录里统一include不要每个server块里重复写。第三每次上线前必须nginx -t检查语法并且保留上一个稳定版本的配置文件备份万一新配置有问题可以快速回滚。第四合理利用include把代理相关的通用Header配置、Gzip配置、缓存配置这些抽成片段文件不同的server按需引用。这样既减少了重复代码也降低了改配置时漏改或者错改的风险。7. 写在最后的一点实战心得关于Nginx搭建负载均衡洋洋洒洒写了不少最后想再说几句掏心窝的话。Nginx这个工具入门极快但深入进去之后你会发现它有非常多的细节和变数。我见过很多朋友拿着一份配置模板到处套出了问题就一筹莫展。其实真正有价值的不是那份配置而是对请求流转链路、对location匹配规则、对各种参数含义的理解。配置模板只是结果理解了原理之后你自然能根据业务场景做出最合理的设计。我自己的习惯是每排一个疑难问题都会把当时的配置、报错信息、排查过程记录下来。时间长了这些记录就是最有价值的排障手册。Nginx的官方文档其实写得很清楚但读文档和实战之间还是有距离的这个距离只能靠踩坑去填。希望这篇东西能帮你少踩一些我踩过的坑。如果你在配置过程中遇到什么问题欢迎带着具体场景和日志来交流这类问题通常都是越聊越清晰的。 Nginx负载均衡实战：从原理到配置、调优与排障
看到“Nginx搭建负载均衡”这个标题我估计不少朋友的第一反应是这不就是个upstream加proxy_pass的事儿吗网上教程一抓一大把。但真到自己上手配置或者接手一个已经跑着的集群时问题就来了——为什么我的请求总是打到同一台机器上为什么后端一挂整个服务就502为什么配了HTTPS前端却一直报证书错误还有被问烂了的“welcome to nginx怎么解决”。这几年我在生产环境里前前后后折腾过不少Nginx的活儿从单机转发到多节点集群从简单的轮询到根据业务场景调整策略踩过的坑比写过的配置都多。这篇东西我不打算给你抄一段配置就完事而是把搭建负载均衡从设计思路、配置细节、坑点排查到扩展玩法完整地捋一遍。内容会覆盖反向代理和负载均衡的关系、upstream的几种算法怎么选、location的工作流机制、HTTPS转发那些容易踩的证书坑还包括本地开发环境多站点配置、用Nginx代理Ollama这类AI服务、容器部署、以及被问得最多的并发连接数优化和访问日志排查。适合刚入门想搞清楚原理的初学者也适合部署过但总被各种疑难杂症折磨的运维和开发朋友。1. 先把思路理清楚负载均衡到底在解决什么问题1.1 为什么偏偏是Nginx做后端或者运维的朋友应该都有这种经历业务量一上来一台Web服务器扛不住了CPU飙到百分之八九十数据库连接被打满用户开始反映页面打开慢。这时候最直接的办法就是加机器。但加完机器之后有个问题——用户请求到底访问谁总不能让用户自己去记一堆IP地址吧。所以我们需要一个入口把请求按照一定的策略分发到后面的多台服务器上这就是负载均衡。市面上能做负载均衡的东西不少硬件有F5软件有LVS、HAProxy云厂商也有现成的SLB产品。但Nginx在这中间有一个很特别的生态位——它本身就是Web服务器又能做反向代理配置起来门槛低性能也够硬。单机Nginx能轻松扛住几万并发连接配合keepalived还能做高可用。更关键的是它的配置语法非常直观改完reload一下就好不像某些重量级方案动辄要重启服务、改一堆参数。所以不管是小公司起步阶段还是已经有一定规模的生产环境Nginx基本都是首选。1.2 反向代理和负载均衡是一回事吗这两个概念经常被放在一起说但严格来讲是两回事。反向代理是站在服务器角度代替后端服务器接收客户端请求再把请求转发给内部的实际服务。对客户端来说它不知道也不关心后面到底有几台服务器它只认反向代理这个入口。而负载均衡是在反向代理的基础上多了一个“把请求分发到不同后端”的能力。你可以这么理解反向代理解决的是“隐藏内部结构”的问题负载均衡解决的是“如何分配压力”的问题。Nginx做负载均衡的时候两者通常是叠加使用的。你对外暴露一个域名或者端口Nginx接收请求后根据配置好的策略把请求转发到upstream里定义的某一台后端机器上。后端服务器响应的内容再经由Nginx返回给客户端。这个过程中Nginx既是代理又是分发器。还有一点需要理清Nginx做负载均衡的时候默认是七层负载均衡工作在HTTP层能拿到URL、请求头、Cookie这些应用层信息所以可以做非常灵活的转发策略。如果你想做四层负载均衡基于IP和端口转发Nginx也有stream模块可以选择。大部分Web场景用七层就够了四层一般留给数据库或者内网服务。2. 动手搭建之前的环境准备与基础配置2.1 Nginx的安装没有那么复杂环境准备这一步本身不难但很多初学者的坑恰恰出在最初的安装环节。我见到的常见问题包括用yum装了个老版本导致某些模块用不了编译安装时少了一堆依赖反复报错还有的装完根本起不来看一眼错误日志才发现是配置文件里的注释符号写错了位置。在不同系统上安装Nginx方法不太一样。在CentOS或者RHEL系列上官方推荐添加Nginx的yum仓库然后安装这样能拿到最新的稳定版。在Ubuntu或者Debian上直接用apt安装也可以但默认仓库里的版本可能偏旧想要新特性的话同样建议添加官方PPA或直接用源码编译。# CentOS / RHEL 系列 sudo yum install epel-release sudo yum install nginx # Ubuntu / Debian 系列 sudo apt update sudo apt install nginx装完之后验证一下版本和启动状态。这里我多说一句装完Nginx之后第一件事不是急着改配置而是先访问一下服务器IP看看能不能看到默认的欢迎页。如果连默认页都看不到说明安装或者网络层面有问题这时候去改负载均衡配置只会让问题更难排查。源码编译安装的话核心命令大致是这样wget https://nginx.org/download/nginx-1.26.2.tar.gz tar -zxvf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure --prefix/usr/local/nginx --with-http_ssl_module --with-stream make make install编译安装的好处是能灵活控制模块比如你想要stream模块做四层转发或者想加一些第三方模块编译安装是最合适的。缺点就是升级维护稍微麻烦一点。个人建议如果没有特殊需求直接用系统包管理器安装的Nginx就够用省心很多。2.2 配置文件结构先看懂再动手改很多人拿到Nginx之后第一件事就是打开nginx.conf然后被里面密密麻麻的配置项吓到。其实没那么复杂Nginx的配置是分层的核心结构可以概括为主配置文件负责全局设置http块里定义虚拟主机server每个server块里定义具体的location转发规则。以yum安装的Nginx为例主配置文件在/etc/nginx/nginx.conf。里面会有一行“include /etc/nginx/conf.d/*.conf;”这是把conf.d目录下所有的conf文件都加载进来。所以我强烈建议不要把所有配置都堆在nginx.conf里而是在conf.d目录下按项目建独立的配置文件比如web1.conf、api.conf这样每个服务的配置互不干扰出了问题也好排查。# 一个典型的server配置块长这样 server { listen 80; server_name example.com; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }理解这个结构是后续所有操作的地基。以后不管是配负载均衡、搞HTTPS、还是做多站点都是在server和location这两层做文章。3. 核心配置实战从单机转发到负载均衡集群3.1 upstream与proxy_pass的配合负载均衡的核心配置其实就两块一个upstream块定义后端服务器列表一个proxy_pass把请求转发到这个upstream。http { upstream backend_servers { server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; server 192.168.1.12:8080 backup; } server { listen 80; server_name example.com; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }这段配置里upstream定义了一个叫backend_servers的后端组包含三台服务器。第一台权重是3第二台权重是1意味着正常情况下每4个请求里有3个打到第一台1个打到第二台。第三台设置了backup参数意味着它是备用节点——只有前两台都挂了的时候才会转发到它。这里有个细节值得展开说一下proxy_set_header这几行配置非常关键。如果不把Host、X-Real-IP、X-Forwarded-For这些头传给后端后端程序拿到的客户端IP全是Nginx的IP日志里看不到真实访客有些依赖IP做限制的功能也会全部失效。尤其是X-Forwarded-For后面的程序如果要做访问频率限制或者风控判断这个头是必须的。3.2 负载均衡算法选型别无脑用轮询Nginx的负载均衡策略有好几种默认是轮询round-robin也就是按顺序轮流把请求分配到每台后端。但实际生产环境中轮询并不总是最优解。常用的策略有这么几种轮询默认每个请求按时间顺序逐一分配到不同的后端。适合后端服务器配置差不多的场景。加权轮询通过weight参数控制每台服务器的流量比例适合服务器性能有差异的情况。ip_hash按客户端IP的哈希结果分配同一个IP的请求会固定打到同一台后端。这个策略很适合需要Session粘滞的场景但缺点是如果某一台后端挂了它承载的那部分用户会受影响而且负载可能不均衡。least_conn把请求发给当前活跃连接数最少的后端。适合请求处理时间差异较大的业务。fair按后端服务器响应时间长短来分配响应快的优先分配。这个需要第三方模块支持默认没带。我在实际项目中用得最多的是加权轮询和ip_hash的组合逻辑——前端Nginx用加权轮询后端服务做无状态化Session放在Redis里这样既保证了负载均衡又不会因为请求打到不同机器导致用户登录状态丢失。如果业务确实有粘滞需求比如某些老系统Session放在本地那就只能用ip_hash了但得接受它带来的负载不均问题。upstream backend_servers { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; }还有一个参数容易被忽略fail_timeout和max_fails。这俩配合起来控制Nginx对后端健康状态的判断。比如配置max_fails2 fail_timeout30s意味着一台后端在30秒内如果有2次转发失败Nginx会认为它挂了接下来30秒内不再给它转发请求。这个机制能起到简单的健康检查效果但它是被动的——只有请求转发失败了才知道后端有问题。如果需要主动健康检查简单场景可以靠这个参数更精细的场景建议引入nginx_upstream_check_module或者直接用云负载均衡的主动探测。3.3 location匹配机制不搞清楚这个配置就是玄学location匹配是所有Nginx配置里面最容易被搞糊涂的地方。我见过不少朋友在location里写了一大堆规则结果访问的URL老是跑到别的地方去最后只能靠试错来猜。Nginx的location匹配规则其实是有一套严格优先级的。简单来说优先级从高到低是这样精确匹配。如果请求的URI和这个字符串完全一样直接命中。^~前缀匹配一旦命中就不再检查后续的正则。~和~*正则匹配。波浪号开头的区分大小写波浪号加星号的不区分。普通前缀匹配。按前缀的匹配程度选最长的那个。举个例子你的server里同时配置了location /和location /api/那么访问/api/login的时候会走location /api/因为普通前缀匹配时Nginx会选择匹配最长的前缀。但如果你的location /api/没有加^~同时配置文件里还有其他正则location那情况就变得复杂了——正则location会在所有普通前缀匹配都确定之后再进行一次检查如果正则匹配上了它会覆盖普通前缀的结果。这段逻辑用文字描述比较绕但在实际配置里我建议遵循一个原则能用和^~搞定的就不要用正则。比如静态资源目录直接写location ^~ /static/ { ... }这样命中之后就不会再去做正则匹配效率更高行为也更好预判。3.4 静态文件与动态请求分离前面说的都是将请求转发给后端的反向代理配置但有一个非常常见的性能优化手段值得单独提一下——静态文件直接由Nginx处理只有动态请求才转发给后端。做法其实就是在location里区分不同路径location /static/ { alias /data/project/static/; expires 7d; access_log off; } location / { proxy_pass http://backend_servers; }这样做的效果非常明显。图片、CSS、JavaScript这些静态资源不必经过后端应用服务器Nginx处理静态文件的性能远高于一般的应用服务器而且expires设置还能让浏览器缓存静态资源大大减少重复请求。我曾经接手过一个项目后端Tomcat的CPU负载一直很高排查后发现大量的静态资源请求都打到了Tomcat上做了这个分离之后CPU直接降了一半还多。4. 场景扩展从单机负载均衡到多环境多服务4.1 本地虚拟机多端口多站点配置做开发的时候经常遇到一个需求本地起了一堆服务想用自定义域名访问不同项目不想每次敲IP加端口。比如项目A在宿主机的8080端口项目B在8081项目C在8082你想通过a.local、b.local这种域名来访问。这个场景在Nginx里配置起来非常顺手。关键是两件事一是hosts文件里做域名解析二是Nginx里每个server块监听80端口但用不同的server_name区分。# /etc/nginx/conf.d/vhost.conf server { listen 80; server_name a.local; location / { proxy_pass http://127.0.0.1:8080; } } server { listen 80; server_name b.local; location / { proxy_pass http://127.0.0.1:8081; } }Windows上的hosts文件在C:\Windows\System32\drivers\etc\hostsLinux在/etc/hosts。加上这几行127.0.0.1 a.local 127.0.0.1 b.local很多人配置完发现不起作用原因一般是两个一是浏览器缓存了DNS解析结果换隐身模式试试就好二是Nginx的server_name和请求的Host头不匹配如果直接用IP访问Nginx只会走默认的第一个server块。这个方案调试起来非常方便而且和生产环境的域名转发行为是一致的本地验证通过了再上服务器能省不少事。4.2 HTTPS转发与证书校验的坑现在基本没有纯HTTP的服务了HTTPS是标配。但Nginx做HTTPS反向代理的时候有一堆小坑其中被问得最多的就是net::ERR_CERT_COMMON_NAME_INVALID。这个报错的含义是浏览器访问的域名和服务器返回的证书里的Common Name或者Subject Alternative Name不匹配。场景通常是这样——你的Nginx配置了443端口的HTTPS监听证书也配置好了浏览器直接访问Nginx是正常的但一旦请求经过Nginx转发到后端HTTPS服务后端返回的页面里引用的资源链接和证书域名不一致浏览器就会拦截。解决的思路分几种如果后端是HTTP服务Nginx这边只要配好证书就行转发的后端用proxy_pass http://浏览器和Nginx之间是HTTPSNginx和后端之间是HTTP这是最常见的架构。如果后端也是HTTPS而且不想跳过证书校验那需要给proxy_pass https://...加上proxy_ssl_server_name on;和proxy_ssl_name来传递正确的SNI。如果是为了调试方便直接跳过校验可以在location里加location / { proxy_pass https://backend_service; proxy_ssl_verify off; }但我不建议生产环境这么干。隐患很明显——中间人攻击的风险会大幅上升而且这类问题一旦出现线上排查比本地麻烦得多。还有一个值得注意的点配置HTTPS时旧客户端或者某些爬虫工具可能会用HTTP来访问你的443端口这时候最好配置一个HTTP跳转HTTPS的策略server { listen 80; server_name example.com; return 301 https://$host$request_uri; }4.3 用Nginx代理Ollama等AI服务最近AI相关的服务火得快不少朋友在自己的机器上跑起来了Ollama、CherryStudio这类工具。这里的典型需求是Ollama默认监听11434端口我想把它暴露给内网的其他电脑或者某个Web前端调用但不想让所有人直接访问原始端口更不想把API Key明文暴露在前端代码里。Nginx在这个场景里做一层代理既隐藏了Ollama的真实端口又可以在代理层拦截不受信任的请求。配置大概是这样的server { listen 11435; server_name _; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }如果是给CherryStudio这类前端工具用还需要考虑一个细节前端调用Ollama时通常会直接将服务的地址配到设置里。如果前端代码里写死了一个API Key而这个Key又被别人从浏览器里抠出来那等于没有防护。所以更稳妥的做法是在Nginx层面做一个简单的鉴权过滤比如要求请求头里带着自定义的Header才放行不满足条件的请求直接返回403。这样即使端口暴露了别人没有正确的Header也调用不了。4.4 容器部署Nginx时的配置挂载问题用Docker跑Nginx的场景现在也很普遍。基础命令大概是这样的docker run -d --name nginx-gateway \ -p 80:80 -p 443:443 \ -v /opt/nginx/conf.d:/etc/nginx/conf.d:ro \ nginx:stable很多朋友在挂载conf.d目录时碰到一个老坑容器起不来日志里报错说Nginx配置格式有问题。实际情况往往是你宿主机上的conf.d目录权限或者SELinux上下文不对容器内的Nginx没有权限读取。另外还要注意官方Nginx镜像里的nginx.conf本身就有一行include /etc/nginx/conf.d/*.conf;所以你挂载的conf.d目录里最好只放.conf后缀的配置文件别放乱七八糟的备份文件——Nginx会把所有.conf文件都当配置加载备份文件如果命名成.conf结尾大概率会报语法错误。在容器里跑Nginx还有一个容易忽略的点如果后端服务也在容器里并通过容器网络互通那么upstream里的server地址应该写容器服务名而不是127.0.0.1。比如后端容器叫app-service配置里就应该写upstream backend { server app-service:8080; }这个细节在docker-compose环境里尤其常见。你宿主机上明明访问得通但容器内访问127.0.0.1访问的是Nginx容器自己当然连不上后端的服务。5. 提升稳定性监控、调优与常见问题排查5.1 看到“Welcome to nginx”别慌“welcome to nginx怎么解决”这个问题在网上被搜索的次数非常惊人。这个页面本身说明Nginx已经安装成功并且正常工作了但你想访问自己的服务却发现一直停留在这个欢迎页原因基本可以归结为两类。第一类你压根没配置自己的server块或者配置了但没把浏览器实际访问的域名写进server_name。Nginx默认的欢迎页配置其实就藏在conf.d目录下的default.conf在Debian系的镜像里它监听80端口server_name是_兜底匹配所有访问。你新建的server块如果没有被正确加载或者加载顺序导致default.conf先匹配了请求就到默认页了。第二类你配置了server块但语法错误Nginx reload失败服务还是跑在旧配置上。解决思路很简单——先用nginx -t检查配置语法再nginx -s reload重载配置最后直接curl访问你的域名看响应头。nginx -t nginx -s reload curl -I http://your-domain.com这里额外提醒一句如果你的Nginx是通过apt安装的配置目录结构是/etc/nginx/sites-enabled不要直接在sites-enabled里改文件而是应该在sites-available里创建配置然后做软链接。这是Debian系在管理多站点时特有的风格硬在sites-enabled里改文件虽然也能生效但不符合习惯升级或者重装的时候容易乱。5.2 Nginx最大并发连接数的限制和调优“Nginx最大并发链接数老是用超”是很多站长朋友的真实痛点。首先要明白一个概念Nginx能承载的并发连接数不只取决于Nginx本身的配置还取决于操作系统内核的限制以及每个worker进程能打开的文件描述符数量。Nginx配置里有个经典的计算公式最大并发连接数 worker_processes × worker_connections。如果你设置了worker_processes为4worker_connections为1024那么理论上最大并发是4096。但这里有个隐藏的前提你的系统文件描述符限制要足够大。默认的ulimit通常只有1024Nginx一个连接就要占用一个文件描述符所以需要同步调大这两个限制worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 2048; use epoll; }worker_processes设为auto会让Nginx根据CPU核数自动调整。worker_connections设为2048的情况下四核机器的理论并发就是8192。同时还需要在系统层面修改文件描述符限制ulimit -n 65535这样改完之后之前“并发一高就超”的问题基本能缓解。但需要注意的是如果你的后端应用服务器处理能力有限把并发调得再高也没用请求只会积压在后端。负载均衡的意义不是让Nginx扛下所有压力而是把压力均匀地分散到后端的每一台机器上。5.3 Windows环境查看Nginx日志很多人在Windows上开发调试Nginx也是可以直接跑的。Windows版的Nginx日志默认在安装目录下的logs文件夹里access.log记录每次请求的详细信息error.log记录错误和警告。但Windows上查看日志文件有一个比较头疼的问题文件被Nginx进程占用用记事本打开有时候看不到实时更新的内容或者文件太大打不开。我之前用Windows调试Nginx时更喜欢用PowerShell加上Select-String做关键字检索。比如要看某个IP的访问记录Get-Content -Path C:\nginx\logs\access.log -Tail 100 | Select-String 192.168.1.100如果日志文件特别大直接完整读文件会卡死这种情况下用-Tail只看末尾最新的记录或者用日志分析工具来解析。有人问过有没有专门看Nginx日志的图形化工具Windows上的选择确实不如Linux那么丰富简单场景用命令行就够数据量大了建议还是把日志集中收集到ELK或者Loki里做可视化分析。5.4 各大常见问题排查速查表配置负载均衡之后日常运维会遇到一系列高频问题我整理了一个排查速查表现象可能原因解决思路502 Bad Gateway后端服务没启动或端口不对先curl后端地址确认服务是否正常504 Gateway Timeout后端处理时间太长Nginx等待超时调大proxy_read_timeout、proxy_send_timeout403 Forbidden目录权限不对或者SELinux拦截检查index文件是否存在目录是否有读权限请求总是打到同一台后端配置了ip_hash且来源IP固定确认业务是否需要粘滞否则改用轮询页面内容时而正常时而异常多台后端数据不一致Session串了排查Session共享方案或改ip_hash配置改了没生效忘记reload或语法检查失败nginx -t nginx -s reload上游日志里看不到真实IP缺少X-Forwarded-For等Header参考前面proxy_set_header的配置这些问题的共同排查思路其实就一句话先确认链路各环节是否正常。客户端到Nginx这一段用curl加-v看握手和响应头Nginx到后端这一段在Nginx的error.log里能看到具体报错后端应用本身的日志也不能漏。一层层排查下来大多数问题都能定位到具体环节。5.5 用Zabbix等工具监控Nginx的关键指标跑了负载均衡之后监控是必须跟上的。你不能等到用户投诉了才发现某台后端挂了。Nginx有一个自带的stub_status模块专门输出当前的连接状态数据。在server配置里加一个locationlocation /nginx_status { stub_status; access_log off; allow 127.0.0.1; deny all; }访问这个地址会返回类似这样的信息Active connections: 291 server accepts handled requests 16630948 16630948 31070465 Reading: 6 Writing: 179 Waiting: 106这里最值得关注的是三个数值Active connections表示当前活跃连接数Reading表示正在读取请求头的连接数Writing表示正在响应请求的连接数Waiting表示空闲连接数。如果Reading长期居高不下说明有慢客户端在拖累连接如果Writing很高说明后端响应速度可能有问题。Zabbix监控Nginx也是干这个事通过agent抓取stub_status的数值设置阈值报警。比如活跃连接数超过某个值就触发告警或者Writing持续超过某个阈值就检查后端负载。这样做的价值在于提前发现隐患而不是等问题爆了才去救火。除了连接数磁盘IO、网络流量、CPU负载这些系统指标也应该一起纳入监控毕竟Nginx再能扛底层资源被打满了一样会出问题。6. 安全加固与踩坑总结6.1 基础安全加固的几个必做项Nginx搞负载均衡之后安全性这块很多人会忽略。首先是版本问题,老版本Nginx可能存在一些已知漏洞建议安装最新稳定版并保持更新。其次是server_tokens这个配置默认情况下Nginx的响应头里会带版本号攻击者一看就知道你用的哪个版本方便针对性攻击。在nginx.conf的http块里加一行server_tokens off;这行配置能隐藏版本号付出的成本几乎为零建议所有环境都加上。还有一个容易被忽略的地方是备份文件。很多人在服务器上维护配置文件的时候习惯把旧配置文件改成nginx.conf.bak放在原目录里。如果这些备份文件落在Web可访问的目录下别人就能直接下载你的配置从而摸清你整个架构。这个风险在静态服务场景下尤其需要注意。配置文件要严格限制权限不要放在站点根目录下。6.2 从踩坑到形成自己的配置规范做Nginx配置这几年我最大的感受是配置本身不复杂复杂的是长期维护。刚开始我只是在nginx.conf里堆各种server和location到了后期整个文件乱得没法看改一处影响一大片。后来我总结了一套自己的配置规范分享出来供参考。第一一个服务一个文件。每个项目的server块单独放在conf.d/或者sites-available/下一个独立配置文件里命名清晰比如api-gateway.conf、blog.conf。第二公用的upstream和SSL配置抽出来放到子目录里统一include不要每个server块里重复写。第三每次上线前必须nginx -t检查语法并且保留上一个稳定版本的配置文件备份万一新配置有问题可以快速回滚。第四合理利用include把代理相关的通用Header配置、Gzip配置、缓存配置这些抽成片段文件不同的server按需引用。这样既减少了重复代码也降低了改配置时漏改或者错改的风险。7. 写在最后的一点实战心得关于Nginx搭建负载均衡洋洋洒洒写了不少最后想再说几句掏心窝的话。Nginx这个工具入门极快但深入进去之后你会发现它有非常多的细节和变数。我见过很多朋友拿着一份配置模板到处套出了问题就一筹莫展。其实真正有价值的不是那份配置而是对请求流转链路、对location匹配规则、对各种参数含义的理解。配置模板只是结果理解了原理之后你自然能根据业务场景做出最合理的设计。我自己的习惯是每排一个疑难问题都会把当时的配置、报错信息、排查过程记录下来。时间长了这些记录就是最有价值的排障手册。Nginx的官方文档其实写得很清楚但读文档和实战之间还是有距离的这个距离只能靠踩坑去填。希望这篇东西能帮你少踩一些我踩过的坑。如果你在配置过程中遇到什么问题欢迎带着具体场景和日志来交流这类问题通常都是越聊越清晰的。