nginx 简介+应用

文章目录

    • [nginx 简介](#nginx 简介)
    • [nginx 二级目录处理](#nginx 二级目录处理)
    • [二级目录 实例列举](#二级目录 实例列举)
      • [1. 第一个 `location /` 块](#1. 第一个 location / 块)
      • [2. 第二个 `location ~ ^/(ui)` 块](#2. 第二个 location ~ ^/(ui) 块)
      • [3. 第三个 `location /api` 块](#3. 第三个 location /api 块)
    • [第一个 `location /` 与 第二个 `location ~ ^/(ui)` 是否重复](#第一个 location / 与 第二个 location ~ ^/(ui) 是否重复)
    • [nginx 前端部署 iframe 嵌套配置设置](#nginx 前端部署 iframe 嵌套配置设置)
    • [后端服务 转发 实例](#后端服务 转发 实例)
    • [nginx ws 心跳配置](#nginx ws 心跳配置)

nginx 简介

  1. 什么是Nginx
    • Nginx是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP代理服务器。它由俄罗斯程序员Igor Sysoev开发,最初是为了解决C10K问题(即服务器同时处理一万个以上客户端连接的问题)。
    • 它具有以下特点:
      • 高性能:Nginx采用事件驱动的异步非阻塞模型,能够在高并发环境下高效地处理大量请求。相比传统的基于进程或线程的服务器,它可以使用更少的系统资源来处理更多的并发连接。
      • 轻量级:Nginx的代码简洁,安装包体积小,占用系统资源少。它可以在各种操作系统上运行,包括Linux、Unix、Windows等。
      • 可扩展性:Nginx可以通过添加模块来扩展其功能,如SSL/TLS加密、HTTP/2支持、缓存模块等。它还可以与其他服务器软件(如Apache、Tomcat等)配合使用,构建复杂的网络应用架构。
  2. Nginx的作用
    • 反向代理
      • 隐藏后端服务器的真实IP地址,增强安全性。例如,当外部用户访问网站时,他们请求的是Nginx服务器的IP地址,而Nginx再将请求转发到后端的真实服务器(如Web服务器、应用服务器等),这样后端服务器的IP就不会直接暴露在互联网上,减少了遭受攻击的风险。
      • 实现负载均衡。Nginx可以将用户请求均匀地分配到多个后端服务器上,提高应用系统的可用性和性能。比如,有一个大型电商网站,后端有多台Web服务器处理用户请求,Nginx可以根据不同的负载均衡算法(如轮询、加权轮询、IP哈希等)将请求合理地分配到这些服务器上,避免某台服务器过载,而其他服务器闲置的情况。
    • HTTP服务器
      • 可以直接提供静态资源服务,如HTML文件、CSS样式表、JavaScript脚本、图片等。当用户请求这些静态资源时,Nginx能够快速地响应,减少请求的处理时间。例如,对于一个新闻网站,新闻文章的页面布局(HTML和CSS)以及相关图片等静态资源可以由Nginx直接提供服务,提高用户访问速度。
      • 支持HTTP/2协议,提供更高效的网络传输。HTTP/2相比HTTP/1.1具有更高的性能,如二进制分帧、多路复用、头部压缩等特性,Nginx可以利用这些特性来提升网站的性能。
    • 缓存功能
      • Nginx可以缓存经常访问的静态资源和部分动态资源,减少对后端服务器的请求次数。例如,对于一些更新不频繁的网页内容,Nginx可以缓存这些页面,当用户再次请求时,直接从缓存中获取数据,而不需要后端服务器重新生成和返回,从而大大提高了响应速度。
  3. 前端项目Nginx部署步骤
    • 安装Nginx
      • 在Linux系统(以Ubuntu为例)上,可以使用以下命令安装Nginx:
        • sudo apt - update
        • sudo apt - install nginx
      • 在Windows系统上,可以从Nginx官方网站(nginx.org)下载Windows版本的Nginx安装包,然后按照安装向导进行安装。
    • 配置Nginx
      • 找到Nginx的配置文件,在Linux系统中通常位于/etc/nginx/nginx.conf/etc/nginx/conf.d/目录下的自定义配置文件(如your_project.conf)。在Windows系统中,配置文件通常位于安装目录下的conf文件夹中。

      • 配置服务器块(server block)来指定前端项目的相关信息。例如:

        nginx 复制代码
        server {
            listen       80;
            server_name  your_domain.com;
        
            location / {
                root   /var/www/your_front_end_project;
                index  index.html;
            }
        }
        • listen:指定Nginx监听的端口,这里是80端口(HTTP默认端口)。
        • server_name:设置服务器名称,通常是域名。
        • location /:定义请求的路径匹配规则。root指定了前端项目文件的根目录,index指定了默认的首页文件。
    • 将前端项目文件放置到指定位置
      • 根据配置文件中指定的root路径,将前端项目的文件(如HTML、CSS、JavaScript等)复制到相应的目录下。例如,如果root设置为/var/www/your_front_end_project,那么就将项目文件复制到这个目录中。
    • 启动或重新启动Nginx
      • 在Linux系统中,可以使用以下命令启动或重新启动Nginx:
        • 启动:sudo service nginx start
        • 重新启动:sudo service nginx restart
      • 在Windows系统中,可以在命令提示符或PowerShell中进入Nginx安装目录下的sbin文件夹,然后执行nginx.exe来启动,使用nginx -s reload来重新启动。
  4. 部署实例
    • 假设我们有一个简单的前端项目,包含一个index.html文件、一个styles.css文件和一个main.js文件。项目结构如下:

      my_front_end_project/
        ├── index.html
        ├── styles.css
        └── main.js
      
    • 首先,按照上述安装步骤在服务器(以Linux为例)上安装Nginx。

    • 然后,配置Nginx。在/etc/nginx/conf.d/目录下创建一个名为my_project.conf的配置文件,内容如下:

      nginx 复制代码
      server {
          listen       80;
          server_name  example.com;
      
          location / {
              root   /var/www/my_front_end_project;
              index  index.html;
          }
      }
    • 接着,将前端项目文件复制到/var/www/my_front_end_project目录下。

    • 最后,通过sudo service nginx restart重新启动Nginx。现在,当用户在浏览器中访问http://example.com时,Nginx就会将/var/www/my_front_end_project/index.html文件作为首页返回给用户,并且能够正确加载相关的styles.cssmain.js文件,从而展示前端项目。

nginx 二级目录处理

  1. 情况分析
    • 当前端项目打包后存在于二级目录(例如,项目打包后放在/var/www/html/your_project_folder,访问路径是http://your_domain.com/your_project_folder)时,需要在Nginx配置中正确地设置rootlocation来匹配这种目录结构。
  2. 配置步骤
    • 修改location指令
      • 在Nginx配置文件(通常是/etc/nginx/conf.d/your_project.conf/etc/nginx/nginx.conf)中,location指令用于匹配请求的URL路径。如果项目在二级目录your_project_folder下,配置如下:

        nginx 复制代码
        server {
            listen       80;
            server_name  your_domain.com;
            location /your_project_folder/ {
                root   /var/www/html;
                index  index.html;
            }
        }
      • 这里的location /your_project_folder/表示当用户访问http://your_domain.com/your_project_folder/开头的URL时,Nginx会根据后面的rootindex指令来处理请求。

    • 处理静态资源路径问题(可选)
      • 如果前端项目中的CSS、JavaScript或图片等静态资源的引用路径是相对路径,那么可能不需要额外配置。但如果是绝对路径(例如,在HTML中<script src="/main.js"></script>这种以/开头的路径),这些资源在二级目录下可能无法正确加载。

      • 可以在HTML文件头部添加一个<base>标签来指定基础路径,例如,如果项目在your_project_folder下,可以在index.html<head>标签内添加:

        html 复制代码
        <base href="/your_project_folder/">
      • 或者修改Nginx配置,使用alias指令来重新映射路径。例如:

        nginx 复制代码
        server {
            listen       80;
            server_name  your_domain.com;
            location /your_project_folder/ {
                alias   /var/www/html/your_project_folder/;
                index  index.html;
            }
        }
        • 注意aliasroot的区别:alias会替换location中的路径部分,而root是将location中的路径附加到root指定的路径后面。使用alias时,路径末尾的/需要特别注意,确保路径的准确性。
    • 测试与调整
      • 完成配置后,重新启动Nginx(在Linux系统中使用sudo service nginx restart)。
      • 打开浏览器,访问http://your_domain.com/your_project_folder/,检查前端项目是否能够正确加载,包括页面布局、样式和脚本等。如果发现静态资源无法加载或者页面显示异常,可以查看浏览器的开发者工具(通常是按F12键打开),检查网络请求的状态和路径,根据错误信息来进一步调整配置。

二级目录 实例列举

以下是对上述Nginx配置内容的详细解释:

1. 第一个 location /

nginx 复制代码
location / {
    root  html2/ui;
    index index.html index.htm;
    try_files $uri $uri/ /index.html;
}
  • root 指令
    • 作用是设置根目录,用于查找请求对应的文件。在这里指定了根目录为 html2/ui,意味着当有客户端发起请求时,Nginx会去服务器上的 html2/ui 目录下寻找对应的资源文件。例如,客户端请求 /styles.css,Nginx就会尝试从 html2/ui/styles.css 这个路径去获取该文件。
  • index 指令
    • 定义了默认的索引文件。当客户端请求的是一个目录(即请求的URL最后没有具体文件名)时,Nginx会按照这里指定的顺序查找相应的文件并返回给客户端。在这个配置中,先查找 index.html,如果不存在再查找 index.htm。比如客户端访问 http://your_domain/(这里假设域名对应的是此Nginx配置),Nginx会尝试查找 html2/ui/index.html,若有则返回给客户端作为响应内容。
  • try_files 指令
    • 它的作用是按顺序尝试查找文件。首先会尝试查找 $uri 对应的文件,$uri 是一个Nginx内置变量,表示当前请求的URI(例如请求 http://your_domain/styles.css$uri 的值就是 /styles.css)。如果 $uri 对应的文件不存在,就尝试查找 $uri/(即对应的目录下的默认索引文件等情况),如果前面这些都找不到,最后会返回 /index.html 对应的文件作为兜底响应。例如,请求一个不存在的页面路径时,最终会返回 html2/ui/index.html(前提是这个文件存在),以确保能给客户端返回一些内容而不是返回404错误页面。

2. 第二个 location ~ ^/(ui)

nginx 复制代码
location ~ ^/(ui) {
    root html2/;
    try_files $uri $uri/ /index.html;
    index index.html index.htm;
}
  • location 匹配规则及 root 指令
    • 这里使用了正则表达式匹配的 location(通过 ~ 符号表示),^/(ui) 表示匹配以 /ui 开头的请求路径。root 指令设置为 html2/,意味着对于匹配到此规则的请求,Nginx会去服务器上的 html2 目录下查找对应的资源文件。比如客户端请求 /ui/styles.css,Nginx会尝试从 html2/ui/styles.css 这个路径去获取该文件(这里与前面第一个 location 块在查找文件路径时有所关联和区分,要结合请求路径来准确判断具体走哪个 location 配置的逻辑)。
  • try_filesindex 指令
    • 其作用和第一个 location 块中的类似,try_files 按顺序尝试查找请求对应的文件,先是 $uri 对应的文件,再是 $uri/ 对应的情况,最后兜底返回 /index.html 对应的文件。index 指令同样定义了默认索引文件的查找顺序,先找 index.html,再找 index.htm,用于处理请求目录时返回合适的默认文件。

3. 第三个 location /api

nginx 复制代码
location /api {
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Credentials true;
    proxy_pass http://192.168.1.685:8082;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}
  • 跨域相关 add_header 指令
    • add_header Access-Control-Allow-Origin *; 这条指令是用于处理跨域资源共享(CORS)的,它允许来自任何域(* 表示任意来源)的请求访问 /api 这个接口对应的后端服务,在实际应用中,出于安全考虑,可能需要更严格地指定具体的允许域名,而不是使用通配符 *
    • add_header Access-Control-Allow-Credentials true; 表示允许跨域请求携带凭证(比如cookies等),当客户端有需要携带凭证访问后端接口的情况时,这个设置很关键。
  • proxy_pass 指令
    • 用于配置反向代理,将所有以 /api 开头的客户端请求转发到 http://192.168.1.185:8082 这个后端服务器地址。例如,客户端请求 http://your_domain/api/user,Nginx会把这个请求转发到 http://192.168.1.185:8082/api/user,由后端服务器去处理该请求并返回响应给Nginx,然后Nginx再将响应返回给客户端。
  • proxy_set_header 指令(多个)
    • proxy_set_header Host $host; 会把客户端请求中的 Host 头信息原封不动地传递给后端服务器,后端服务器可以根据这个 Host 信息来正确识别请求的域名等相关情况,便于进行相应的业务逻辑处理。
    • proxy_set_header X-Real-IP $remote_addr; 是将客户端的真实IP地址($remote_addr 变量表示客户端的IP)传递给后端服务器,这样后端服务器能够知晓请求的真正来源,对于一些需要记录客户端IP或者基于IP做访问控制等业务场景很有用。
    • proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 用于传递客户端请求经过的代理服务器链的IP信息,它会把之前经过的代理服务器IP(如果有的话)以及客户端IP等信息整合起来传递给后端服务器,方便后端对请求链路等情况进行分析。
    • proxy_set_header X-Forwarded-Proto $scheme; 则是把客户端请求的协议(如 http 或者 https,通过 $scheme 变量获取)传递给后端服务器,让后端能根据实际的协议情况进行相应的操作,比如构建正确的跳转链接等。

总体来说,这段Nginx配置涵盖了前端项目资源的文件查找与服务配置,以及针对 /api 接口的反向代理和跨域相关设置,用于构建一个较为完整的Web服务应用场景,满足前端页面展示及与后端接口交互等需求。

第一个 location / 与 第二个 location ~ ^/(ui) 是否重复

  1. 配置不重复的原因

    • 路径匹配规则不同
      • 第一个location / :这是一个最基本的路径匹配,它会匹配所有以/开头的请求路径。例如,当用户访问http://yourdomain.com/(根路径)或者http://yourdomain.com/about(非ui开头的其他路径)或者http://yourdomain.com/ui/(以ui开头的路径也会匹配)时,都会首先考虑这个location块的配置。
      • 第二个location ~ ^/(ui) :这是一个基于正则表达式的路径匹配。~表示使用正则表达式匹配,^/(ui)的意思是匹配以/ui开头的请求路径。例如,它会匹配http://yourdomain.com/ui/styles.csshttp://yourdomain.com/ui/subfolder/index.html等以/ui开头的路径,但不会匹配http://yourdomain.com/about这种非ui开头的路径。
    • root指令导致的文件查找路径不同
      • 第一个location /root指令设置为html2/ui。这意味着对于匹配这个location的请求,Nginx会在html2/ui目录下查找文件。例如,对于请求http://yourdomain.com/about,Nginx会尝试在html2/ui/about路径下查找对应的资源文件。
      • 第二个location ~ ^/(ui)root指令设置为html2/。对于匹配这个location的请求,Nginx会在html2/目录下查找文件。所以对于请求http://yourdomain.com/ui/styles.css,Nginx会尝试在html2/ui/styles.css路径下查找对应的资源文件。虽然最终查找的文件位置可能在某些情况下看起来相同(如ui相关路径),但由于root指令的基础路径不同,在处理其他路径请求时就会有明显差异。
    • 应用场景的潜在差异
      • 第一个location / :可以作为一个通用的配置,用于处理大部分的前端页面请求。它可以提供默认的文件查找方式,当没有更具体的location匹配规则时(比如不是/api这种特殊路径,也不符合其他更精准的正则表达式匹配的location),就使用这个配置来查找前端页面相关的文件。
      • 第二个location ~ ^/(ui) :可能是用于特定的前端模块或者功能的路径配置。也许ui相关的资源有特殊的组织方式或者需要单独的处理逻辑,比如ui模块下的资源可能有特殊的缓存策略或者权限控制,通过这个单独的location可以更精细地对这些ui开头的请求进行管理。
  2. 不能只用第二个的原因

    • 缺失通用匹配情况
      • 如果只使用第二个location配置,那么除了以/ui开头的请求外,其他请求(如根路径、其他非ui开头的前端页面路径)将没有合适的配置来处理。例如,用户访问http://yourdomain.com/或者http://yourdomain.com/about等路径时,Nginx将不知道如何查找对应的文件,因为没有了第一个location /提供的通用查找规则。
    • 可能破坏前端页面功能完整性
      • 前端页面可能包含多种类型的资源和路径,包括但不限于样式表、脚本文件、图片等,这些资源的路径可能不都是以/ui开头的。如果移除第一个location /,可能会导致部分资源无法正确加载,从而破坏整个前端页面的功能和布局。

nginx 前端部署 iframe 嵌套配置设置

  1. 理解iframe和Nginx配置的关系
    • iframe是HTML中的一个标签,用于在一个HTML文档中嵌入另一个HTML文档。当在前端部署中涉及iframe嵌套时,Nginx主要需要确保被嵌套的页面(即iframesrc属性指向的页面)能够正确地被访问。这涉及到正确配置location规则来处理这些页面的请求路径。
  2. 基本的Nginx配置示例用于iframe嵌套
    • 假设主页面index.html和被嵌套的页面nested.html都位于Nginx服务器的/var/www/html目录下。

    • Nginx配置文件(通常是/etc/nginx/nginx.conf/etc/nginx/conf.d/your_project.conf)可以这样配置:

      nginx 复制代码
      server {
          listen       80;
          server_name  your_domain.com;
          location / {
              root   /var/www/html;
              index  index.html;
          }
          location /nested.html {
              root   /var/www/html;
          }
      }
    • 解释:

      • listenserver_name部分:listen 80表示Nginx监听80端口(HTTP默认端口),server_name your_domain.com指定了服务器的域名。
      • 第一个location /:用于处理主页面index.html的请求。root /var/www/html表示主页面文件所在的根目录是/var/www/htmlindex index.html表示当请求路径是/(即域名本身)时,返回index.html作为默认页面。
      • 第二个location /nested.html:用于处理被嵌套页面nested.html的请求。同样,root /var/www/html指定了该页面所在的根目录,这样当iframesrc属性指向http://your_domain.com/nested.html时,Nginx能够正确地找到并返回这个页面。
  3. 跨域iframe嵌套的情况(如果主页面和被嵌套页面在不同域名下)
    • 如果主页面所在的域名是your_domain.com,被嵌套页面所在的域名是another_domain.com,会涉及跨域问题。在这种情况下,需要在被嵌套页面所在的服务器(another_domain.com对应的Nginx服务器)上进行配置,允许跨域访问。

    • Nginx配置如下:

      nginx 复制代码
      server {
          listen       80;
          server_name  another_domain.com;
          location / {
              root   /var/www/html;
              index  index.html;
              add_header 'Access-Control-Allow-Origin' 'http://your_domain.com';
              add_header 'Access-Control-Allow-Credentials' 'true';
          }
      }
    • 解释:

      • add_header 'Access - Control - Allow - Origin' 'http://your_domain.com';:这个头信息允许来自http://your_domain.com的主页面跨域访问本服务器上的资源(即被嵌套页面)。如果希望允许所有域名跨域访问,可以将http://your_domain.com替换为*,但这样可能存在安全风险。
      • add_header 'Access - Control - Allow - Credentials' 'true';:表示允许跨域请求携带凭证,例如cookies等。如果iframe中的页面需要进行用户认证等操作并且要共享凭证,这个配置是必要的。
  4. 处理iframe中相对路径的问题
    • iframe嵌套页面中的资源(如CSS文件、JavaScript文件等)使用相对路径引用时,可能会因为iframe的嵌套结构导致路径解析错误。

    • 解决方法之一是在iframe嵌套页面的<head>标签中使用<base>标签来指定资源的基础路径。例如,如果nested.html页面中的资源相对于/var/www/html目录,并且nested.html被嵌套在index.html中,可以在nested.html中添加以下代码:

      html 复制代码
      <head>
          <base href="/">
          <!-- 其他头部内容 -->
      </head>
    • 这样可以确保页面中的相对路径资源(如<script src="script.js"></script>中的script.js)能够正确地根据/(即/var/www/html目录)来解析路径,而不会因为iframe的嵌套而出现路径混乱的问题。

后端服务 转发 实例

以下是几个常见的后端 Nginx 服务转发实例,涵盖不同的应用场景,供你参考:

一、简单的反向代理转发到后端 Web 服务器实例

假设后端有一台运行在 192.168.1.100:8080 的 Tomcat 服务器(以 Tomcat 作为示例后端 Web 服务器,也可以是其他如 Node.js 应用服务器等),希望通过 Nginx 将外部请求转发到这台后端服务器上,配置如下:

nginx 复制代码
server {
    listen       80;
    server_name  your_domain.com;

    location / {
        proxy_pass http://192.168.1.100:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
  • 解释
    • listen 80:指定 Nginx 监听的端口为 80(HTTP 常用端口),用于接收外部客户端的请求。
    • server_name your_domain.com:设置对应的域名,当客户端通过该域名访问时,会匹配到此服务器块配置。
    • proxy_pass http://192.168.1.100:8080:将所有匹配到此 location 的请求(这里是所有以 / 开头的请求,因为 location 配置为 /)转发到后端的 192.168.1.100:8080 服务器上。例如,客户端请求 http://your_domain.com/index.jsp,Nginx 会把这个请求转发给后端 Tomcat 服务器,变成 http://192.168.1.100:8080/index.jsp 让其处理。
    • proxy_set_header 相关指令:
      • proxy_set_header Host $host:把客户端请求中的 Host 头信息传递给后端服务器,使得后端服务器能知晓请求对应的域名情况,便于正确处理请求,比如区分不同域名下的虚拟主机配置等。
      • proxy_set_header X-Real-IP $remote_addr:将客户端的真实 IP 地址($remote_addr 变量代表客户端 IP)传递给后端服务器,方便后端记录请求来源、做访问控制等基于 IP 的操作。
      • proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for:用于向后端传递客户端请求经过的代理服务器链的 IP 信息,有助于后端了解请求的完整链路情况。

二、基于路径区分转发到不同后端服务器的实例

假设有两个后端服务,一个是运行在 192.168.1.100:8080 的 API 服务器,另一个是运行在 192.168.1.101:8081 的管理后台服务器,希望根据请求路径来分别转发到不同的后端服务器,配置如下:

nginx 复制代码
server {
    listen       80;
    server_name  your_domain.com;

    location /api {
        proxy_pass http://192.168.1.100:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /admin {
        proxy_pass http://192.168.1.101:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location / {
        proxy_pass http://192.168.1.100:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
  • 解释
    • 对于 location /api 块:当客户端请求的路径是以 /api 开头时,比如 http://your_domain.com/api/users,Nginx 会把该请求转发到 192.168.1.100:8080 这个后端的 API 服务器上,对应的后端服务器就能根据具体的 API 接口逻辑进行处理。
    • 对于 location /admin 块:若客户端请求路径是以 /admin 开头,像 http://your_domain.com/admin/login,Nginx 会将请求转发至 192.168.1.101:8081 的管理后台服务器,供管理后台相关的页面和接口操作使用。
    • 对于 location / 块:作为兜底配置,当请求路径既不符合 /api 开头也不符合 /admin 开头等更具体的 location 匹配规则时,就会将请求转发到 192.168.1.100:8080 这个 API 服务器(当然这里也可以根据实际需求转发到其他通用的后端服务器),确保所有请求都能有对应的后端处理逻辑。

三、负载均衡转发实例(以轮询算法为例)

假设有多台相同的后端 Web 服务器(如 3 台 Tomcat 服务器,IP 分别为 192.168.1.100:8080192.168.1.101:8080192.168.1.102:8080),希望通过 Nginx 实现负载均衡,让请求均匀地分配到这些后端服务器上,配置如下:

nginx 复制代码
upstream backend_pool {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

server {
    listen       80;
    server_name  your_domain.com;

    location / {
        proxy_pass http://backend_pool;
        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_pool,里面列出了参与负载均衡的多台后端服务器的 IP 和端口信息。
    • location / 块中,proxy_pass http://backend_pool 表示将所有以 / 开头的请求转发到这个定义好的后端服务器集群中。Nginx 会根据默认的轮询算法(当然也可以配置其他负载均衡算法,如加权轮询、IP 哈希等),依次将请求分配到 192.168.1.100:8080192.168.1.101:8080192.168.1.102:8080 这几台后端服务器上,实现负载均衡,提高整个系统对大量请求的处理能力和可用性。

四、配置 HTTPS 并转发到后端 HTTP 服务器实例(假设已配置好 SSL 证书)

假设有一个后端服务器运行在 192.168.1.100:8080,前端通过 HTTPS(端口 443)访问,Nginx 需要接收 HTTPS 请求后转发到后端的 HTTP 服务器,配置如下:

nginx 复制代码
server {
    listen       443 ssl;
    server_name  your_domain.com;
    ssl_certificate /path/to/your_domain.com.crt;
    ssl_certificate_key /path/to/your_domain.com.key;

    location / {
        proxy_pass http://192.168.1.100:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
  • 解释
    • listen 443 ssl:表示 Nginx 监听 443 端口(HTTPS 常用端口),并且启用 SSL/TLS 加密。
    • ssl_certificatessl_certificate_key:分别指定了 SSL 证书文件和对应的私钥文件的路径,用于建立 HTTPS 连接时的加密验证等操作。
    • 对于 location / 块,和前面类似,将接收到的通过 HTTPS 访问的请求(比如 https://your_domain.com/ 等路径的请求)转发到后端的 192.168.1.100:8080 这个 HTTP 服务器上,实现了从前端安全的 HTTPS 访问到后端普通 HTTP 服务器的请求转发。

这些实例展示了 Nginx 在后端服务转发方面的不同应用场景,可以根据实际的业务需求、服务器架构等情况进行灵活配置和扩展。

nginx ws 心跳配置

  1. 什么是WS心跳以及为什么要配置它

    • WS(WebSocket)是一种在单个TCP连接上进行全双工通信的协议。心跳机制用于检测WebSocket连接是否还存活。在网络环境不稳定或者长时间没有数据传输的情况下,通过发送和接收心跳消息,可以确保连接的有效性,避免连接因为长时间空闲而被服务器或代理(如Nginx)错误地关闭。
  2. Nginx配置WS心跳的实例

    • 基本配置示例(使用proxy_read_timeoutproxy_send_timeout
      • 假设后端的WebSocket服务运行在http://backend-ws-server:8080,以下是Nginx的配置:

        nginx 复制代码
        http {
            # 其他http配置...
            upstream backend_ws_pool {
                server backend-ws-server:8080;
            }
            server {
                listen       80;
                server_name  your_domain.com;
                location /ws {
                    proxy_pass http://backend_ws_pool;
                    proxy_http_version 1.1;
                    proxy_set_header Upgrade $http_upgrade;
                    proxy_set_header Connection "Upgrade";
                    proxy_read_timeout 60s;
                    proxy_send_timeout 60s;
                }
            }
        }
      • 解释:

        • upstream backend_ws_pool:定义了后端WebSocket服务器的集群,这里只有一个服务器backend - ws - server:8080
        • location /ws:匹配以/ws开头的请求路径,用于将WebSocket请求转发到后端服务器。
        • proxy_http_version 1.1:设置代理使用HTTP/1.1协议,这是支持WebSocket的必要条件。
        • proxy_set_header Upgrade $http_upgradeproxy_set_header Connection "Upgrade":这两个指令用于将客户端的升级请求(从HTTP升级到WebSocket)正确地传递给后端服务器。
        • proxy_read_timeout 60sproxy_send_timeout 60s:这是设置Nginx等待接收和发送数据的超时时间为60秒。在这个时间内如果没有数据传输,Nginx不会立即关闭连接,这可以看作是一种简单的心跳检测机制。当连接空闲时间超过这个超时时间,Nginx可能会关闭连接。
相关推荐
域智盾-运营小韩4 分钟前
CAD图纸加密软件哪个最好用 | 安全可靠的解决方案
运维·网络
宁君25 分钟前
Elasticsearch高性能优化2
linux·运维·服务器
sdkdlwk1 小时前
ubuntu上更改ext4格式的硬盘为 windows的 NTFS 格式参考
linux·运维·ubuntu
苹果醋31 小时前
从零开始,一步一步搭建Typescript+React+Redux项目——集成react-router和axios(三)
运维·vue.js·spring boot·nginx·课程设计
休息一下接着来1 小时前
Ubuntu 挂载目录
linux·运维·ubuntu
rock——you2 小时前
docker容器报错No log line matching the ‘‘ filter
运维·docker·容器
vvw&2 小时前
如何在 Ubuntu 22.04 上使用 vnStat 监控网络流量
linux·运维·服务器·ubuntu·https·集群·vnstat
CQU_JIAKE2 小时前
12.4【计算机网络】【Study】
运维·服务器·计算机网络
aherhuo2 小时前
kubervirt使用与运行策略
运维·docker·容器
lishing63 小时前
Linux驱动开发(13):输入子系统–按键输入实验
linux·运维·驱动开发