Nginx部署中关于Flask的错误优化

蜜汁404

好吧，虽然已经快去实习了，然而也貌似累积了不少网站在手上，果然还是平时玩的太多了，我需要认真的反思了

就在刚刚做资助管理网的旧网站数据兼容的时候发现了一个相当奇怪的地方，好吧，其实也不算奇怪，不就是在自己笔记本上怎么测试都运行的各种完美，到了服务器上就死活找不到原因。

以上图片一直加载显示404，蜜汁404，让喵抓狂了好久，无论怎么修改代码都无法在服务器上正常运行。让我一直以为是flask的redirect有问题或者是浏览器对于这样直接显示的图片资源进行重定向就会出现这样的问题。

当然这样只有在服务器上才会出现的问题，当然Nginx的日志显得尤为重要了。

No such file or directory!!!

好吧，的确，图片并不在这个目录，然而，我确实在代码中重定向了啊！！！不然我本地不早就报错了么，，，不可能，一定是服务器上有鬼作祟，，恩，一定是酱紫的。。。。

柳暗花明

就在快放弃治疗的时候，想起来服务器上Nginx的标准配置，当年韬肾配置好了第一个news的模板，后来所有人都copy这份代码，好吧，虽然后来自己有简化过Nginx配置文件中的变量设置，不过大体并没有改变。

其中有一段优化静态文件的配置如下：

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|ttf|woff)$ {
                expires      30d;
        }
location ~ .*\.(js|css)?$ {
                expires      12h;
        }

原本的意思是缓存下所有的图片，动画，字体资源等(缓存30天)，缓存js和css文件12小时。不得不说，这样的配置，对于原本的需求来说是很合理的，程序员并不会编辑图片资源或者其他媒体资源(除非程序员兼职设计。。。)，所以缓存下来会加快第二次访问的速度，然而location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|ttf|woff)$这句话包含的范围太广了诶，由于在这里的Nginx作为最高级的代理，会先把符合规则的url拦截下来，在这里看上去只是在header里面添加了expires的选项然后再返回给uwsgi，uwsgi再到flask应用。

个人猜测，Nginx在获取到符合这条规则的时候会拦截这条URL，并直接作为静态文件返回，不会向下发送给uwsgi甚至flask

作为重定向访问，正确的结果如下：

突然想起来，还好我在做静态文件服务器的时候用的是没有任何后缀的hash值来索引一个文件，如果在不知道还有这样的情况存在的话，可能这篇文章早就出来了233333

其实对于默认静态文件目录配置的flask来说，应该在这个url规则中限制static下的文件才进行缓存就好了的，like this location ~* /static/.*\.(gif|jpg|jpeg|png|bmp|swf|ttf|woff)$ { expires 30d; }，应该就差不多了～～

最后纪念

最后，纪念一下即将迁移的服务器，传输了我的服务器一年都传输不了的数据量

好吧，毕竟也运行了好久了的服务器捏～～～

18:19:55 up 303 days, 18:12, 1 user, load average: 0.21, 0.05, 0.01