nginx首先决定要用配置文件里的哪个server{}块来处理，假设有下面的server{}配置
server {
listen 80;
server_name aaa;
...
}
server {
listen 80;
server_name bbb;
...
}
nginx会根据过来的http请求头里的Host字段里的值，来判断使用哪个server{}。
如果请求头里没有Host字段，或者Host字段里的值，和Nginx配置文件里的server{}里的{server_name}都不匹配，则使用第一个server{}，来处理这个请求。
如果请求头里的Host字段里的值和Nginx配置文件里的某个server{}里的{server_name}，匹配上了，则使用这个server{}，来处理这个请求。
可以使用curl工具来方便的做实验，curl可以设置http请求的请求头，所以可以任意设置Host字段，用【-H】来设置。下面的10.210.65.73是安装了nginx的机器的IP地址。
所以用下面的命令，发送了http请求后，nginx就会使用server{server_name aaa}来处理这个请求。
curl.exe -H "Host: aaa" 10.210.65.73
非常重要的结论：server_name对应的是http请求头里的Host字段的值，有了上面的理论支撑，就可以很容易的设置反向代理和负载均衡：
当过来的http请求头里的Host字段为aaa时，storage.test来处理。
当过来的http请求头里的Host字段为bbb时，tracker.test来处理。
#负载均衡配置，IP为129的机器配置高，所以给他的数字的27，就是让它多处理
upstream storage.test {
server 10.210.65.129:80 weight=27;
server 10.210.65.130:80 weight=1;
}
#负载均衡配置
upstream tracker.test {
server 10.210.65.52:80 weight=7;
server 10.210.65.53:80 weight=2;
}
#文件的存储
server {
listen 80;
server_name aaa;
location / {
#http:://后面的内容是自己定义,对应上面upstream的名字
proxy_pass http://storage.test;
}
}
#文件服务器tracker
server {
listen 80;
server_name bbb;
location / {
#http:://后面的内容是自己定义的，对应上面upstream的名字
proxy_pass http://tracker.test;
}
}
server{}里的listen监听的是谁的端口？
监听的是：发送过来http请求的进程（大部分是浏览器）的端口（如果是http请求，则为端口为80），不是nginx服务器自己进程的端口。
nginx根据http请求头的Host字段里的值，和发送过来http请求的进程（大部分是浏览器）的端口，来决定使用哪个server{}来处理http请求。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。
nginx,处理,http,请求
这一波大模型产业落地浪潮里，不少企业其实处在 “干瞪眼“的状态。
一种情况是，很多大模型产品看得见却摸不着，在台上一个个遥遥领先——今天Sora技精四座，明天英伟达的机器人又赢得满堂彩，可是到了台下一问：啥时候能用上啊？答曰：遥遥无期。
另一种情况是，企业想用上大模型，却又难免瞻前顾后——既要考虑场景融合，又得兼顾安全性，还要考虑打通现有系统，再加上各种部署成本和繁琐的采购流程……最后只能拂袖：罢了，再等等吧。
稳了！魔兽国服回归的3条重磅消息！官宣时间再确认！
昨天有一位朋友在大神群里分享，自己亚服账号被封号之后居然弹出了国服的封号信息对话框。
这里面让他访问的是一个国服的战网网址，com.cn和后面的zh都非常明白地表明这就是国服战网。
而他在复制这个网址并且进行登录之后，确实是网易的网址，也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情，因为以前都没有出现这样的情况，现在突然提示跳转到国服战网的网址，是不是说明了简体中文客户端已经开始进行更新了呢？