⑴ 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 知识
“ 关注 前端开发社区 ，回复 ' 领取资源 '，免费领取Vue，小程序，Node Js，前端开发用的插件以及面试视频等学习资料，让我们一起学习，一起进步
<figcaption style="margin-top: 5px; text-align: center; color: #888; font-size: 14px;">作者:树酱 来源: 掘金</figcaption>
当有一台服务器宕机时，负载均衡器就分配其他的服务器给用户，极大的增加的网站的稳定性 当用户访问web时候，首先访问到的是 负载均衡器 ，再通过负载均衡器将请求转发给后台服务器
如果检测出其中某台服务器异常,那么在通过客户端请求 nginx 反向代理进来的都不会被发送到该服务器上（直至下次轮训健康检查正常）
基本例子如下👇
涉及两个配置：
反向代理的优势主要有以下两点:
当你的应用不想直接暴露给客户端（也就是客户端无法直接通过请求访问真正的服务器，只能通过 Nginx ），通过 nginx 过滤掉没有权限或者非法的请求，来保障内部服务器的安全
也就上一章提到负载均衡，本质上负载均衡就是反向代理的一种应用场景，可以通过 nginx 将接收到的客户端请求" 均匀地 "分配到这个集群中所有的服务器上(具体看负载均衡方式),从而实现服务器压力的 负载均衡
我们通过模拟内部服务器的端口启动的 nodejs 项目设置反向代理到80端口访问
在 Nginx 反向代理是，会通过 location 功能匹配指定的 URI ，然后把接收到的符合匹配 URI的请求通过 proxy_pass 转移给之前定义好的 upstream 节点池
建立白名单
修改nginx配置(nginx.conf)
为匹配项做白名单设置
假如我们在程序文件夹下有一个 ngxin 配置文件： /home/app/app.nginx.conf 我们需要给这个文件创建一个软链接到 /etc/nginx/conf.d/ 下：
这样操作之后，当我们改应用配置文件， /etc/nginx/conf.d/ 下与之对应的配置文件也会被修改，修改后重启 nginx 就能够使新的 ngxin 配置生效了。
往期
安利几个JS开发的小技巧
请各位帅哥美女多多支持帅编，回复“ 加群 ”即可领取 前端干货
⑶ 前端工程师怎么充分利用nginx，更有效的进行web开发
前端工程师，也叫Web前端开发工程师。他是随着web发展，细分出来的行业。
Web前端开发技术主要包括三个要素：HTML、CSS和JavaScript！
它要求前端开发工程师不仅要掌握基本的Web前端开发技术，网站性能优化、SEO和服务器端的基础知识，而且要学会运用各种工具进行辅助开发以及理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持等。
随着近两三年来RIA（Rich Internet Applications的缩写，中文含义为：丰富的因特网应用程序）的流行和普及带来的诸如：Flash/Flex，Silverlight、XML和服务器端语言（PHP、ASP.NET，JSP、Python）等语言，前端开发工程师也需要掌握。
前端开发的入门门槛其实很低，与服务器端语言先慢后快的学习曲线相比，前端开发的学习曲线是先快后慢。
HTML 甚至不是一门语言，他仅仅是简单的标记语言！
CSS 只是无类型的样式修饰语言。当然可以勉强算作弱类型语言。
Javascript 的基础部分相对来说不难，入手还算快。
也正因为如此，前端开发领域有很多自学成“才”的同行，但大多数人都停留在会用的阶段，因为后面的学习曲线越来越陡峭，每前进一步都很难。
Web前端技术有一些江湖气，知识点过于琐碎，技术价值观的博弈也难分伯仲，即全局的系统的知识结构并未成体系，这些因素也客观上影响了“正统“前端技术的沉淀！而且各种“奇技淫巧”被滥用，前端技术知识的传承也过于泛泛，新人难看清时局把握主次。因此，前端技术领域，为自己觅得一个靠谱的师兄，重要性要盖过项目、团队、公司、甚至薪水。
另一方面，正如前面所说，前端开发是个非常新的职业，对一些规范和最佳实践的研究都处于探索阶段。
总有新的灵感和技术不时闪现出来，例如CSS sprite、负边距布局、栅格布局等；
各种JavaScript框架层出不穷，为整个前端开发领域注入了巨大的活力；
浏览器大战也越来越白热化，跨浏览器兼容方案依然是五花八门。
为了满足“高可维护性”的需要，需要更深入、更系统地去掌握前端知识，这样才可能创建一个好的前端架构，保证代码的质量。
随着手持设备的迅猛发展，带动了HTML5行业标准的快速发展。web领域的技术，大概有10年都没有大的更新了！
⑷ 我是做前端的，请教下nginx apache什么意思，在web上有具体应用是什么，
nginx和apache都是静态HTTP服务器，用于提供HTTP服务，主要展示静态的html页面。
⑸ 如何搞定前端资源服务跨域问题之nginx篇
通过add_header命令为响应增加跨域头：
add_header "Access-Control-Allow-Origin" "*";
⑹ 前端必须用nginx部署吗
是的。根据查询相关资料显示：前后端分别部署，前端使用Nginx部署，后端直接运行jar.
⑺ nginx 在前端中的简单应用
Web 服务实际上又称静态资源服务，自从前后端分离后，前端的输出趋向于静态资源的形式，什么是静态资源：就是我们通常用webpack构建输出的结果，比如：
而为了提供文件在互联网中的可访问性，前端还是需要依赖 静态资源服务 ；最常用的做法就是Node服务和Nginx服务。
Node服务最常见的，就是WebpackServer, 在前端开发联调时经常用到, 启动后我们就可以通过 http://localhost:8907/bundle.05a01f6e.js 的形式来访问构建资源；除此之外，我给大家安利另一款Node服务库： serve , 它也能快速启动一个静态资源服务。
但在生产环境，我们一般用Nginx来处理，不是Node不好，而是Nginx已经够好了。通常整个大前端会有很多前端项目，我们都将构建结果放在一台服务器上（一般有备份机器）的某个文件夹下,然后通过安装Nginx来创建一个静态资源服务供所有前端资源的访问；比如文件夹static下有A，B，C，D四个前端项目资源, 我们通过nginx配置:
我们即可通过 http://static.closertb.site/A 访问A项目，通过 http://static.closertb.site/C 访问C项目, 从而做到一鸡多吃，这种玩法在HTTPS与HTTP2的时代特别常见。
以上就是Nginx作为Web服务的简单用法，接下来我们了解一下反向代理服务
作为一个开发者，可能经常听到 代理 两字，但很多人区分不清楚正向和反向的区别：
如上图左侧所示，正向代理是用户的主动行为，如我们fq时访问goggle所做的；右侧反向代理是我们访问的服务器行为，作为用户的我们是不能控制也无需关注的。
反向代理在服务部署中，是一种非常常见的技术，比如负载均衡、容灾、缓存。
而对于前端开发来说，反向代理多用于请求转发，来处理 跨域 问题。当我们把前端静态资源服务都指向一个域名（static.closertb.site）时，与服务端请求域名（server.closertb.site）不一致，就会造成跨域。如果服务端不配合的话，那通过nginx，前端也是可以轻松做到的，在前面的配置上，我们添加：
所以当网页发出一个请求： http://static.closertb.site/a 时，实际请求地址是： http://server.closertb.site/a ，这就简单实现了一个服务代理。其原理与WebpackServer的proxy相似.
以上就是Nginx的web服务和代理服务在前端开发中的两个典型使用场景, 接下来我们说点零碎又有用的
当请求 http://static.closertb.site/site/a/logo.png )时，将会返回服务器上的/home/static/static/a/logo.png文件，即'/home/static'+'/static/a/logo.png',其 拼接的地址是匹配字符串及其以后的
而对于alias：
当请求 http://static.closertb.site/static/a/logo.png )时，将会返回服务器上的/home/static/a/logo.png文件，即'/home/static'+'/a/logo.png',其 拼接的地址是除了匹配字符串以后的地址
你可能见过A这种：
也可能见过B这种
有什么区别？
两者与root 和 alias有相似之处，只不过这种差别，只适用于：
所以当收到一个请求： http://static.closertb.site/api/user/get ) 时，配置A将会把请求代理到： http://server.closertb.site/api/user/get ); 配置B将会把请求代理到： http://server.closertb.site/user/get )
这个知识，在代理配置中真的相当重要
当我们下架一个前端服务，或者用户访问了某个根本不存在的页面，我们不希望用户看到的是404，而是将其引导到一个模糊正确的页面，这时候我可以用rewrite服务；反手一个配置，直接就将流量打到了网站首页;
另一个比较常用的，就是网站开启https，我们需要将所有http请求重定向到https：
上面同是rewrite，但还是有不一样的 ，一个是redirect（302）, 另一个是permanent（301），这两个还是有很大区别的；
web 性能优化是前端的一门学问，好的静态资源加载速度，会显着提升用户体验，而nginx作为最常用的静态资源服务器，也是有诸多渠道来帮助我们来提升静态资源加载速度，简单来讲，可以三个方面，直接上配置：
``if ( ) {
expires 365d;
add_header Cache-Control max-age=31536000;
}</pre>
expires与max-age两种配置方式都可以达到告诉浏览器资源一年以后过期的目的，更多关于http缓存的可以 看这一篇文章 ；
⑻ 如何搞定前端资源服务跨域问题之nginx篇
我们可以很清楚的看到当http请求的站点访问https的资源的时候会报出“Cross-Origin”跨域的问题。为什么会出现这样的错误，这是因为涉及到“同源策略”的问题。。。blablabla……
3、下面依次说如何解决这个问题
问题解决
1、我们再来看一下报错信息，报错信息中有一段写明“Access-Control-Allow-Origin”header的字样，我们可以由此看出会不会在服务端add header即可呢？
2、顺着这个思路，在nginx配置中加入了这样一句：
add_header 'Access-Control-Allow-Origin' '*';
如图所示：
3、重启之后，其他内容好了（例如，css文件等）发现字体（font）文件还是有问题的，如图所示：
这是为什么……！字体文件的Context-Type却是”text/html"！！！而且还没有像别的东东那样的 Access-Control-Allow-Origin:*
4、于是乎，继续增加了这样一句（如图所示），指定eot、ttf、woff字体文件 强制加入header信息
5、觉得这样万事大吉 就错了、错了、错了……重要的事情说三遍（这个地方是个巨坑、当时就是在下面要说的地方浪费了好长时间，不过最后还是解决了，不墨迹了，我们继续……）6、突然发现，哦，是不是因为我没加mime.types呢？（这个必须要加的，因为它决定文件的Content-Type）这个应该早点想起来的……blablabla…… 赶紧加上 回来再看……
于是乎加了三行：
application/x-font-woff woff woff2;
font/ttf ttf;
font/opentype otf;
【要删除 application/font-woff woff; 这行删掉(mime.types 第27行） 否则会报plicate的warning】
7、再次重启，再看！
Oh，My God 还是如此。。。
8、拿出杀手锏，查询log吧。
果然发现一个致命问题
哥，为啥你要去$NGINX_HOME/html目录去找啊，你不应该是从/www/xinghuo-img去找吗？(⊙o⊙)…
（旁白：谁告诉你 "location /" 和“location ~"会共用他们其中一个的root了。。。。
好吧……我错了。
9、于是乎，我在“location ~"也加一个root好了：）
10、“最后”一次重启，测试、搞定！如图所示：
后记
1、之前看安全测试的书籍中了解到了“同源策略”，今天是见识并实践了一下跨域问题的解决。涨姿势了！受益匪浅！
2、其实最后那个配置文件，可以修改为（如图所示），我姑且认为可以设置一个root全局变量，嘿嘿。
3、还是得继续学习、钻研呀……fighting。
4、它折磨我从两点到四点……还好顺利解决了。记录下来以便大家以后不用再次踩坑，谢谢！blablabla……
5、遇到问题及时查log非常重要、非常重要、非常重要……