初识Nginx

Nginx基本介绍基本的目录结构confsbinhtmllogsxxx_temp (运行时候的一些缓存)conf nginx中的主配置文件html nginx中默认的静态资源和网页logs 记录访问日志access.log 访问日志error.log 错误日志nginx.pid 记录nginx的id号在 Linux 或 Unix 系统中ps -ef是一个常用的命令用于显示当前系统中所有进程的详细信息。其中-ef是ps命令的一个选项参数具体含义如下-e显示所有进程包括系统守护进程以及其他用户的进程。-f以完整的格式显示进程的详细信息包括进程的 PID进程标识符、PPID父进程标识符、状态、运行时间、CPU 占用率等。Nginx基本请求流程主进程fork出来多个进程来完成用户请求主进程协调子进程Nginx的基本配置nginx.conf 的基本配置 以下是删除注释的简化版(最小配置)worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } }worker_processes 1;开启多少个子进程这个数字基本上对应CPU的物理CPU内核数events { worker_connections 1024; }events 这是 Nginx 配置块专门用于设置与连接处理相关的事件模型参数worker_connections 1024;表示每个 Nginx 工作进程worker process最多可以同时处理1024 个并发连接。。http { .... }Nginx 的核心配置块包含所有 HTTP 协议相关的配置如反向代理、静态资源、MIME 等所有server块都嵌套在这个块里。include mime.types;includeNginx 的配置导入指令用来加载外部配置文件类似代码里的 “引入包”避免主配置文件过于臃肿。mime.typesNginx 自带的 MIME 类型映射文件默认路径/etc/nginx/mime.types里面定义了 “文件后缀” 和 “MIME 类型” 的对应关系。举个实际例子当浏览器请求https://xxx.com/test.jpg时Nginx 会先查mime.types发现.jpg对应的 MIME 类型是image/jpeg然后 Nginx 在响应头中返回Content-Type: image/jpeg浏览器拿到这个响应头就知道这是一张图片会正确渲染而不是当成文本下载。如果没有include mime.types;Nginx 会默认把所有文件的Content-Type设为application/octet-stream浏览器收到后会直接触发 “下载”而不是正常显示图片、CSS、JS 等资源。default_type application/octet-stream;默认类型如果不包含在mime.types则以application/octet-stream;的方式传递给客户端。application/octet-stream是一种 Internet 媒体类型也被称为 MIME 类型它通常用于表示未知或二进制数据的内容类型。sendfile on;sendfile是一种零拷贝技术可以在内核空间和用户空间之间直接传输文件数据而无需通过用户空间进行数据复制。这样可以显著提高文件传输的效率和性能。当sendfile设置为on时Nginx 将尝试使用 sendfile 机制来传输文件。在处理静态文件或大文件下载等场景下这个选项通常建议开启因为它可以减少 CPU 和内存的使用提高数据传输速度。需要注意的是在某些特定的环境或操作系统上sendfile可能会导致一些问题例如与某些反向代理或网络加速设备不兼容。如果遇到问题你可以尝试将sendfile设置为off禁用该功能然后重新加载 Nginx 配置。server {listen 80;server_name localhost;定义了一个监听端口为 80 的服务器并将其命名为 localhost。这意味着该服务器将监听来自该端口的传入请求location / {root html;index index.html index.htm;}这一部分配置了请求路径为/的位置。它指定了网页文件的根目录为html并指定了默认的索引文件为index.html或index.htm。当用户请求该服务器上的根路径时将返回存储在html目录下的index.html或index.htm文件。error_page 500 502 503 504 /50x.html;location /50x.html {root html;}如果出现 500、502、503 或 504 错误的情况下将返回一个特定的错误页面/50x.html。该页面同样位于html目录下。Nginx虚拟主机与域名解析浏览器、Nginx与HttpHttps协议浏览器、Nginx 和 HTTPHTTPS协议是构成 web 网络通信的重要组成部分。以下是它们之间的关系和简要介绍浏览器Browser 浏览器是用于访问和浏览网页的客户端应用程序例如 Google Chrome、Mozilla Firefox、Microsoft Edge 等。浏览器负责发送 HTTP 请求到服务器并解析和渲染服务器返回的 HTML、CSS、JavaScript 等资源以呈现给用户。Nginx Nginx 是一款高性能的开源 Web 服务器软件。它可以作为反向代理服务器、负载均衡器和缓存服务器等用于处理和转发浏览器发送的请求。Nginx 提供了强大的性能和可扩展性能够同时处理大量的并发连接。HTTPHypertext Transfer Protocol HTTP 是一种用于在 web 浏览器和服务器之间传输数据的协议。它采用客户端-服务器模型通过请求-响应的方式在浏览器和服务器之间进行通信。HTTP 协议是无状态的每个请求都是独立的并且不会保存之前的状态信息。HTTPSHTTP Secure HTTPS 是基于 HTTP 的加密安全版本。它使用 SSLSecure Sockets Layer或 TLSTransport Layer Security协议来加密传输的数据提供更安全的通信。使用 HTTPS 可以保护用户的隐私和数据安全防止被第三方篡改或窃取。当浏览器与服务器进行通信时浏览器发送 HTTP 请求到服务器的特定端口通常是 80 或 443Nginx 作为 web 服务器接收这些请求并处理。对于 HTTPS 请求Nginx 会使用 TLS/SSL 协议解密请求并将解密后的请求转发给后端服务器。然后服务器处理请求并生成 HTTP 响应再通过 Nginx 返回给浏览器最终由浏览器解析和渲染响应中的内容。虚拟主机原理虚拟主机是一种在同一台物理服务器上托管多个域名或网站的技术。Nginx 是一个强大的 Web 服务器软件可以通过虚拟主机配置来处理多个域名和网站。下面是 Nginx 虚拟主机的原理基于域名的虚拟主机Nginx 可以根据请求中的域名不同将请求分发给不同的虚拟主机进行处理。这被称为基于域名的虚拟主机。Nginx 会检查每个请求的 “Host” 头部字段根据配置文件中的域名匹配规则将请求发送到对应的虚拟主机配置中。配置文件 在 Nginx 的配置文件中每个虚拟主机都需要定义一个 server 块。在 server 块中你可以指定域名、监听的端口、文件路径、代理规则等。例如server { listen 80; server_name example.com; root /var/www/example; … }上述配置表示针对 example.com 的请求Nginx 会监听端口 80并将请求转发到/var/www/example目录下的文件进行处理。默认服务器 如果请求中的域名与任何虚拟主机的 server_name 都不匹配Nginx 会将请求发送到默认服务器default server。默认服务器配置可以通过以下方式定义server { listen 80 default_server; … }HTTPS 和 SSL 配置 对于使用 HTTPS 的虚拟主机你需要配置 SSL 证书和相应的加密设置。可以通过添加 ssl 相关的指令来启用 SSL 支持并指定证书的路径等配置。例如server { listen 443 ssl; server_name example.com; ssl_certificate /path/to/cert.crt; ssl_certificate_key /path/to/private.key; … }上述配置表示针对 example.com 的 HTTPS 请求Nginx 会监听端口 443并使用指定的证书和私钥进行加密通信。http { # 全局配置 # 定义默认服务器 server { listen 80 default_server; server_name _; # 默认服务器的配置 } # 虚拟主机1 server { listen 80; server_name example1.com; # 虚拟主机1 的配置 } # 虚拟主机2 server { listen 80; server_name example2.com; # 虚拟主机2 的配置 } # HTTPS 虚拟主机 server { listen 443 ssl; server_name secure.example.com; ssl_certificate /path/to/cert.crt; ssl_certificate_key /path/to/private.key; # HTTPS 虚拟主机的配置 } }上述配置中全局配置位于http块内可以在其中定义一些全局设置例如日志路径、缓存策略等。默认服务器定义了一个监听端口为 80 的默认服务器用于处理没有匹配的域名请求。server_name _表示匹配任何未定义的域名。虚拟主机1 和虚拟主机2 分别定义了两个监听端口为 80 的虚拟主机使用不同的域名进行区分。HTTPS 虚拟主机使用listen 443 ssl来监听端口并配置了 SSL 证书和私钥。通过合理配置虚拟主机Nginx 可以高效地处理多个域名和网站的请求并提供可靠的性能和资源隔离。这使得 Nginx 成为托管多个网站的常用选择。域名解析配置本地host文件外网域名需要备案然后去各自的运营商上面手动解析。这里我们以本地host 文件作为测试host文件一般在windows中的路径如下C:\Windows\System32\drivers\etc\hosts需要注意的是这里配置需要管理员权限如果没有好用的工具可以copy一个到桌面修改以后替换请注意不要修改到你的默认配置新的配置应该加到后面修改完成以后使用cmd 执行如下命令 刷新dns缓存配置Nginx虚拟主机域名通过刚才修改的host文件以后我们发现并不能直接访问我们刚才的域名,这里是因为我们在nginx中没有对虚拟主机进行配置。首先创建2个站点并且分别创建index.html作为默认文件其中 /vp1/index.html 内容为 im vp1其中 /vp2/index.html 内容为 im vp2配置nginxworker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } # vp1 server { listen 80; server_name vp1.com; location / { root /www/vp1; # 目录 index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } # vp2 server { listen 80; server_name www.vp2.com; location / { root /www/vp2; # 目录 index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } }修改完成以后应该重启nginxsystemctl restart nginx或者重载配置(systemctl reload nginx) 并且使用(systemctl status nginx) 检查所有的配置修改都应该有检查这一步。Nginx反向代理反向代理图正向代理图反向代理服务器在系统架构中的应用场景做伪静态Nginx 通过使用伪静态也称为 URL 重写来实现对动态网页的静态化处理。伪静态可以将动态生成的 URL 重写为看起来像静态页面的 URL从而提升网站性能和 SEO 友好性比如把index.php?id123变成article/123.html既提升 SEO 友好度又能隐藏后端技术栈以下是一个使用 Nginx 实现伪静态的示例配置server { listen 80; server_name example.com; root /path/to/website; location / { try_files $uri $uri/ rewrite; } location rewrite { rewrite ^/(.*)$ /index.php?r$1 last; } location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }上述配置假设网站的根目录是/path/to/website并且通过一个 PHP 脚本index.php处理动态页面。这个配置中首先尝试直接访问请求的文件try_files $uri $uri/。如果请求的文件不存在则转到rewrite块进行 URL 重写。try_files指令的作用是尝试直接访问请求的文件首先Nginx 会尝试直接访问$uri所表示的文件。如果该文件存在则 Nginx 会直接返回该文件的内容作为响应。尝试访问添加斜杠的目录如果第一步访问文件不存在Nginx 会尝试访问$uri/所表示的目录。如果该目录存在并且包含默认的索引文件如index.html、index.php则 Nginx 会返回该索引文件的内容作为响应。进入下一步处理如果前两步都没有找到可访问的文件或目录Nginx 将执行下一步的处理规则。这里的rewrite是一个命名 location表示进一步处理请求的阶段。在示例配置中try_files $uri $uri/ rewrite;指定了以下处理逻辑尝试直接访问请求的文件例如/example.html。如果文件不存在尝试访问添加斜杠的目录例如/example/。如果目录不存在或者没有默认索引文件将请求传递给命名 locationrewrite进行进一步处理。通过使用try_files指令我们可以优先检查是否存在静态文件或目录并在找到可访问资源时立即返回减少了不必要的重定向或后端处理的开销rewrite块使用正则表达式将所有请求都重写到index.php脚本并将原始 URL 作为参数传递rewrite ^/(.*)$ /index.php?r$1 last;。什么是lastlast是一个关键字用于指定rewrite规则匹配成功后的行为。它表示停止当前的 rewrite 过程并使用重写后的 URL 重新执行请求具体来说last关键字的作用是结束当前的rewrite过程当 Nginx 匹配到某个rewrite规则后如果该规则带有last关键字Nginx 将停止进一步的rewrite过程。使用新的 URL 重新执行请求当rewrite规则匹配成功并使用了last关键字时Nginx 会将重写后的 URL 作为新的请求地址然后重新执行整个请求过程包括重新匹配server、location、if等。在示例配置中rewrite ^/(.*)$ /index.php?r$1 last;规则将匹配所有请求并将原始的 URL 重写为/index.php?r原始URL的形式。同时last关键字指示 Nginx 在重写后使用这个新的 URL 再次执行请求。需要注意的是last关键字只会终止当前的rewrite过程并不会立即返回响应。重写后的请求还会经过其他的location匹配和处理规则直到找到合适的处理逻辑或到达配置结束。最后location ~ \.php$匹配以.php结尾的 URL并将请求转发给 PHP-FPM 进程来处理。什么是负载均衡负载均衡Load Balancing是一种分布式系统中的技术用于将工作负载即请求、任务均匀地分发到多个服务器或计算资源上以提高系统的性能、可靠性和可扩展性。在负载均衡的架构中有一个负载均衡器Load Balancer它作为中间层位于客户端和后端服务器之间。当客户端发送请求时负载均衡器会根据一定的算法如轮询、最少连接数加权轮询ip哈希等选择一个后端服务器并将请求转发到该服务器上处理。这样负载均衡器可以避免某些服务器过载而导致性能下降同时还可以提供高可用性因为如果某台服务器出现故障负载均衡器可以自动将请求转发到其他正常的服务器上。通过负载均衡系统可以实现以下好处提高性能负载均衡将请求分发到多个服务器上使得每个服务器都可以处理相对较少的请求从而提高整体系统的响应速度和吞吐量。提高可靠性如果某个服务器发生故障或不可用负载均衡器可以将请求转发到其他正常的服务器上保证服务的可用性和可靠性。实现可扩展性通过增加新的服务器来扩展系统的处理能力负载均衡器可以自动将请求分发到新加入的服务器上实现水平扩展。限流算法有哪些固定窗口算法把时间分成固定大小的窗口比如 1 秒每个窗口内最多允许 N 个请求窗口结束后计数器清零重新计数滑动窗口算法把固定窗口拆分成更小的时间片比如 1 秒窗口拆成 10 个 100ms 的时间片窗口随时间 “滑动”每次只统计当前窗口内的请求数解决固定窗口的临界值问题。漏桶算法把请求比作 “水”先进入一个 “漏桶”漏桶以固定速率出水处理请求水满则限流基于反向代理的负载均衡器server { listen 80; server_name vp1.com; location / { # 这里需要注意一定要写http:// # 另外需要注意的是 这里的 vp2 就是真正的www.vp2.com了 不是下面配置的vp2 proxy_pass http://www.vp2.com; # 如果配置了proxy_pass 则下面的 root index都失效了 # root /www/vp1; # index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } }以上配置相当于是访问我们自己的 vp1.com 的时候 nginx帮我们代理到了 http://www.vp2.com 然后返回给我们客户端配置中的proxy_pass指令指定了代理的目标地址为http://www.vp2.com。当收到来自客户端的请求时Nginx会将请求的内容原封不动地发送给http://www.vp2.com并将从http://www.vp2.com返回的响应内容直接返回给客户端。这样对于客户端来说它们只知道访问的是vp1.com而不会感知到实际处理请求的是http://www.vp2.com。需要注意的是在这种代理设置下root和index配置将失效。因为proxy_pass指令会覆盖掉默认的文件根目录root和索引文件index的设置所以客户端访问vp1.com时不会使用root目录中的文件也不会按照index的顺序查找默认的索引文件。此外配置中还包括错误页面的处理。当出现500、502、503或504错误时Nginx会将请求重定向到/50x.html页面并从html目录下返回该错误页面的内容给客户端。这样可以提供更友好的错误信息给用户。proxy_pass指令后面可以跟多种不同的参数形式以适应不同的代理需求。直接指定目标URL可以使用完整的目标URL作为参数例如proxy_pass http://www.example.com;使用变量可以使用变量来动态构建目标URL。这样可以根据请求的特定条件将请求代理到不同的目标服务器上例如location / { proxy_pass http://$backend; }使用负载均衡可以使用upstream模块配置多个后端服务器并使用proxy_pass指令将请求转发到负载均衡池中的服务器例如upstream backend { server backend1.example.com; server backend2.example.com; } location / { proxy_pass http://backend; }配置负载均衡组首先我在本地使用nginx开启了一个服务并且修改根文件内容为192.128.2.10然后修改虚拟机上的配置 添加负载均衡模块upstream需要注意的是upstream与server模块是同级的不能写到server里面http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream httpds{ server 192.168.2.10; server 192.168.2.21:81;#这里指定81是为了防止服务器死循环即我负载均衡到自己 自己又要转发给负载均衡 负载均衡又给自己 一直反反复复 我是这样理解的 } server { listen 80; server_name localhost; location / { proxy_pass http://httpds; # root html; # index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } server { listen 81; server_name localhost; location / { # proxy_pass http://httpds; root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } }以上代码配置了upstream组意思是当我访问 192.168.2.21的时候就会负载均衡到我配置的192.168.2.10上面了负载均衡策略权重weightweight是用于指定上游服务器的权重的参数。权重用于控制请求在负载均衡时分发给每个上游服务器的比例。默认情况下Nginx使用简单的轮询算法将请求均匀地分发给上游服务器。但是通过指定不同的权重值您可以调整服务器接收请求的比例。权重值越高服务器接收请求的概率就越大。例如如果有两个上游服务器server1和server2它们的权重分别为weight1和weight2那么对于每3个请求将有两个请求被转发到server2而只有一个请求被转发到server1从而实现了请求负载的不均衡。upstream httpds{ server 192.168.2.10 weight1; server 192.168.2.21:81 weight9; }下线downdown参数来标记一个后端服务器为“下线”状态。当一个服务器被标记为down后Nginx 将不再将新的请求分发给它直到将其标记为“上线”upstream httpds{ server 192.168.2.10 weight1 down; server 192.168.2.2181 weight9; }备用backupbackup参数来指定一个后备服务器。当所有的主要服务器都处于故障或不可用状态时Nginx 将会将请求转发到后备服务器。upstream httpds{ server 192.168.2.10 backup; server 192.168.2.2181 ; }动静分离什么是动静分离动静分离也称为静态内容分离是一种将动态生成的网页内容和静态资源进行拆分和分离的技术策略。在传统的 Web 应用程序中动态网页内容和静态资源如图片、CSS 文件、JavaScript 文件等通常由同一个应用服务器提供。当用户请求一个页面时应用服务器会处理逻辑、从数据库或其他数据源中获取数据并生成完整的 HTML 页面再将其发送给用户的浏览器。这样做的缺点是无论是动态内容还是静态资源都需要经过应用服务器的处理增加了服务器的负载和响应时间。而使用动静分离的策略可以将动态生成的网页内容和静态资源分别存放在不同的服务器上从而实现更好的性能和扩展性。通常静态资源会被存放在专门的静态资源服务器如 CDN 或文件存储服务器上而动态网页内容则由应用服务器生成。当用户请求一个页面时应用服务器只需负责生成动态内容而静态资源则由专门的服务器来提供。这样可以减轻应用服务器的负载提高网页的加载速度并且使得静态资源可以被缓存和有效地利用 CDN。动静分离可以通过代理服务器、反向代理服务器或负载均衡器来实现。在 Nginx 中可以通过配置多个 location 来指定静态资源的访问路径然后将其代理到静态资源服务器上从而实现动静分离。总结来说动静分离是一种优化网站性能和提高扩展性的技术策略通过将动态内容和静态资源分别存放在不同的服务器上减轻了应用服务器的负载提高了网页的加载速度。动静分离的作用是什么提高网页加载速度静态资源如图片、CSS 文件、JavaScript 文件等通常较大而且在内容不变的情况下可以被缓存因此将静态资源存放在专门的服务器上利用缓存和 CDN 技术可以减少网络传输时间和带宽消耗从而加快网页的加载速度。减轻应用服务器负载将静态资源交由专门的服务器处理可以将应用服务器从处理静态资源的任务中解放出来更集中地处理动态生成的内容。这样可以提高应用服务器的响应能力和并发处理能力减轻服务器负荷提高整个系统的性能和可扩展性。实现更好的可扩展性通过动静分离我们可以对动态内容和静态资源进行独立的部署和扩展。根据需求可以灵活地配置和调整静态资源服务器和应用服务器的数量和规模以满足不断增长的访问量和用户需求动静分离的实现注意每次修改nginx配置都需要重载配置或者重启服务并检查哦systemctl restart nginx.service systemctl ststus nginx.service在开始进行动静分离之前我们首先要准备至少2个服务一个用作于应用服务器一个用作于静态资源服务器这里我采用本机192.168.2.10作为静态资源服务器同时对其目录结构中新增一张图片 img.png并且修改index.html如下图所示。现在我们通过如下配置访问192.168.2.21这里是我的另一个服务器地址以下的当前nginx的配置http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream httpds{ server 192.168.2.10; server 192.168.2.21:81 ; } server { listen 80; server_name localhost; location / { proxy_pass http://httpds; # root html; # index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } }这个时候我们查看一下可以看到目前这种情况下是可以直接在192.168.2.21这个服务器上代理到192.168.2.10服务器并且正确拿到图片并且渲染现在我们要做的就是把他分开把所有的静态资源迁移到192.168.2.21这个服务器上让21作为静态资源服务器。下面的方法适用于静态资源较少目录结构相对简单的情况下。首先我们删除192.168.2.10服务器上的 img 文件夹并且再192.168.2.21中创建img/img.png这样的目录结构。这样我们就可以看到在同上的配置下并不能再正常的渲染出图片。现在我们修改nginx配置如下server { listen 80; server_name localhost; location / { proxy_pass http://httpds; # root html; # index index.html index.htm; } location /img{ root html; index index.html; } }在本机配置中我们新建了一个location这里的意思是 当url资源匹配到 /img 时 会自动从 root html 这下面去寻找这里不需要写下级地址他会自动根据url寻址在这里表现为/html/img/img.ong这样我们就做好了一个简单的动静分离但是这里又引申出来一个新的问题如果我的静态资源目录很复杂难道一个一个这样配置吗接下来我们就需要了解一个新的概念正则表达式匹配动静分离正则匹配动静分离location ~*/(img|js|css|xxx){ root html; index index.html; }location ~*/(img|js|css|xxx)这是一个正则表达式匹配的 location 块。它指定了当请求的 URL 匹配以 “/img”、”/js”、”/css” 或 “/xxx” 开头的路径时下面的配置将生效。root html这个指令规定了静态资源的根目录。在这个例子中静态资源被存放在 “html” 目录下。index index.html这个指令指定了默认的索引文件。当用户请求访问一个目录时Nginx 会优先查找该目录下的 “index.html” 文件并返回给用户。URL writer 伪静态为什么要做 URL writer 伪静态友好的 URL 结构伪静态 URL 可以提供更友好、易读和易记的 URL 结构让用户更容易理解和记住网站的链接。相比于含有动态参数的 URL伪静态 URL 更符合用户的预期并且能够增强用户对网站的信任感。提升搜索引擎优化SEO大多数搜索引擎更喜欢解析和索引静态 URL因为它们通常与特定内容相关联。通过使用伪静态 URL您可以使搜索引擎更容易理解和索引您的网页内容从而提高在搜索结果中的排名和可见性。伪静态的实现server { listen 80; server_name localhost; location / { rewrite ^/(\d)\.html$ /index.html?page$1 break; proxy_pass http://192.168.2.10; } }以上代码表示当访问 http://192.168.2.21/123.html 的时候自动匹配到 http://192.168.2.10/index.html?page123last标志当使用last标志时nginx将停止处理当前请求并将其重新发送给重新计算的URI。这意味着nginx将使用新的URI再次处理请求这可能会导致不同的位置匹配或其他指令的应用。在您的情况下当使用rewrite ^/index\.html$ /index.html?page1 last;进行重写后Nginx将重新处理请求并根据新的 URI/index.html?page1来选择适当的位置进行处理。break标志与last标志不同break标志表示停止执行当前location匹配块中的重写规则并使用新的URI在同一个location块中重新处理请求。它不会跳出当前location块也不会再次触发其他location块的匹配。这意味着在您的情况下当使用rewrite ^/index\.html$ /index.html?page1 break;进行重写后Nginx只会重新处理当前的location块而不会再重新匹配其他location块。举个例子location / { rewrite ^/old-url$ /new-url break; rewrite ^/new-url$ /final-url; }如果请求的 URL 是 “/old-url”当 Nginx 执行第一个 rewrite 规则时它将把 “/old-url” 重写为 “/new-url”然后立即停止执行后续的 rewrite 规则。因此对于客户端来说它将看到的 URI 仍然是 “/new-url”并且不会被第二个 rewrite 规则再次匹配和处理。“break” 只适用于 rewrite 指令本身并不影响后续的 location 匹配或其他指令的执行。location / { rewrite ^/old-url$ /new-url last; rewrite ^/new-url$ /final-url; }如果使用last标志而不是break标志那么它将导致 Nginx 重新匹配和处理请求。这意味着在您提供的示例中当请求的 URL 是 “/old-url” 时Nginx 会将其重写为 “/new-url”然后再次处理请求。接下来Nginx 将重新评估重写后的 URL并继续应用其他的 rewrite 规则。在您的示例中请求的 URL 现在是 “/new-url”因此它会匹配第二个 rewrite 规则将其重写为 “/final-url”。使用last标志的效果是请求将在每次重写后重新进入 location 块并按照新的 URL 继续处理。这可能会触发多次匹配和重写直到没有更多的匹配项或达到配置的限制。如果没有last或break标志Nginx 将会继续尝试其他的 rewrite 规则直到找到匹配的规则或完成所有的 rewrite 处理。至此入门的nginx已经给你教完了作为一名初入职场的后端开发小白相信这些已经够你基本的调试和修改了后面更深入的学习需要你结合工作需求去学习了