前言： 我们在访问淘宝的时候，会看到代码中的js和css文件是通过一次请求或得的，我们知道浏览器一次请求只能并发访问数个资源，这样的处理错输在网络传输层面可以大大节省时间，这里使用的技术就是把css、js等静态资源合并为一个资源。淘宝使用的tengine是基于nginx的web服务器，从11年底开源。所使用的是mod_concat模块，合并多个文件在一个响应报文中。 http1.1下浏览器的并发访问资源数 IE6 2 IE7 2 IE8 6 Firefox2 2 Firefox3 6 Safari 3,4 […]
View DetailsCentos7下nginx配置https 在互联网信息安全日益重要的今天，https协议几乎成了标配，部分浏览器如果遇到非https的服务器会拒绝访问，有的平台也要求app的服务器要用https协议（如苹果、微信小程序）。 下面是个人配置https的笔记，先完整记录下来，不然到时遇到问题又各种百度。 一、步骤1 配置nginx 假如你已经申请到了https证书，而且有nginx下的版本，通常是两个文件，一个是 .key 后缀的文件，为证书的私钥，另一个是 .crt 后缀的文件，为证书的公钥。 nginx.conf 配置如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
server { listen 443 ssl; server_name www.server.com default_server; #1 ssl_certificate ssl/bundle.crt; #2 ssl_certificate_key ssl/cert.key; #3 ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; } |
把#1所在行的 www.sever.com 改成你的域名（注意：这个域名是你申请证书时用的域名）。 把#2所在行的 ssl/bundle.crt* 改成你实际文件的路径，如果是相对路径，那么是相对于nginx的conf目录的路径。 把#3所在行的 ssl/cert.key* 改成你实际文件的路径，如果是相对路径，那么是相对于nginx的conf目录的路径。 如果要让用户用http协议访问时自动跳转https，则还需加上如下配置：
|
1 2 3 4 5 |
server { listen 80; server_name www.server.com; rewrite ^(.*)$ https://www.server.com; } |
就是一个url重写而已。 注意要把 www.server.com 改成你实际的主机名。 配置完后，用如下命令
|
1 |
nginx -t |
测试下配置文件有没有错误。 如果没有错误，用如下命令
|
1 |
nginx -s reload |
重启nginx，然后用浏览器测试下用https协议能否正常访问服务器。 如果不能访问，请确认下证书路径有没有问题，如果没有，请看下面的 步骤2。 二、步骤2 开启服务器的防火墙 需要该步骤是因为服务器的防火墙没有开通443端口。 centos7 下用的防火墙是firewalld，配置防火墙用命令firewall-cmd。 开通443端口
|
1 |
firewall-cmd --zone=public --add-port=443/tcp --permanent |
确认是否开通
|
1 |
firewall-cmd --list-ports |
如果可以看到443/tcp字样就说明开通了 重新加载下防火墙配置
|
1 |
firewall-cmd --reload |
执行完该步骤，大多数服务器应该可以正常用https协议访问。 如果不能，如果你用的是阿里云服务器，请看步骤3。如果是其它服务器，请自行百度。 步骤3 在安全组规则开通443端口 需要该步骤的原因是因为云服务器的安全组规则上没有开通相关的端口。 做完步骤3，应该可以用https了。如果还不能，提交工单问技术人员吧。或者再检查下步骤1与步骤2有没有做到位。 from:https://blog.csdn.net/chunyuan314/article/details/77369110
View Details原文：http://blog.csdn.net/wzy_1988/article/details/8549290 需求简介 基于nginx搭建了一个https访问的虚拟主机，监听的域名是test.com，但是很多用户不清楚https和http的区别，会很容易敲成http://test.com，这时会报出404错误，所以我需要做基于test.com域名的http向https的强制跳转 我总结了三种方式，跟大家共享一下 nginx的rewrite方法 思路 这应该是大家最容易想到的方法，将所有的http请求通过rewrite重写到https上即可 配置 server { listen 192.168.1.111:80; server_name test.com; rewrite ^(.*)$ https://$host$1 permanent; } 搭建此虚拟主机完成后，就可以将http://test.com的请求全部重写到https://test.com上了 nginx的497状态码 error code 497 497 – normal request was sent to HTTPS 解释：当此虚拟站点只允许https访问时，当用http访问时nginx会报出497错误码 思路 利用error_page命令将497状态码的链接重定向到https://test.com这个域名上 配置 server { listen 192.168.1.11:443; #ssl端口 listen 192.168.1.11:80; #用户习惯用http访问，加上80，后面通过497状态码让它自动跳到443端口 server_name test.com; #为一个server{……}开启ssl支持 ssl on; #指定PEM格式的证书文件 ssl_certificate /etc/nginx/test.pem; #指定PEM格式的私钥文件 ssl_certificate_key /etc/nginx/test.key; #让http请求重定向到https请求 error_page 497 https://$host$uri?$args; } index.html刷新网页 思路 上述两种方法均会耗费服务器的资源，我们用curl访问baidu.com试一下，看百度的公司是如何实现baidu.com向www.baidu.com的跳转 可以看到百度很巧妙的利用meta的刷新作用，将baidu.com跳转到www.baidu.com.因此我们可以基于http://test.com的虚拟主机路径下也写一个index.html，内容就是http向https的跳转 index.html [html] view plaincopyprint? <html> <meta http-equiv="refresh" content="0;url=https://test.com/"> </html> nginx虚拟主机配置 server { listen 192.168.1.11:80; server_name test.com; location / { #index.html放在虚拟主机监听的根目录下 root /srv/www/http.test.com/; } #将404的页面重定向到https的首页 error_page 404 https://test.com/; } 后记 上述三种方法均可以实现基于nginx强制将http请求跳转到https请求，大家可以评价一下优劣或者根据实际需求进行选择。 from:http://www.cnblogs.com/yun007/p/3739182.html
View Details在前面《Nginx服务器开箱体验》 一文中我们从开箱到体验，感受了一下Nginx服务器的魅力。Nginx是轻量级的高性能Web服务器，提供了诸如HTTP代理和反向代理、负载均衡、缓存等一系列重要特性，因而在实践之中使用广泛，笔者也在学习和实践之中。
在本文中，我们继续延续前文，从前文给出的一份示例配置清单开始，详解一下Nginx服务器的各种配置指令的作用和用法。
在阅读本文前，大家要有一个概念，在实现正常的TCP/IP 双方通信情况下，是无法伪造来源 IP 的，也就是说，在 TCP/IP 协议中，可以伪造数据包来源 IP ，但这会让发送出去的数据包有去无回，无法实现正常的通信。这就像我们给对方写信时，如果写出错误的发信人地址，而收信人按信封上的发信人地址回信时，原发信人是无法收到回信的。 一些DDoS 攻击，如 SYN flood, 就是利用了 TCP/ip 的此缺陷而实现攻击的。《计算机网络》教材一书上，对这种行为定义为“发射出去就不管”。 因此，本文标题中的伪造来源IP 是带引号的。并非是所有 HTTP 应用程序中存在此漏洞。 那么在HTTP 中， " 伪造来源 IP", 又是如何造成的？如何防御之？ 在理解这个原理之前，读者有必要对HTTP 协议有所了解。 HTTP 是一个应用层协议，基于请求 / 响应模型。客户端（往往是浏览器）请求与服务器端响应一一对应。 请求信息由请求头和请求正文构成（在GET 请求时，可视请求正文为空）。请求头类似我们写信时信封上的基本信息，对于描述本次请求的一些双方约定。而请求正文就类似于信件的正文。服务器的响应格式，也是类似的，由响应头信息和响应正文构成。 为了解这个原理，可使用Firefox Firebug, 或 IE 浏览器插件 HTTPwatch 来跟踪 HTTP 请求 / 响应数据。 本文中，以HTTPwatch 为例说明之。安装 httpwatch 并重启 IE 浏览器后， IE 的工具栏上出现其图标，点击并运行 Httpwatch, 就会在浏览器下方显示出 HTTPWatch 的主界面。 点击左下角红色的“Record ”按钮，并在地址栏输入 www.baidu.com, 等页面打开后，选中一个请求，并在下方的 tab 按钮中选择“ Stream ”，如图： 左边即是请求数据，右边即是服务器响应数据。左边的请求头均以回车换行结束，即“\r\n ” , 最后是一个空行（内容为 \r\n ） , 表示请求 header 结束。而请求 header 中除第一行外，其它行均由 header 名称， header 值组成，如 Accept-Encoding: gzip, deflate ， header 名称与值之间有冒号相隔，之间的空格是可有可无的。 那么，在HTTP 应用程序中，如何取得指定的请求 header 信息呢？这里使用 PHP 语言为例说明。对所有客户端请求 header, PHP 程序中取得其值的方式如下： $_SERVER['HTTP_ HEADER_NAME '] HEADER_NAME应该以换成对应的 header 名称，此项的规律是：全大写，连接线变成下划线。比如要取得客户端的User-Agent 请求头，则使用 $_SERVER['HTTP_USER_AGENT'], 掌握这个规律，即可达到举一反三的效果。如要取得 COOKIE 信息，则使用 $_SERVER['HTTP_COOKIE'] 即可。也就是说， $_SERVER 数组中，以 HTTP 开头的项均属于客户端发出的信息。 回归到HTTP 应用程序层，来源 IP 的重要性不言而语，例如表单提交限制，频率等等均需要客户端 IP 信息。使用流行的 Discuz X2.5 的文件 source/class/discuz/discuz_application.php 中的代码片断： private function _get_client_ip() { $ip = $_SERVER['REMOTE_ADDR']; if (isset($_SERVER['HTTP_CLIENT_IP']) && preg_match('/^([0-9]{1,3}\.){3}[0-9]{1,3}$/', $_SERVER['HTTP_CLIENT_IP'])) { $ip = $_SERVER['HTTP_CLIENT_IP']; 如以下的JSP代码片段： public String getIpAddr(HttpServletRequest request) { String ip = request.getHeader("x-forwarded-for"); if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) { ip = request.getHeader("Proxy-Client-IP"); } if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) { ip = request.getHeader("WL-Proxy-Client-IP"); } if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) { ip = request.getRemoteAddr(); } return ip; } 以上代码片段即是获取客户端IP ，这段程序会尝试检查 HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, 根据之前的原理说明，以 HTTP_ 开头的 header, 均属于客户端发送的内容。那么，如果客户端伪造 Client-Ip, X-Forward-For ，不就可以欺骗此程序，达到“伪造 IP ”之目的？ 那么如何伪造这项值？如果你会写程序，并了解HTTP 协议，直接伪造请求 header 即可。或者使用 Firefox 的Moify Headers 插件即可。 按图示顺序号输入或点击相应按钮。Start 按钮这里变为红色 Stop ，说明设置成功。 这时，如果我们使用Firefox 访问其它网站，网站服务器就针接收到我们伪造的 X-Forward-For, 值为 1.1.1.1 。 严格意义上讲，这并不是程序中的漏洞。Discuz 为了保持较好的环境兼容性 ( 包含有反向代理的 web 服务器环境，如 nginx 作为 php fastcgi 的前端代理 ) ，如此处理是可以理解的。那么如何处理，才能杜绝这个问题呢？ 服务器重新配置X-Forward-For 为正确的值。 如对典型的nginx + php fastcgi 环境（ nginx 与 php fastcgi 是否位于同一机器，并不妨碍此问题的产生） , nginx和 php fastcig 进程直接通信： 切记，$_SERVER['REMOTE_ADDR'] 是由 nginx 传递给 php 的参数，就代表了与当前 nginx 直接通信的客户端的 IP （是不能伪造的）。 再比如，存在中间层代理服务器的环境： 这种情况下，后端的HTTP 文件服务器上获取取的 REMOTE_ADDR 永远是前端的 squid/varnish cache 服务器的通信 IP 。 服务器集群之间的通信，是可以信任的。我们要做的就是在离用户最近的前端代理上，强制设定X-Forward-For 的值，后端所有机器不作任何设置，直接信任并使用前端机器传递过来的 X-Forward-For 值即可。 即在最前端的Nginx 上设置： location ~ ^/static { proxy_pass ….; proxy_set_header X-Forward-For $remote_addr ; […]
View DetailsOpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。 OpenResty® 通过汇聚各种设计精良的 Nginx 模块（主要由 OpenResty 团队自主开发），从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样，Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块，快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统。 OpenResty® 的目标是让你的Web服务直接跑在 Nginx 服务内部，充分利用 Nginx 的非阻塞 I/O 模型，不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都进行一致的高性能响应。 from:http://openresty.org/cn/
View Details在nginx配置文件增加以下代码
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
location / { # 如果请求的文件已存在，直接返回 if (-f $request_filename) { break; } set $supercache_file ''; set $supercache_uri $request_uri; set $supercache 1; set $ihttp_host ''; if ($request_method = POST) { set $supercache 0; } # 仅在访问文章永久链接时使用静态文件，请求中带参数则不使用静态缓存 set $qs 0; if ($query_string) { set $qs 1; } # 不过从 twitter, facebook, feedburner 链接点过来的，总是带参数，这些访问仍然可以使用静态文件 if ($query_string ~* "^utm_source=([^&]+)&utm_medium([^&]+)&utm_campaign=([^&]+)(&utm_content=([^&]+))?$") { set $qs 0; set $supercache_uri $document_uri; } #deactivate on high load if ($qs = 1) { set $supercache 0; } # 针对已登录用户（发表过评论），可以不静态化。在访问量高峰时可注释掉 if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) { set $supercache 0; } # 支持移动设备，访问移动版本的网页缓存 if ($http_user_agent ~* '(iphone|ipod|aspen|incognito|webmate|android|dream|cupcake|froyo|blackberry9500|blackberry9520|blackberry9530|blackberry9550|blackberry 9800|webos|s8000|bada)') { set $ihttp_host '-mobile'; } # 指定静态缓存文件的路径 if ($supercache = 0) { set $supercache_uri ''; } if ($supercache_uri ~ ^(.+)$) { set $supercache_file /wp-content/cache/supercache/$http_host$1/index${ihttp_host}.html; } # 只有当缓存文件存在时，才进行 rewrite if (-f $document_root$supercache_file) { #rewrite ^(.*)$ $supercache_file break; rewrite ^ $supercache_file last; } # 所有其他请求，转给 wordpress 处理 if (!-e $request_filename) { rewrite . /index.php last; } |
针对已登录用户（发表过评论），可以不静态化。在访问量高峰时可注释掉
|
1 2 3 4 5 |
if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) { set $supercache 0; } } |
from:http://blog.csdn.net/wangdada111/article/details/71189332
View Details为了在前端正确地显示字体，浏览器必须使用正确的http header来接受字体文件。如果服务器没有设置要求的头信息，那么有些浏览器就会在控制台报错或者直接不能显示。 可能你的服务器已经配置好了，你无须再动任何东西。如果没有配置好，那么你需要注意下面几点： 首先，修改mime-type headers； 其次设置CORS headers-仅当你从不同域下获取字体文件或者html页面的时候。（*注意：如果你没有设置CORS headers信息，你可以直接把字体文件（路径）嵌入到CSS样式中。如果你去fontello网站下载到本地的话fontello.css中就已经这样做好了） 下面介绍两大主流服务器的字体支持配置： Apache 设置正确的mime-type来支持字体文件，将下面的设置加入到服务器配置文件中：
|
1 2 3 4 |
AddType <span class="hljs-type">application</span>/font-sfnt otf ttf AddType <span class="hljs-type">application</span>/font-woff woff AddType <span class="hljs-type">application</span>/font-woff2 woff2 AddType <span class="hljs-type">application</span>/vnd.ms-fontobject eot |
如果你不能修改配置文件，那么就在你的项目下新建一个*.htaccess文件，添加下面的设置： 设置CORS headers 信息：
|
1 2 3 |
<span class="hljs-subst"><</span>FilesMatch <span class="hljs-string">".(eot|ttf|otf|woff|woff2)"</span><span class="hljs-subst">></span> <span class="hljs-keyword">Header</span> <span class="hljs-built_in">set</span> Access<span class="hljs-attribute">-Control</span><span class="hljs-attribute">-Allow</span><span class="hljs-attribute">-Origin</span> <span class="hljs-string">"*"</span> <span class="hljs-subst"><</span>/FilesMatch<span class="hljs-subst">></span> |
Nginx Nginx服务器默认是没有支持字体的mime-type设置的，并且对.eot文件的mime-type也是不正确的。在配置文件夹下找到mime-type设置的地方。通常，在mimes.types文件下。 搜索.eot，并在下它的设置下添加下面几行：
|
1 2 3 4 |
<span class="hljs-type">application</span>/font-sfnt otf ttf; <span class="hljs-type">application</span>/font-woff woff; <span class="hljs-type">application</span>/font-woff2 woff2; <span class="hljs-type">application</span>/vnd.ms-fontobject eot; |
对于CORS headers 信息设置，添加下面的几行到你的vhost配置中：
|
1 2 3 4 |
location ~<span class="hljs-subst">*</span> <span class="hljs-subst">\</span><span class="hljs-built_in">.</span>(eot<span class="hljs-subst">|</span>otf<span class="hljs-subst">|</span>ttf<span class="hljs-subst">|</span>woff<span class="hljs-subst">|</span>woff2)$ { add_header Access<span class="hljs-attribute">-Control</span><span class="hljs-attribute">-Allow</span><span class="hljs-attribute">-Origin</span> <span class="hljs-subst">*</span>; } |
from:http://blog.csdn.net/yypsober/article/details/52012577
View Details安装nginx yum install nginx 设置nginx开启起动 systemctl start nginx 测试 访问http://你的域名或IP/ 查看nginx安装位置 whereis nginx nginx: /usr/sbin/nginx /etc/nginx /usr/share/nginx /usr/share/man/man3/nginx.3pm.gz /usr/share/man/man8/nginx.8.gz 安装php yum install php php-mysql php-fpm 安装过程中经常会见到如下问题： 2:postfix-2.10.1-6.el7.x86_64 有缺少的需求 libmysqlclient.so.18()(64bit) 2:postfix-2.10.1-6.el7.x86_64 有缺少的需求 libmysqlclient.so.18(libmysqlclient_18)(64bit) 解决方法： 把php-mysql换成php-mysqlnd 即执行 yum install php php-mysqlnd php-fpm 配置php处理器 vim /etc/php.ini 查找cgi.fix_pathinfo 将 ;cgi.fix_pathinfo=1改为cgi.fix_pathinfo=0 配置www.conf vim /etc/php-fpm.d/www.conf 将 user = nobody group = nobody 改为 user = nginx group = nginx 前提是已经创建了nginx用户和nginx组。 起动php-fpm systemctl start php-fpm 设置php-fpm开机启动 systemctl enable php-fpm 配置nginx 打开/etc/nginx/conf.d/default.conf，如果不存在则创建 粘贴 server { listen 80; server_name server_domain_name_or_IP; note that these lines are originally from […]
View Details