nginx 简介+应用

放逐者-保持本心，方可放逐2024-12-16 10:44

文章目录

    • [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.css和main.js文件，从而展示前端项目。

nginx 二级目录处理

  1. 情况分析
    • 当前端项目打包后存在于二级目录（例如，项目打包后放在/var/www/html/your_project_folder，访问路径是http://your_domain.com/your_project_folder）时，需要在Nginx配置中正确地设置root和location来匹配这种目录结构。
  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会根据后面的root和index指令来处理请求。

    • 处理静态资源路径问题（可选）

      • 如果前端项目中的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;
    }
}
        • 注意alias和root的区别：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_files 和 index 指令 ：
    • 其作用和第一个 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.css、http://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主要需要确保被嵌套的页面（即iframe的src属性指向的页面）能够正确地被访问。这涉及到正确配置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;
    }
}

    • 解释：

      • listen和server_name部分：listen 80表示Nginx监听80端口（HTTP默认端口），server_name your_domain.com指定了服务器的域名。
      • 第一个location /：用于处理主页面index.html的请求。root /var/www/html表示主页面文件所在的根目录是/var/www/html，index index.html表示当请求路径是/（即域名本身）时，返回index.html作为默认页面。
      • 第二个location /nested.html：用于处理被嵌套页面nested.html的请求。同样，root /var/www/html指定了该页面所在的根目录，这样当iframe的src属性指向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:8080、192.168.1.101:8080、192.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:8080、192.168.1.101:8080、192.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_certificate 和 ssl_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_timeout和proxy_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_upgrade和proxy_set_header Connection "Upgrade"：这两个指令用于将客户端的升级请求（从HTTP升级到WebSocket）正确地传递给后端服务器。
        • proxy_read_timeout 60s和proxy_send_timeout 60s：这是设置Nginx等待接收和发送数据的超时时间为60秒。在这个时间内如果没有数据传输，Nginx不会立即关闭连接，这可以看作是一种简单的心跳检测机制。当连接空闲时间超过这个超时时间，Nginx可能会关闭连接。
相关推荐
一心0921 小时前
ubuntu 20.04.6 sudo 源码包在线升级到1.9.17p1
运维·ubuntu·sudo·漏洞升级
好好学习啊天天向上1 小时前
世上最全：ubuntu 上及天河超算上源码编译llvm遇到的坑，cmake,ninja完整过程
linux·运维·ubuntu·自动性能优化
你想考研啊1 小时前
三、jenkins使用tomcat部署项目
运维·tomcat·jenkins
代码老y2 小时前
Docker：容器化技术的基石与实践指南
运维·docker·容器
典学长编程2 小时前
Linux操作系统从入门到精通！第二天（命令行）
linux·运维·chrome
DuelCode3 小时前
Windows VMWare Centos Docker部署Springboot 应用实现文件上传返回文件http链接
java·spring boot·mysql·nginx·docker·centos·mybatis
你想考研啊5 小时前
四、jenkins自动构建和设置邮箱
运维·jenkins
Code blocks5 小时前
使用Jenkins完成springboot项目快速更新
java·运维·spring boot·后端·jenkins
饥饿的半导体6 小时前
Linux快速入门
linux·运维
还是奇怪8 小时前
Linux - 安全排查 2
linux·运维·安全
热门推荐
01Java学习第十五部分——MyBatis02集群聊天服务器---MySQL数据库的建立03Coze扣子平台完整体验和实践（附国内和国际版对比）04基于odoo17的设计模式详解---装饰模式05使用Ruby接入实时行情API教程06扣子（coze）实战|我用扣子搭建了一个自动分析小红薯笔记内容的AI应用|详细步骤拆解07Everything文件检索工具 几秒检索几百G的文件08基于odoo17的设计模式详解---单例模式09DeepSeek各版本说明与优缺点分析10【无标题】