如何搞定前端资源服务跨域问题之nginx篇

Posted 2023-05-16

　　我们可以很清楚的看到当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行） 否则会报duplicate的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非常重要、非常重要、非常重要…… 参考技术A 通过add_header命令为响应增加跨域头：1add_header "Access-Control-Allow-Origin" "*";

Linux服务之nginx服务篇一（概念）

nginx官网：http://nginx.org/

一、 nginx和apache的区别

Nginx：

1、轻量级，采用 C 进行编写，同样的 web 服务，会占用更少的内存及资源。

2、抗并发，nginx 以 epoll and kqueue 作为开发模型，处理请求是异步非阻塞的，负载能力比 apache 高很多，而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能 ，而 apache 在 PHP 处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。

3、nginx 处理静态文件好，静态处理性能比 apache 高三倍以上。

4、nginx 的设计高度模块化，编写模块相对简单。

5、nginx 配置简洁，正则配置让很多事情变得简单，而且改完配置能使用 -t 测试配置有没有问题，apache 配置复杂 ，重启的时候发现配置出错了，会很崩溃。

6、nginx 作为负载均衡服务器，支持 7 层负载均衡。

7、nginx 本身就是一个反向代理服务器，而且可以作为非常优秀的邮件代理服务器。

8、启动特别容易, 并且几乎可以做到 7*24 不间断运行，即使运行数个月也不需要重新启动，还能够不间断服务的情况下进行软件版本的升级

9、社区活跃，各种高性能模块出品迅速

Apache：

1、apache 的 rewrite 比 nginx 强大，在 rewrite 频繁的情况下，用 apache

2、apache 发展到现在，模块超多，基本想到的都可以找到

3、apache 更为成熟，少 bug ，nginx 的 bug 相对较多

4、apache 超稳定

5、apache 对 PHP 支持比较简单，nginx 需要配合其他后端用

6、apache 在处理动态请求有优势，nginx 在这方面是鸡肋，一般动态请求要 apache 去做，nginx 适合静态和反向。

apache 仍然是目前的主流，拥有丰富的特性，成熟的技术和开发社区

总结

两者最核心的区别在于 apache 是同步多进程模型，一个连接对应一个进程，而 nginx 是异步的，多个连接（万级别）可以对应一个进程

一般来说，需要性能的 web 服务，用 nginx 。如果不需要性能只求稳定，更考虑 apache ，后者的各种功能模块实现得比前者，例如 ssl 的模块就比前者好，可配置项多。epoll(freebsd 上是 kqueue ) 网络 IO 模型是 nginx 处理性能高的根本理由，但并不是所有的情况下都是 epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的 select 模型或许比 epoll 更高性能。当然，这只是根据网络 IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。

更为通用的方案是，前端 nginx 抗并发，后端 apache 集群，配合起来会更好。

二、集群

简单来说，集群就是指一组相互独立的计算机，利用高速通信网络组成的一个较大的计算机服务系统，每个集群节点都是运行各自服务的独立服务器。这些服务器之间可以彼此通信，协同向用户提供应用程序、系统资源和数据，并以单一系统的模式加以管理。当用户客户机请求集群系统时，集群给用户的感觉就是一个单一的服务器，而实际上用户请求的是一组集群服务器。

集群主要包括几大特点：高性能、价格有效性、可伸缩性、高可用性、透明性、可管理性和可编程性。

1、负载均衡集群

常见的负载均衡的架构包括有负载均衡集群、高可用性集群、高性能计算集群等等。这里着重介绍负载均衡集群，其他的集群方式不做介绍。

负载均衡集群为企业提供了更为实用、性价比更高的系统架构解决方案。负载集群可以把很多客户集中的访问请求负载压力尽可能平均分摊到计算机集群中处理。客户访问请求负载均衡通常包含应用程序处理负载均衡和网络流量负载。这样的系统非常适合使用同一组应用程序为大量用户提供服务的模式，每个节点都可以承当一定的访问请求负载压力，并且可以实现访问请求在各节点之间动态分配，以实现负载均衡。

负载均衡集群运行时，一般是通过一个或多个前端负载均衡器将客户访问请求分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。一般高可用性集群和负载均衡集群使用类似的技术，或同事具有高可用与负载均衡的特点。负载均衡的作用为：分担用户访问及数据流量、保持业务的连续性、应用于Web业务及数据库从库等服务器的业务。

2、Nginx负载均衡集群介绍

互联网企业中常见的开源集群软件有：Nginx、LVS、Haproxy、Keepalived等，硬件有F5、Netscaler等。

严格地说，Nginx仅仅是作为Nginx Proxy反向代理使用的，因为反向代理功能表现的效果是负载均衡集群的效果，所以也叫做Nginx负载均衡。反向代理和负载均衡的区别在于负载均衡通常都是对请求的数据包的转发（也有可能会改写数据包）、传递，其中DR模式明显的特征就是从负载均衡下面的节点服务器来看，接收到的请求还是来自负载均衡器的客户端的真实用户。而反向代理，反向代理接收访问用户的请求后，会代理用户重新发起请求代理下的节点服务器，最后把数据返回给客户端用户。在节点服务器来看，访问节点服务器的客户端用户是反向代理服务器，而不是真实的网站访问用户。

Nginx负载均衡的模块主要有两个，ngx_http_proxy_module，ngx_http_upstream_module。编译的时候需要把这两个模块编译进去。