一、为什么要先理解 Nginx 处理请求的流程¶

很多人在学 Nginx 配置时，会先接触 server_name、root、location 这些指令，但如果不知道一次请求是怎么被处理的，就容易把这些配置看成零散的语法点。

原笔记先通过一个现象引出问题：

已经搭建好的 cxk.oldboylinux.cn 站点，使用域名访问没有问题
如果改动配置文件名，或者直接用 IP 访问，请求可能会落到另一个静态站点

这说明 Nginx 并不是“随便找一个站点返回内容”，而是有一套明确的请求处理逻辑。

二、域名访问一个网站会经历哪些步骤¶

原笔记把使用域名访问网站的过程拆成了六个阶段。

2.1 DNS 解析¶

首先，浏览器或系统需要把域名解析为 IP 地址。
例如：

cxk.oldboylinux.cn
先解析成对应服务器 IP

没有这一步，客户端根本找不到要连接的主机。

2.2 与目标端口建立连接¶

获得 IP 后，客户端会和网站监听的端口建立 TCP 连接。
原笔记这里强调的是：

网站默认常用端口是 80
建立连接依赖 TCP 三次握手

只有连接建立成功，后面的 HTTP 请求才能发出去。

2.3 客户端发送 HTTP 请求报文¶

连接建立后，客户端会发出 HTTP 请求，原笔记中给出的关键内容包括：

GET /index.html
Host: cxk.oldboylinux.cn
User-Agent: Chrome/xxx

这里最重要的信息有三类：

请求方法，例如 GET
请求 URI，例如 /index.html
Host 头，也就是用户访问的域名

其中 Host 头对 Nginx 的虚拟主机匹配非常关键。

2.4 Nginx 在服务端开始处理请求¶

原笔记把 Nginx 的处理过程概括得很清楚：

请求先进入 http 区域
然后进入某个具体的 server {} 区域处理
匹配时会关注端口
也会根据用户请求中的域名和 server_name 进行匹配
匹配成功后，再结合 root、location 和 index 去查找实际文件

也就是说，Nginx 至少会回答三个问题：

1、这个请求进的是哪个端口
2、这个域名该由哪个 server {} 处理
3、具体该返回站点目录里的哪个文件

2.5 Nginx 返回 HTTP 响应报文¶

文件找到之后，Nginx 会向客户端返回响应内容。
原笔记提到响应里通常会包含：

状态码，例如 200 OK
Server 等响应头信息
实际文件内容

如果文件不存在、权限不对或者命中了别的站点规则，状态码和返回结果也会随之变化。

2.6 浏览器解析并展示页面¶

客户端收到响应后，浏览器再对 HTML、CSS、JS、图片等内容进行解析，最终把页面展示给用户。

从用户角度看只是“打开了一个网站”，但从服务端角度看，前面已经经过了完整的一条处理链路。

三、为什么域名访问和 IP 访问可能得到不同结果¶

原笔记专门提醒了一个很容易忽略的问题：

域名访问时，会带上明确的 Host
直接用 IP 访问时，匹配结果可能不同

如果请求里的域名无法和某个 server_name 对应上，Nginx 就可能：

落到默认 server
或者在没有显式默认配置时，按配置顺序选择第一个可处理的 server {}

这就是为什么同一台机器上部署了多个站点后：

用域名访问是一个站
用 IP 访问可能却是另一个站

四、学习 Nginx 配置时应该抓住哪些关键点¶

结合原笔记这一节，可以把处理流程中的关键配置点总结为：

listen：决定请求进入哪个端口
server_name：决定域名匹配到哪个虚拟主机
root：决定站点目录在哪里
location：决定 URI 命中哪条规则
index：决定默认首页文件

这些指令并不是孤立存在的，而是共同参与了一次请求的完整处理。

五、小结¶

理解 Nginx 的请求处理流程之后，再去看虚拟主机、日志和 location 匹配就会更轻松。
因为你会知道：用户访问网站时，不只是“读一个文件”，而是先匹配端口和域名，再进入具体站点规则，最后才把对应内容返回给浏览器。

Nginx处理请求流程详解：从DNS到server_name匹配