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可能会关闭连接。
相关推荐
Deutsch.41 分钟前
负载均衡Haproxy
运维·负载均衡·haproxy
不做无法实现的梦～1 小时前
mid360连接机载电脑，远程桌面连接不上的情况
运维·服务器·电脑
运维成长记2 小时前
关于linux运维 出现高频的模块认知
运维·职场和发展·云计算
IT成长日记2 小时前
【自动化运维神器Ansible】Ansible常用模块之archive模块详解
运维·自动化·ansible·常用模块·archive
晴天￥2 小时前
阶段1--域名服务器
运维·服务器·网络
禁默3 小时前
进程调度的艺术：从概念本质到 Linux 内核实现
linux·运维·服务器
Azure DevOps3 小时前
在Azure DevOps的工作项中使用markdown
运维·microsoft·flask·azure·devops
先做个垃圾出来………3 小时前
CI/CD与DevOps集成方法
运维·ci/cd·devops
qq_447705313 小时前
宝塔通过docker部署JupyterHub指南【常见错误处理】
运维·docker·容器
卡比巴拉—林4 小时前
HAProxy 实验指南：从零开始搭建高可用负载均衡系统
运维·负载均衡
热门推荐
01Qwen3-Coder 快速上手教程 | Qwen Code + Claude Code02扣子开源本地部署教程 丨Coze智能体小白喂饭级指南03Coze 开源了，送上保姆级私有化部署方案【建议收藏】04全球最强模型Grok4，国内已可免费使用！（附教程）05vue数据变化但页面不变06KGG转MP3工具|非KGM文件|解密音频07干翻 Typora！MilkUp：完全免费的桌面端 Markdown 编辑器！0801-开源版COZE-字节 Coze Studio 重磅开源！保姆级本地安装教程，手把手带你体验09腾讯还是太全面了，限时免费！超全CodeBuddy IDE保姆级教程！（附案例）10sqli-labs 靶场 less-8、9、10 第八关到第十关详解：布尔注入，时间注入