当前位置:首页 » 网页前端 » nginx映射前端加项目名
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

nginx映射前端加项目名

发布时间: 2023-07-14 21:33:14

❶ Docker 入门 (07) 部署nginx 并且映射本地配置文件

目标:

1. 利用docker部署一个nginx容器

2.为nginx 容器设置配置文件 , 并且映射到宿主机(本机)

操作步骤:

1.拉取nginx镜像,并尝试简单运行(忘记怎么操作请参考第五节)

2.在本地新增配置文件 , 为了后面映射容器使用 ,我习惯是放到 /etc/docker/nginx-config , 按你个人习惯新增

3.进入config ,我们需要创建一个简单配置文件 , 这里就来个简单的吧

4.因为我稍后需要占用的是8080端口 , 请确认云服务器端是否开放

5. 万事俱备 , 尝试启动吧

6. 使用你的 服务器ip+8080端口访问测试 , 看到您的写的 index,html 内容, 代表启动成功!

7.具体映射位置 可以 使用 docker exec -it [容器ID] /bin/bash 命令去参考对应映射文件 ,原理就应该明白了

结语:

通过本节的 nginx 映射本地配置文件 , 应该掌握对docker映射文件的基本使用了 , 希望大家都把自己的nginx跑起来吧

❷ linux下安装nginx部署多个前端项目

1.先安装nginx所需要的环境

yum install gcc-c++

yum install -y pcre pcre-devel

yum install -y zlib zlib-devel

yum install -y openssl openssl-devel

也可按照如下命令一键安装

yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel

2.安装nginx,安装在/usr/local下

wget -c https://nginx.org/download/nginx-1.10.1.tar.gz

# 解压缩

tar -zxvf linux-nginx-1.12.2.tar.gz

cd nginx-1.12.2/

# 执行配置

./configure

# 编译安装(默认安装在/usr/local/nginx)

make

make install

安装完直接访问 http://121.36.107.248/     默认端口是80

Nginx常用命令

测试配置文件:${Nginx}/sbin/nginx -t

启动命令:${Nginx}/sbin/nginx

停止命令:${Nginx}/sbin/nginx -s stop/quit

重启命令:${Nginx}/sbin/nginx -s reload

查看进程命令:ps -ef | grep nginx

平滑重启:kill -HUP [Nginx主进程号(即ps命令查到的PID)]

喜欢请关注 “蛋皮皮” 微信公众号!更多干货等你来学习哦。

❸ nginx前端常用配置

nginx现在几乎是众多大型网站的必用技术,大多数情况下,我们不需要亲自去配置它,但是了解它在应用程序中所担任的角色,以及如何解决这些问题是非常必要的。

下面我将从nginx在企业中的真实应用来解释nginx在应用程序中起到的作用。

为了便于理解,首先先来了解一下一些基础知识, nginx是一个高性能的反向代理服务器 那么什么是反向代理呢?

代理 是在服务器和客户端之间假设的一层服务器, 代理 将接收客户端的请求并将它转发给服务器,然后将服务端的响应转发给客户端。

不管是正向代理还是反向代理,实现的都是上面的功能。

正向代理 是为我们服务的,即为客户端服务的,客户端可以根据正向代理访问到它本身无法访问到的服务器资源。

正向代理 对我们是透明的,对服务端是非透明的,即服务端并不知道自己收到的是来自代理的访问还是来自真实客户端的访问。

反向代理 是为服务端服务的,反向代理可以帮助服务器接收来自客户端的请求,帮助服务器做请求转发,负载均衡等。

反向代理 对服务端是透明的,对我们是非透明的,即我们并不知道自己访问的是代理服务器,而服务器知道反向代理在为他服务。

下面是一个nginx配置文件的基本结构:

下面是 nginx 一些配置中常用的内置全局变量,你可以在配置的任何位置使用它们。

