云计算之路-阿里云上:排查奇怪的404错误
2014-07-01 14:32
176 查看
最近接到多位园友的反馈,在浏览器输入cnblogs.com,有时会出现404的页面,而正常情况下应该跳转至www.cnblogs.com。
在服务器端的IIS中,我们是通过URL Rewrite Module进行这个跳转的,URL重写规则是这么写的:
重写规则本身没问题,即使这个规则不起作用,也应该能正常访问,只是不跳转,不至于出现404。百思不得其解。。。
分析来分析去,我们觉得只有一种可能会引起404。在我们的URL Rewrite Module配置文件中有这样一条重写规则:
当IIS收到的hostname不是我们的域名与IP,就会返回404。
而对于我们遇到的问题,虽然用户在浏览器输入的是cnblogs.com,但如果hostname在中途被人偷梁换柱了,也会引发404。
而能够进行偷梁换柱的只有一个嫌疑对象,那就是我们使用的负载均衡——阿里云SLB。
确定了嫌疑对象,接下来就是取证,然后向阿里云起诉SLB,将之绳之以法。
我们想到了一个很简单的取证方法,稍微修改一下上面的URL重写规则,给在返回404时,再附加返回一个subStatusCode(用于在IIS日志中与其它的404区分开来):
并在IIS日志中增加对cs-host与sc-substatus的记录:
然后守在IIS旁边,等待犯罪嫌疑人再次作案。。。
守了一段时间之后,通过IIS Log Parser Studio查询IIS日志,查询命令如下:
发现了重要的线索:
我们猜测,访问cnblogs.com时出现404,很有可能是SLB在转发请求时丢掉了host头。
但我们只能说很有可能,我们的取证工作也只能做到这里,是否真的是这个原因,需要阿里云通过SLB的日志进行确认。
不管是不是SLB的问题,找到了这个线索,我们就有办法应对这个问题,添加一条如下的URL重写规则(放在block_invalid_host规则之前)—— 当host为空时,跳转至www.cnblogs.com:
在服务器端的IIS中,我们是通过URL Rewrite Module进行这个跳转的,URL重写规则是这么写的:
<rule name="root_redirect_www" stopProcessing="true"> <match url="(.*)" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> <add input="{HTTP_HOST}" pattern="^cnblogs\.com$" /> </conditions> <action type="Redirect" url="http://www.cnblogs.com/{R:1}" redirectType="Permanent" /> </rule>
重写规则本身没问题,即使这个规则不起作用,也应该能正常访问,只是不跳转,不至于出现404。百思不得其解。。。
分析来分析去,我们觉得只有一种可能会引起404。在我们的URL Rewrite Module配置文件中有这样一条重写规则:
<rule name="block_invalid_host" enabled="true" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> <add input="{HTTP_HOST}" pattern="^.+\.?cnblogs\.com$" negate="true" /> <add input="{HTTP_HOST}" pattern="^\d+\.\d+\.\d+\.\d+$" negate="true" /> </conditions> <action type="CustomResponse" statusCode="404" statusReason="Not found" statusDescription="Not found" /> </rule>
当IIS收到的hostname不是我们的域名与IP,就会返回404。
而对于我们遇到的问题,虽然用户在浏览器输入的是cnblogs.com,但如果hostname在中途被人偷梁换柱了,也会引发404。
而能够进行偷梁换柱的只有一个嫌疑对象,那就是我们使用的负载均衡——阿里云SLB。
确定了嫌疑对象,接下来就是取证,然后向阿里云起诉SLB,将之绳之以法。
我们想到了一个很简单的取证方法,稍微修改一下上面的URL重写规则,给在返回404时,再附加返回一个subStatusCode(用于在IIS日志中与其它的404区分开来):
<rule name="block_invalid_host" enabled="true" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> <add input="{HTTP_HOST}" pattern="^.+\.?cnblogs\.com$" negate="true" /> <add input="{HTTP_HOST}" pattern="^\d+\.\d+\.\d+\.\d+$" negate="true" /> </conditions> <action type="CustomResponse" statusCode="404" subStatusCode="8" statusReason="Not found" statusDescription="Not found" /> </rule>
并在IIS日志中增加对cs-host与sc-substatus的记录:
然后守在IIS旁边,等待犯罪嫌疑人再次作案。。。
守了一段时间之后,通过IIS Log Parser Studio查询IIS日志,查询命令如下:
SELECT to_string(to_localtime(time),'HH:mm:ss') as time, cs-uri-stem, sc-status, sc-substatus, cs-host FROM '[LOGFILEPATH]' WHERE sc-status=404 AND sc-substatus=8
发现了重要的线索:
我们猜测,访问cnblogs.com时出现404,很有可能是SLB在转发请求时丢掉了host头。
但我们只能说很有可能,我们的取证工作也只能做到这里,是否真的是这个原因,需要阿里云通过SLB的日志进行确认。
不管是不是SLB的问题,找到了这个线索,我们就有办法应对这个问题,添加一条如下的URL重写规则(放在block_invalid_host规则之前)—— 当host为空时,跳转至www.cnblogs.com:
<rule name="blank_host_redirect" stopProcessing="true"> <match url="(.*)" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> <add input="{HTTP_HOST}" pattern="^$" ignoreCase="false" /> </conditions> <action type="Redirect" url="http://www.cnblogs.com/{R:1}" redirectType="Found" /> </rule>
相关文章推荐
- 云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题
- 云计算之路-阿里云上:排查“黑色30秒”问题-为什么请求会排队
- 云计算之路-阿里云上:超级奇怪的“黑色10秒钟”
- 云计算之路-阿里云上:奇怪的CPU 100%问题
- 云计算之路-阿里云上:5月1日下午飘过的一朵乌云
- 云计算之路-阿里云上:终于找出了500错误的真正原因
- 阿里云的一些奇怪问题及服务器配置
- atitit.404错误的排查流程总结vOa6
- 云计算之路-阿里云上:消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload
- 云计算之路-阿里云上:2014年6月11日17点遇到的CPU 100%状况
- 云计算之路-阿里云上:弹性伸缩无服务器可弹,已有服务器无兵可援
- 阿里云的一些奇怪问题
- Atitit 404错误的排查流程总结 v3 qaf
- 云计算之路-阿里云上:在乌云中坚信蓝天
- 阿里云服务器排查带宽流量过大的程序
- 云计算之路-阿里云上:RDS用户的烦恼
- 云计算之路-阿里云上:原来“黑色0.1秒”发生在socket读取数据时
- 云计算之路-阿里云上:什么是“黑色1秒”?
- Atitit 404错误的排查流程总结 v3 qaf
- 云计算之路:遭遇奇怪的云服务器问题