来源：蜘蛛抓取(WebSpider)
时间：2016-09-09 04:18
标签：
nginx 过滤非法请求
看了下nginx的官方文档，其中nginx如何处理一个请求讲解的很好，现在贴出来分享下。Nginx首先选定由哪一个虚拟主机来处理请求。让我们从一个简单的配置（其中全部3个虚拟主机都在端口*：80上监听）开始：
1 server {
server_name example.org www.example.
7 server {
server_name example.net www.example.
13 server {
在这个配置中，nginx仅仅检查请求的&Host&头以决定该请求应由哪个虚拟主机来处理。如果Host头没有匹配任意一个虚拟主机，或者请求中根本没有包含Host头，那nginx会将请求分发到定义在此端口上的默认虚拟主机。在以上配置中，第一个被列出的虚拟主机即nginx的默认虚拟主机&&这是nginx的默认行为。而且，可以显式地设置某个主机为默认虚拟主机，即在"listen"指令中设置"default_server"参数：
1 server {
80 default_
server_name example.net www.example.
下面让我们来看一个复杂点的配置，在这个配置里，有几个虚拟主机在不同的地址上监听：
192.168.1.1:80;
server_name example.org www.example.
192.168.1.1:80;
server_name example.net www.example.
192.168.1.2:80;
这个配置中，nginx首先测试请求的IP地址和端口是否匹配某个server配置块中的listen指令配置。接着nginx继续测试请求的Host头是否匹配这个server块中的某个server_name的值。如果主机名没有找到，nginx将把这个请求交给默认虚拟主机处理。例如，一个从192.168.1.1:80端口收到的访问的请求将被监听192.168.1.1:80端口的默认虚拟主机处理，本例中就是第一个服务器，因为这个端口上没有定义名为的虚拟主机。
阅读(...) 评论()<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&Nginx部署一部分https与部分http - 互联网当前位置:& &&&Nginx部署一部分https与部分httpNginx部署一部分https与部分http&&网友分享于：&&浏览：0次Nginx部署部分https与部分http
http://blog.csdn.net/na_tion/article/details/
一般而言，大规模的网站都有很多台Web服务器和应用服务器组成，用户的请求可能是经由Varnish，HAProxy，Nginx之后才到应用服务器，中间有好几层。而中小规模的典型部署常见的是 Nginx+Tomcat/jboss 这种两层配置，而Tomcat或jboss 会多于一台，Nginx 作为静态文件处理和负载均衡。下面重点讲解nginx+jboss+ssl实现部分页面https部分页面http
如果Nginx作为前端代理的话，则Tomcat/jboss不处理自己 https，全交由Nginx处理是可以的。（一般情况下nginx和Tomcat/jboss处于同一个局域网内，安全问题暂时忽略。nginx与jboss之间加密传输在本文最后说明）用户首先和Nginx建立连接，完成SSL握手，而后Nginx 作为代理以 http 协议将请求转给 tomcat 处理，Nginx再把 Tomcat/jboss 的输出通过SSL 加密发回给用户，这中间是透明的，Tomcat/jboss只是在处理 http 请求而已。因此，这种情况下不需要配置 Tomcat 的SSL，只需要配置 Nginx 的SSL 和 Proxy。
SSL比 http 要消耗更多cpu资源（主要是在建立连接的阶段，之后还要对内容加密），所以对一般网站，只需要对部分地方采用https，大部分开放内容是没必要的，具体取决于你的业务要求。比如对于很多安全要求较低的网站，完全不用https也是可接受的。
某些页面是同时支持 http 和 https ，还是只支持 https、强制 https？
同时支持就是用户用什么协议访问都可以，那么用户的请求主要就是由页面本身的链接引导来的，因为一般用户不会自己特意去修改地址栏的。
一般我们的网站可以做成同时支持http和https，都可以访问。但是这就容易有后面说的混合内容或混合脚本的问题。
还可以规划为部分页面支持 https，一般公开页面不用https，只是将部分地方的链接改为 https 就可以了。专门期望以 https 访问的页面中，引用的绝对URL可以明确的使用 https链接。
是否强制 https ？对于安全性高的网站或网站中的部分页面，可以强制使用https访问， 即使用户在地址栏里手工把 https 改为 http， 也会被自动重定向回 https 上。比如可以通过配置web服务器 rewrite 规则将这些 http url 自动重定向到对应的 https url 上（这样维护比较简单），而不用改应用
解决混合内容问题(http和https)
混合内容是指：在https的页面中混合了非https的资源请求，比如图片、css、js 等等。如果是混合了非 https 的 js 代码，则被称为混合脚本。
特别注意：
(1)在http页面混有https内容时，页面排版不会发生乱排现象
(2)在https页面，只有包含以http方式引入的资源（如图片，js等）时，才算作混合内容，如果https页面有超链接(如http:),但是该超链接并没有引入资源，不算做混合内容，页面显示正常，鼠标放在该超链接时，页脚显示：或者
混合内容的危害：如果只是混合了不安全的图片和css，那么受中间人攻击篡改，一般只会影响页面的显示，危害相对小一点。如果是混合了不安全的 js 代码，则这个不安全的 js 可以完全访问和修改页面中的任何内容，这是非常危险的。
所以，只有页面本身和所有引用的资源都是 https 的浏览器才认为是安全的，只要其中引用了非安全资源（即使图片），浏览器都会给出不安全的提示，特别是有 js 的情况。如果浏览器提示不安全，那样我们就达不到原来目的了。我们费了半天功夫去申请 SSL 证书，配置Web服务器，最后如果因为混合内容而前功尽弃就太糟了。
理论上，混合了第三方的内容，即使是SSL的第三方内容也不是很好。因为用户信任的是你，而不是第三方，即使第三方也支持https，但你能保证第三方就绝对安全吗。不引用任何第三方才是绝对安全的，但这样太严格了，安全其实也是一个 tradeoff 的问题，需要考虑很多方面的平衡。
Chrome出绝招阻断混合脚本漏洞:/1/197/197058.htm
谷歌浏览器混合显示内容会这样指示:
谷歌浏览器混合脚本得以执行时，整个原始页面都会受到影响，原因是浏览器阻止混合内容的加载。如果me的显示网站上存在混合内容问题，可以尝试的开发工具定位问题。有用的信息通常记录在控制台菜单工具控制台,只要把提示的非传送内容改为传送的就可以了，这个在后面的代码中展示。
在其他主流浏览器（如或）需要点击确认对话框来确定是否显示混合内容。
Nginx+jboss+http/https详细配置
1、nginx.conf 中的配置示例
upstream cluster{
server 172.18.0.33:80 weight=1;
server 172.18.0.101:8088 weight=5;
upstream clusterssl{
server 172.18.0.33:8443 weight=1;
server 172.18.0.101:8443 weight=5;
location / {
proxy_pass http://
proxy_set_header Host $
proxy_set_header X-Real-Ip $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
proxy_set_header X-Forwarded-Proto $
proxy_connect_timeout 10;
proxy_read_timeout 120;
location ~* /*login.htm {
#rewrite ^(.*) https://$host$1
rewrite ^(.*) $1
location ~ \.(css|js|gif)$ {
#rewrite ^(.*) https://$host$1
rewrite ^(.*) $1
# HTTPS server
listen 443;
ssl_certificate
ssl_certificate_key
ssl_session_cache
shared:SSL:10m;
ssl_session_timeout
ssl_protocols
SSLv3 TLSv1;
ssl_ciphers
HIGH:!ADH:!EXPORT56:RC4+RSA:+MEDIUM;
ssl_prefer_server_
location / {
rewrite ^(.*) http://www.AAA.com$1
location ~* /*login.htm {
proxy_pass http://
proxy_redirect off;
proxy_set_header Host $
proxy_set_header X-Real-Ip $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
proxy_set_header X-Forwarded-Proto $
location ~ \.(css|js|gif)$ {
proxy_pass http://
proxy_set_header Host $
proxy_set_header X-Real-Ip $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
proxy_set_header X-Forwarded-Proto $
首先，用户访问,进入网站首页，当点击登陆页面/login.htm页面时，由于在80端口进行如下配置：
location ~* /*login.htm {
#rewrite ^(.*) https://$host$1
#当AAA与BBB相同时，可用$host常量
rewrite ^(.*) $1
Url重写之后，到443端口，然后通过443端口的代理配置：
proxy_pass http://
Nginx将https请求转发给后台的jboss应用服务器。由于https状态会保持，在登陆之后跳转到其它页面时，如果不进行强制使用http,会一直保持https状态，443端口的如下配置：
location / {
rewrite ^(.*) http://www.AAA.com$1
会使得https状态下的非login.htm链接使用http协议。
在登录页面引入的css、js、gif等资源，由于是后端的jboss以http状态返回给nginx的，所以login.htm页面会有混合内容，浏览器认为是不安全的，不进行加载，会出现页面排版乱排等现象，谷歌浏览器提示如下：
打开谷歌浏览器:菜单工具控制台，信息如下
IE9显示如下：
在80端口下进行如下配置：
location ~ \.(css|js|gif)$ {
#rewrite ^(.*) https://$host$1
rewrite ^(.*) $1
在443端口进行如下配置：
location ~ \.(css|js|gif)$ {
proxy_pass http://
可以解决页面有混合内容的问题。
现在，另一个问题出现了，如果按照上面进行配置，那么其它非login页面的css、js、gif也都会走https,影响效率，又使得http页面存在https方式引入的内容，解决办法是把登录页面需要的资源放在一个可以区分的路径下面，location匹配的时候，让该路径下的css、js、gif等资源走https，其他路径下面的资源走http。
在代理模式下，jboss 如何识别用户的直接请求（URL、IP、https还是http )？
在透明代理下，如果不做任何配置jboss认为所有的请求都是 Nginx 发出来的，这样会导致如下的错误结果：
request.getScheme()
//总是 http，而不是实际的http或https
request.isSecure()
//总是false（因为总是http）
request.getRemoteAddr()
//总是 nginx 请求的 IP，而不是用户的IP
request.getRequestURL()
//总是 nginx 请求的URL 而不是用户实际请求的 URL
response.sendRedirect( 相对url )
//总是重定向到 http 上 （因为认为当前是 http 请求）
如果程序中把这些当实际用户请求做处理就有问题了。解决方法很简单，只需要配置一下 Nginx 就好了，而不用改程序。
配置 Nginx 的转发选项：
proxy_set_header
proxy_set_header
proxy_set_header
X-Forwarded-For $proxy_add_x_forwarded_
proxy_set_header X-Forwarded-Proto
1、优化rewrite语句：
rewrite复杂而且低效,用return语句代替，如
http://www.example.org$1;
retrun 301 http://www.example.org$request_
2、优化SSL配置
SSL操作需要消耗CPU资源，所以在多处理器的系统，需要启动多个工作进程，而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手，有两种方法可以将每个客户端的握手操作数量降到最低：第一种是保持客户端长连接，在一个SSL连接发送多个请求;第二种是在并发的连接或者后续的连接中重用SSL会话参数，这样可以避免SSL握手的操作。会话缓存用于保存SSL会话，这些缓存在工作进程间共享，可以使用ssl_session_cache指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟，可以使用ssl_session_timeout加大它。下面是一个针对4核系统的配置优化的例子，使用10M的共享会话缓存：
worker_processes
ssl_session_cache
shared:SSL:10m;
ssl_session_timeout
keepalive_timeout
ssl_certificate
ssl_certificate_key .
ssl_protocols
SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers
HIGH:!aNULL:!MD5;
证书密钥的保护：
服务器证书是公开的，会被传送到每一个连接到服务器的客户端,而私钥不是公开的，不会被发送，在服务器上要保护好它，比如存放在访问受限的文件中，例如：chmod 400 ssl.key （仅root可读），当然，nginx主进程必须有读取密钥的权限；或者为私钥文件设置密码时，这样私钥虽然很安全，但是每次重启nginx服务都要输入一次密码，比较麻烦
Nginx前端机与后端jboss间部分http部分https通道实现
如果想要在nginx与jboss之间也实现加密传输，仅需要做如下关键点的修改：
(1)在jboss端配置服务器证书，并开启https端口（下面以8443端口为例）
(2)配置jboss端的部分https部分http
(2)在nginx监听443端口的服务修改如下：
location ~* /*login.htm {
proxy_pass https://clusterssl;
proxy_set_header Host $
proxy_set_header X-Real-Ip $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
proxy_set_header X-Forwarded-Proto $
(3)修改其它混合内容
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
一个到处闯荡的江湖人士！附加:俺们还是个很典型的双鱼座撒!-v-
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
# wget http://nginx.org/download/nginx-1.4.2.tar.gz# wget /alibaba/nginx-http-concat/archive/master.zip -O nginx-http-concat-master.zip# unzip nginx-http-concat-master.zip# tar -xzvf nginx-1.4.2.tar.gz# cd nginx-1.4.2# ./configure --prefix=/usr/local/nginx-1.4.2 --with-http_stub_status_module \--add-module=../nginx-http-concat-master# make# make install2. 指令directivesconcat on | offdefault: concat offcontext: http, server, location开启火关闭concatconcat_types MIME typesdefault: concat_types: text/css application/x-javascriptcontext: http, server, locationDefines the MIME types which can be concatenated in a given context.在给定的配置段中可以被合并的MIME文件类型.concat_unique on | offdefault: concat_unique oncontext: http, server, location是否只允许同类型文件（相同MIME文件）合并。例如，设置为off，那么js和css文件可以合并。默认情况下，这个值是on，意味着只有相同的类型文件才能合并。如果希望js和css能够合并为一个请求，那么你必须设置concat_unique off，其他类型文件也可以用同样的方式合并.如下为OFF才可以的请求：/static/??foo.css,bar/foobaz.jsconcat_max_files numberpdefault: concat_max_files 10context: http, server, location定义一个给定的配置段里面允许合并文件的数量，默认最多10个.不过一定要注意，uri不要超过系统的规定的page size，在里面执行getconf PAGESIZE可以获取系统的限制.通常限制是4096字节。concat_delimiter: stringdefault: NONEcontext: http, server, locatione定义文件分隔符concat_ignore_file_error: on | offdefault: offcontext: http, server, location是否忽略文件请求错误，例如404和403等3. 配置nginxserver {&&&&&listen&&&&&& 80;&&&&server_name& ;&&&&&root /data/site/;&&&&location /static/ {&&&&&& &&&&&&& &concat_max_files 20;&&&&&& &concat_&&&&}}4. 测试nginx concat我的站点有调用到static/ttlsa_concat.css和static/ttlsa_concat.js两个文件，为了提高站点访问速度，我决定使用nginx的concat模块将两个请求合并为一个。合并前/static/css/ttsa_concat.css/static/js/ttsa_concat.js合并后/static??js/ttlsa_concat.js,css/ttlsa_concat.css?ver=123测试之前，准备一下文件.# cd /data/site//static# cat js/ttlsa_concat.js &// this is js&file&ttlsa_concat.js# cat js/a.js&&&&&&&&&&& &// this is js&file&a.js# cat css/a.css/** this is css a.css **/# cat css/ttlsa_concat.css/** this is css ttlsa_concat.css **/4.1 两个css合并# curl /static/??css/ttlsa_concat.css,css/a.css/** this is css ttlsa_concat.css **//** this is css a.css *4.2 两个js合并# curl /static/??js/ttlsa_concat.js,js/a.js &// this is js&file&ttlsa_concat.js// this is js&file&a.js4.3 js与css合并# curl /static/??js/ttlsa_concat.js,css/ttlsa_concat.css// this is js&file&ttlsa_concat.js/** this is css ttlsa_concat.css **/4.4 带版本号参数# curl /static/??css/ttlsa_concat.css,css/a.css?123/** this is css ttlsa_concat.css **//** this is css a.css *以上仅仅用了两个文件来测试，在具体应用中，大家可以使用多个，具体几个由你的nginx配置来控制. 在具体的环境中，都是以下方式来调用，以下方法摘自官方文档.js：&script src="??bar1.js,bar22.css,subdir/bar3.js?v=3245"&/&以上意思是将ba1.Js，bar22.css和subdir/bar3.js这三个请求合并为一个，并且版本号为3245.css:&link rel="stylesheet"&href="??foo1.css,foo2.css,subdir/foo3.css?v=2345"&/&这边也是一个道理,只不过只包含css.5. 结束语减少web请求在一定程度上能减少web服务器的压力，简单的使用nginx concat模块便可以实现这个功能，不过需要前端设计师来使用。如果想减少web请求，又不想让前端设计师来插手的话，大家可以参考下google出的pagespeed模块6. 参考文章官方：http://wiki.nginx.org/HttpConcatModule来源站点：运维生存时间&& 网址：
阅读(678)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'nginx js、css多个请求合并为一个请求(concat模块)',
blogAbstract:'模块介绍
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}你可能喜欢
12345678910
12345678910
关于本站 本站以分享运维技术为主，欢迎大家参与技术分享，同时也欢迎大家吐槽，本站提供以下交流圈：QQ群①：*****（满）QQ群②：6690706 QQ群③： QQ群④：（新） 微信公众号：ttlsacom 商务合作QQ：