| 变量名 | 功能 | | ------ | ------ | | $host | 请求信息中的 Host ,如果请求中没有 Host 行,则等于设置的服务器名 | | $request_method | 客户端请求类型,如 GET 、 POST | $remote_addr | 客户端的 IP 地址 | | $args | 请求中的参数 | | $content_length | 请求头中的 Content-length 字段 | | $http_user_agent | 客户端agent信息 | | $http_cookie | 客户端cookie信息 | | $remote_addr | 客户端的IP地址 | | $remote_port | 客户端的端口 | | $server_protocol | 请求使用的协议,如 HTTP/1.0 、·HTTP/1.1 | | server_name | 服务器名称| | $server_port`|服务器的端口号|

先追本溯源以下,跨域究竟是怎么回事。

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。通常不允许不同源间的读操作。

如果两个页面的协议,端口(如果有指定)和域名都相同,则两个页面具有相同的源。

例如:

现在我在 fe.server.com 对 dev.server.com 发起请求一定会出现跨域。

现在我们只需要启动一个nginx服务器,将 server_name 设置为 fe.server.com ,然后设置相应的location以拦截前端需要跨域的请求,最后将请求代理回 dev.server.com 。如下面的配置:

这样可以完美绕过浏览器的同源策略: fe.server.com 访问 nginx 的 fe.server.com 属于同源访问,而 nginx 对服务端转发的请求不会触发浏览器的同源策略。

根据状态码过滤

根据URL名称过滤,精准匹配URL,不匹配的URL全部重定向到主页。

根据请求类型过滤。

GZIP 是规定的三种标准HTTP压缩格式之一。目前绝大多数的网站都在使用 GZIP 传输 HTML 、 CSS 、 JavaScript 等资源文件。

对于文本文件, GZip 的效果非常明显,开启后传输所需流量大约会降至 1/4 ~ 1/3 。

并不是每个浏览器都支持 gzip 的,如何知道客户端是否支持 gzip 呢,请求头中的 Accept-Encoding 来标识对压缩的支持。

启用 gzip 同时需要客户端和服务端的支持,如果客户端支持 gzip 的解析,那么只要服务端能够返回 gzip 的文件就可以启用 gzip 了,我们可以通过 nginx 的配置来让服务端支持 gzip 。下面的 respone 中 content-encoding:gzip ,指服务端开启了 gzip 的压缩方式。

这里为什么默认版本不是 1.0 呢?

HTTP 运行在 TCP 连接之上,自然也有着跟 TCP 一样的三次握手、慢启动等特性。

启用持久连接情况下,服务器发出响应后让 TCP 连接继续打开着。同一对客户/服务器之间的后续请求和响应可以通过这个连接发送。

为了尽可能的提高 HTTP 性能,使用持久连接就显得尤为重要了。

HTTP/1.1 默认支持 TCP 持久连接, HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。对于 TCP 持久连接上的 HTTP 报文,客户端需要一种机制来准确判断结束位置,而在 HTTP/1.0 中,这种机制只有 Content-Length 。而在 HTTP/1.1 中新增的 Transfer-Encoding: chunked 所对应的分块传输机制可以完美解决这类问题。

nginx 同样有着配置 chunked的 属性 chunked_transfer_encoding ,这个属性是默认开启的。

Nginx 在启用了 GZip 的情况下,不会等文件 GZip 完成再返回响应,而是边压缩边响应,这样可以显着提高 TTFB ( Time To First Byte ,首字节时间,WEB 性能优化重要指标)。这样唯一的问题是, Nginx 开始返回响应时,它无法知道将要传输的文件最终有多大,也就是无法给出 Content-Length 这个响应头部。

所以,在 HTTP1.0 中如果利用 Nginx 启用了 GZip ,是无法获得 Content-Length 的,这导致HTTP1.0中开启持久链接和使用 GZip 只能二选一,所以在这里 gzip_http_version 默认设置为 1.1 。

如上面的图,前面是众多的服务窗口,下面有很多用户需要服务,我们需要一个工具或策略来帮助我们将如此多的用户分配到每个窗口,来达到资源的充分利用以及更少的排队时间。

把前面的服务窗口想象成我们的后端服务器,而后面终端的人则是无数个客户端正在发起请求。负载均衡就是用来帮助我们将众多的客户端请求合理的分配到各个服务器,以达到服务端资源的充分利用和更少的请求时间。

Upstream指定后端服务器地址列表

在server中拦截响应请求,并将请求转发到Upstream中配置的服务器列表。

上面的配置只是指定了nginx需要转发的服务端列表,并没有指定分配策略。

轮询策略

默认情况下采用的策略,将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的,但是如果其中某一台服务器压力太大,出现延迟,会影响所有分配在这台服务器下的用户。

最小连接数策略

将请求优先分配给压力较小的服务器,它可以平衡每个队列的长度,并避免向压力大的服务器添加更多的请求。

最快响应时间策略

依赖于NGINX Plus,优先分配给响应时间最短的服务器。

客户端ip绑定

来自同一个ip的请求永远只分配一台服务器,有效解决了动态网页存在的session共享问题。

匹配以 png|gif|jpg|jpeg 为结尾的请求,并将请求转发到本地路径, root 中指定的路径即nginx本地路径。同时也可以进行一些缓存的设置。

nginx的功能非常强大,还有很多需要探索,上面的一些配置都是公司配置的真实应用(精简过了),如果您有什么意见或者建议,欢迎在下方留言...

❹ 利用nginx部署站点,前端资源默认放在

部署springboot+vue项目的时候,我们一般是将打包好的前端项目放在我们后端的resources目录下,然后前后端一起打包成jar包或者war包部署上服务器的。也就是说,如果前端项目发生修改的话,那么即使后端不用修改,前后端项目也要重新放在一起重新打包、重新部署。但是,前端项目打包往往是几mb大小,而后端项目打包却要几十mb。因此,为了方便,我们可以使用Nginx独立部署前端项目。

一、 Nginx安装步骤

1、安装GCC、automake、pcre、zlib和openssl

用rpm -qa 命令查看是否安装

如果没有安装,执行以下命令

yum -y install gcc gcc-c++ automake pcre pcre-devel zlib zlib-devel openssl openssl-devel
1
2、下载Nginx

我是安装在 /www/server目录的

cd /www/server
1
weget命令下载

wget http://nginx.org/download/nginx-1.16.1.tar.gz
1
tar zxvf 解压

tar zxvf nginx-1.16.1.tar.gz
1
重命名 nginx-1.16.1文件夹

mv nginx-1.16.1 nginx
1

3、安装Nginx,默认安装目录:/usr/local/nginx

进入nginx文件夹,运行configure脚本

cd nginx
./configure
1
2
编译、安装

make
make install
1
2
切换到安装目录

cd /usr/local/nginx
1

注意:html:存放了两个后缀名为.html的静态文件,前端项目打包后的文件放在此处,编辑好配置文件,启动Nginx服务器即可成功部署前端项目。

4、修改配置文件、开放端口

vim /usr/local/nginx/conf/nginx.conf
1
端口改为 8051

5、启动Nginx

cd /usr/local/nginx
./sbin/nginx
1
2
6、其他命令

查看进程

ps -ef|grep nginx
1
重启Nginx

/usr/local/nginx/sbin/nginx -s reopen
1
停止Nginx

/usr/local/nginx/sbin/nginx -s stop
1
重载Nginx配置文件

/usr/local/nginx/sbin/nginx -s reload
1
7、访问

curl 127.0.0.1:8051
1

如果访问不了,服务器安全组开放端口以及防火墙放行端口

firewall-cmd --zone=public --add-port=8051/tcp --permanent
1
firewall-cmd --reload
1
二、前端项目独立部署

1、将打包的前端项目上传到/usr/local/nginx/html目录

2、 重新启动即可成功访问到前端项目

/usr/local/nginx/sbin/nginx -s reopen
1
可能遇到的问题

1、刷新页面查询404的情况,也就是页面找不到

修改Nginx配置文件

try_files $uri $uri/ /index.html;
1

重新加载配置文件重启Nginx

❺ 使用Tomcat和Nginx部署前端项目

第一种方式,将我们的前端项目放置在webapps目录下

进入tomcat安装路径下的conf目录,在server.xml文件中<Host>标签内配置虚拟路径

简单的解释一下参数
path 对应用户请求过来的url路径, /static 匹配所有以 /static 开头的请求
docBase 表示实际匹配到的路径,这里可以使用绝对路径,也可以使用相对路径
reloadable 如果为true,则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化。(对于静态资源来说,个人觉得这个配置用处不大)
总结起来就是,对于ip:8080/static的资源请求,会通过虚拟路径匹配到我们实际的资源路径music_client/static。
配置好后重启,我们可以发现已经能够看到我们的前端项目了

对于ROOT目录下的资源,tomcat可以直接在根目录下进行访问。通过这种方式,我们可以让项目的路径去适配tomcat访问的路径。
但是这种方式不是特别推荐,当有多个项目在同一个tomcat服务器上的时候,会不方便管理。

Nginx是当下热门的服务器,使用起来只需要进行简单的配置即可。对于Nginx的安装大家可以自行网络解决。
我们先进入到usr/local/nginx(具体以实际nginx安装目录为准)下的conf目录,vim编辑nginx.xml。主要进行下面的配置

简单的解释一下
listen 表示nginx监听的端口号,也就是你希望暴露哪个端口给用户进行访问
server_name 表示nginx接受请求的域名,一般默认localhost就行
location 模块用于响应请求,这里的 / 表示匹配8082端口的所有请求
root 表示静态资源/项目的路径
index 表示默认的访问资源
配置完成后,进入 sbin 目录下,通过 ./nginx -t 检查配置文件的格式是否正确
如正确 ./nginx 进行启动或者 ./nginx -s reload 进行重启
启动完,我们就可以直接ip:8082直接访问我们的前端项目啦

开启nginx的反向代理也比较简单,只需要加上proxy_pass 配置即可

出现这个问题的原因是: 在history模式下,只是动态的通过js操作window.history来改变浏览器地址栏里的路径,并没有发起http请求,但是当我们直接在浏览器输入这个地址的时候,就会对服务器发起http请求,但是这个目标在服务器上又不存在,所以会返回404。
我们可以通过把所有请求都转发到首页上来解决这个问题。只需要在 Nignx 中的配置文件加入如下配置:

事实上,上面的解决方式也是Vue-Router官方推荐的解决方式( https://router.vuejs.org/zh/guide/essentials/history-mode.html#nginx )。
那上面的 try_files 为什么能帮助我们解决这个问题呢?我们可以看一下这个属性的作用

try_files :按选项所指定的顺序去检查用户请求的文件是否存在,如果本地存在的话则返回该请求;不存在的话将该请求转发到指定的其它路径。也就是说,比如我们当前的前端项目部署在 /usr/myproj 目录下,现在我们在浏览器发起 ip:port/testApi 请求,那么此时 uri 为testApi,nginx会先去 $root/testApi (即/usr/local/myproj/testApi)找是否存在该静态资源,若不存在,则继续寻找 $root/testApi/index (即/usr/local/myproj/testApi/index)文件是否存在,如果还是不存在,则会把请求转发到首页。

而我们的项目本事就是由Vue-Cli创建的 单页面应用 ,当index页面接收到请求的时候,对应的history模式路由就可以发挥作用了,根据浏览器的路由跳转到对应的页面,这也就保证了我们的路由请求都能够转发给index页面来进行处理。

这种问题一般是出现在服务器一开始安装Nginx的时候,没有安装SSL模块。在不重装Nignx的情况下,可以安装如下方式进行操作:

执行如下命令

这一步只是以防万一,可以省略

也可以直接执行 ./usr/local/nginx/sbin/nginx -t 看还会不会报错就行

nginx报错: [emerg] https protocol requires SSL support in /usr/local/nginx/conf/nginx.conf:50

❻ nginx 部署多个前端vue项目的3种方式,一篇文章搞定

首先我们看一下nginx.conf配置文件

为了方便管理,在/usr/local/nginx/conf.d/ 创建自己的*.conf配置文件。没有conf.d目录,直接mkdir 创建conf.d
*.conf 详细可参考:

这种方式只需要开放80端口,然后访问二级域名。

这种方式的好处是只有一个server ,而且不需要二级域名、用路径location就能实现。

但是这种方式的一个缺点,就是vue项目前端需要改配置。修改地方如下:

react 配置请参考: https://blog.csdn.net/mollerlala/article/details/96427751?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBai-2&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBai-2

vue 配置请参考: https://blog.csdn.net/weixin_33868027/article/details/92139392

❼ nginx部署前端纯页面

1.进入nginx配置文件vim .../nginx-1.9.12/conf/nginx.conf。

如上图所示:第一个红框中的内容就是应用服务器的地址;第二个红框中的内容就是前端包的位置。

此时,配置文件已经准备完毕。这个包和端口可以存在多个。

2.进入.../nginx-1.9.12/sbin 找到nginx的启动程序。

nginx -c ../nginx-1.9.12/conf/nginx.conf    启动nginx程序,并指定配置文件。

3.如果要替换包,则直接替换就行,nginx为热加载自动更新的。但是以防有缓存之类的存在,可以使用nginx -s reload命令进行重载一次。

追加 一 :

如果前端包的构造如下图

则location配置依然如下图

但是访问地址则需要指定到具体的html文件上。。

绑定: http://127.0.0.1:48110/binding.html

成功: http://127.0.0.1:48110/success.html

失败: http://127.0.0.1:48110/error.html

追加 二:

同一个端口部署多个页面:

一个server下,多个 location。

location的作用就是是否有后缀,并且这个后缀会去拼接root后的地址。

比如第二个location /sis/。

则在访问127.0.0.1:8080/sis时,会去自动寻找/apps/svr/nginx-1.9.12/pagefile/0921/sis这个包。   (Ps:location后的地址一定要用 / 关闭,比如 location /sis/,不然访问127.0.0.1:8080/sis时,会报错,只有用127.0.0.1:8080/sis/才行。)

这样就部署好了一个 端口支持多个页面。