文章目录
-
- [nginx 简介](#nginx 简介)
- [nginx 二级目录处理](#nginx 二级目录处理)
- [二级目录 实例列举](#二级目录 实例列举)
-
- [1. 第一个 `location /` 块](#1. 第一个
location /
块) - [2. 第二个 `location ~ ^/(ui)` 块](#2. 第二个
location ~ ^/(ui)
块) - [3. 第三个 `location /api` 块](#3. 第三个
location /api
块)
- [1. 第一个 `location /` 块](#1. 第一个
- [第一个 `location /` 与 第二个 `location ~ ^/(ui)` 是否重复](#第一个
location /
与 第二个location ~ ^/(ui)
是否重复) - [nginx 前端部署 iframe 嵌套配置设置](#nginx 前端部署 iframe 嵌套配置设置)
- [后端服务 转发 实例](#后端服务 转发 实例)
-
- [一、简单的反向代理转发到后端 Web 服务器实例](#一、简单的反向代理转发到后端 Web 服务器实例)
- 二、基于路径区分转发到不同后端服务器的实例
- 三、负载均衡转发实例(以轮询算法为例)
- [四、配置 HTTPS 并转发到后端 HTTP 服务器实例(假设已配置好 SSL 证书)](#四、配置 HTTPS 并转发到后端 HTTP 服务器实例(假设已配置好 SSL 证书))
- [nginx ws 心跳配置](#nginx ws 心跳配置)
nginx 简介
- 什么是Nginx
- Nginx是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP代理服务器。它由俄罗斯程序员Igor Sysoev开发,最初是为了解决C10K问题(即服务器同时处理一万个以上客户端连接的问题)。
- 它具有以下特点:
- 高性能:Nginx采用事件驱动的异步非阻塞模型,能够在高并发环境下高效地处理大量请求。相比传统的基于进程或线程的服务器,它可以使用更少的系统资源来处理更多的并发连接。
- 轻量级:Nginx的代码简洁,安装包体积小,占用系统资源少。它可以在各种操作系统上运行,包括Linux、Unix、Windows等。
- 可扩展性:Nginx可以通过添加模块来扩展其功能,如SSL/TLS加密、HTTP/2支持、缓存模块等。它还可以与其他服务器软件(如Apache、Tomcat等)配合使用,构建复杂的网络应用架构。
- 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可以缓存这些页面,当用户再次请求时,直接从缓存中获取数据,而不需要后端服务器重新生成和返回,从而大大提高了响应速度。
- 反向代理
- 前端项目Nginx部署步骤
- 安装Nginx
- 在Linux系统(以Ubuntu为例)上,可以使用以下命令安装Nginx:
sudo apt - update
sudo apt - install nginx
- 在Windows系统上,可以从Nginx官方网站(nginx.org)下载Windows版本的Nginx安装包,然后按照安装向导进行安装。
- 在Linux系统(以Ubuntu为例)上,可以使用以下命令安装Nginx:
- 配置Nginx
-
找到Nginx的配置文件,在Linux系统中通常位于
/etc/nginx/nginx.conf
或/etc/nginx/conf.d/
目录下的自定义配置文件(如your_project.conf
)。在Windows系统中,配置文件通常位于安装目录下的conf
文件夹中。 -
配置服务器块(server block)来指定前端项目的相关信息。例如:
nginxserver { 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
来重新启动。
- 在Linux系统中,可以使用以下命令启动或重新启动Nginx:
- 安装Nginx
- 部署实例
-
假设我们有一个简单的前端项目,包含一个
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
的配置文件,内容如下:nginxserver { 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 二级目录处理
- 情况分析
- 当前端项目打包后存在于二级目录(例如,项目打包后放在
/var/www/html/your_project_folder
,访问路径是http://your_domain.com/your_project_folder
)时,需要在Nginx配置中正确地设置root
和location
来匹配这种目录结构。
- 当前端项目打包后存在于二级目录(例如,项目打包后放在
- 配置步骤
- 修改
location
指令-
在Nginx配置文件(通常是
/etc/nginx/conf.d/your_project.conf
或/etc/nginx/nginx.conf
)中,location
指令用于匹配请求的URL路径。如果项目在二级目录your_project_folder
下,配置如下:nginxserver { 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
指令来重新映射路径。例如:nginxserver { 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(在Linux系统中使用
- 修改
二级目录 实例列举
以下是对上述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
,若有则返回给客户端作为响应内容。
- 定义了默认的索引文件。当客户端请求的是一个目录(即请求的URL最后没有具体文件名)时,Nginx会按照这里指定的顺序查找相应的文件并返回给客户端。在这个配置中,先查找
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)
是否重复
-
配置不重复的原因
- 路径匹配规则不同
- 第一个
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
开头的请求进行管理。
- 第一个
- 路径匹配规则不同
-
不能只用第二个的原因
- 缺失通用匹配情况
- 如果只使用第二个
location
配置,那么除了以/ui
开头的请求外,其他请求(如根路径、其他非ui
开头的前端页面路径)将没有合适的配置来处理。例如,用户访问http://yourdomain.com/
或者http://yourdomain.com/about
等路径时,Nginx将不知道如何查找对应的文件,因为没有了第一个location /
提供的通用查找规则。
- 如果只使用第二个
- 可能破坏前端页面功能完整性
- 前端页面可能包含多种类型的资源和路径,包括但不限于样式表、脚本文件、图片等,这些资源的路径可能不都是以
/ui
开头的。如果移除第一个location /
,可能会导致部分资源无法正确加载,从而破坏整个前端页面的功能和布局。
- 前端页面可能包含多种类型的资源和路径,包括但不限于样式表、脚本文件、图片等,这些资源的路径可能不都是以
- 缺失通用匹配情况
nginx 前端部署 iframe 嵌套配置设置
- 理解
iframe
和Nginx配置的关系iframe
是HTML中的一个标签,用于在一个HTML文档中嵌入另一个HTML文档。当在前端部署中涉及iframe
嵌套时,Nginx主要需要确保被嵌套的页面(即iframe
的src
属性指向的页面)能够正确地被访问。这涉及到正确配置location
规则来处理这些页面的请求路径。
- 基本的Nginx配置示例用于
iframe
嵌套-
假设主页面
index.html
和被嵌套的页面nested.html
都位于Nginx服务器的/var/www/html
目录下。 -
Nginx配置文件(通常是
/etc/nginx/nginx.conf
或/etc/nginx/conf.d/your_project.conf
)可以这样配置:nginxserver { 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能够正确地找到并返回这个页面。
-
- 跨域
iframe
嵌套的情况(如果主页面和被嵌套页面在不同域名下)-
如果主页面所在的域名是
your_domain.com
,被嵌套页面所在的域名是another_domain.com
,会涉及跨域问题。在这种情况下,需要在被嵌套页面所在的服务器(another_domain.com
对应的Nginx服务器)上进行配置,允许跨域访问。 -
Nginx配置如下:
nginxserver { 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
中的页面需要进行用户认证等操作并且要共享凭证,这个配置是必要的。
-
- 处理
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 心跳配置
-
什么是WS心跳以及为什么要配置它
- WS(WebSocket)是一种在单个TCP连接上进行全双工通信的协议。心跳机制用于检测WebSocket连接是否还存活。在网络环境不稳定或者长时间没有数据传输的情况下,通过发送和接收心跳消息,可以确保连接的有效性,避免连接因为长时间空闲而被服务器或代理(如Nginx)错误地关闭。
-
Nginx配置WS心跳的实例
- 基本配置示例(使用
proxy_read_timeout
和proxy_send_timeout
)-
假设后端的WebSocket服务运行在
http://backend-ws-server:8080
,以下是Nginx的配置:nginxhttp { # 其他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可能会关闭连接。
-
- 基本配置示例(使用