Nginx和Tomcat同时启用GZIP的后果

新部署的一台服务器在做了性能调优以后发现FCK在线编辑器IE、firefox都出现报错，只有chrome正常。百思不得其解，差点就把FCK换掉。经过千辛万苦终于找到了原因（本人找错误原因的运气一直都非常好）：

 

开始以为是脚本乱码，看了文件头的那段注释以后确认不是这个问题。

 

在firefox的firedebug上面看到的脚本一直报找不到对象的错误，难道是公司的网络龟速导致脚本加载顺序不协调所致？几次刷新以后问题还在，304状态码说明不是网络龟速的原因。

 

最后把FCK的javascript脚本下载到本地以后一看，只有20k左右，而完整的是249K，看来我找到原因了~~

 

还是百思不得其解，好好的静态脚本文件为什么会下载了一部分就完了呢？而且首次下载的状态码是200，之后的刷新都是304，这违反了我对HTTP状态码的理解。

 

撇开前端的Nginx，直接访问tomcat居然页面就正常了。so~问题在nginx。nginx处理静态资源的能力从来都没有怀疑过（这再次违反了我对XXX的理解）。

 

灵光一闪，前后端的服务器最近都进行了调优，难道是这次修改了配置文件导致的？so首先关闭nginx的gzip  off;，重启Nginx后全世界正常了。随后关闭后端tomcat的compression="off"，重新启用Nginx的gzip，问题终于解决了。

 

总结：多层服务器结构的系统启用gzip压缩要注意一个问题：前端服务器启用了gzip以后，后端的服务器就不要启用gzip压缩了，不然部分浏览器会下载到不完整的文件。

 

 

静态资源为什么不可以在nginx就直接返回，而要经过tomcat处理呢？
不知道你们的配置是否是全部转发请求。
我对这些不是特别熟悉，所以不是质疑，只是有此疑问。

能否让nginx把静态资源直接返回？

很重要的经验分享~~

不错，受用！

哈哈 前台后台一起压缩的故障啊~~ 不过比混淆器带来的痛苦好多了

部分系统不是我们的，所以控制不了。