<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I notice error_page is used at server level while fastcgi_cache_use_stale is at http level. error_page has thus higher precedence than the last. I would give a shot at putting both at the same level and see what happens.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">I trust error_page is some kind of 'last resort' feature, handling an error which is considered as such. Since fastcgi_cache_use_stale might triggers on errors coming from the backend, I would say it should filter them before they are considered by nginx as an error (and thus being processed as such, as the *_intercept_errors directive do).<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">So the only reason I see error_page being triggered before fastcgi_cache_use_stale would be the higher precedence of the server environment over the http one. Test, test, test. :o)<br></div><div class="gmail_extra"><div><div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Thu, Dec 4, 2014 at 6:09 PM, Fry-kun <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am; that was a copy/paste error. The original config is around 3000 lines,<br>
it was easier to type & copy/paste than cleaning up unnecessary lines.<br>
<br>
<br>
~Konstantin<br>
<br>
<br>
B.R. Wrote:<br>
-------------------------------------------------------<br>
<span>> Quick quesiton; I see you are using proxy_intercept_errors. Should not<br>
> you<br>
> be using fastcgi_intercept_errors<br>
</span>> <<a href="http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_in" target="_blank">http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_in</a><br>
> tercept_errors><br>
> ?<br>
> ---<br>
> *B. R.*<br>
<div><div>><br>
> On Thu, Dec 4, 2014 at 2:25 AM, Fry-kun <<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>> wrote:<br>
><br>
> > I'm trying to configure my sites to failover to fastcgi_cache when<br>
> backends<br>
> > are unavailable -- but at the same time I want to return nginx<br>
> errors<br>
> > (hiding backend errors)<br>
> ><br>
> > Here's a simplified version of my current config:<br>
> ><br>
> > fastcgi_cache_path /dev/shm/nginx_fastcgi_cache levels=1:2<br>
> inactive=3d<br>
> > keys_zone=mycache:100m max_size=5000m;<br>
> > fastcgi_cache_use_stale error http_500 http_503 timeout updating;<br>
> > fastcgi_cache_valid 200 5m;<br>
> > fastcgi_cache_valid 404 1m;<br>
> > proxy_intercept_errors on;<br>
> > server {<br>
> > server_name <a href="http://domain.com" target="_blank">domain.com</a><br>
> > root /var/www/<a href="http://domain.com" target="_blank">domain.com</a>;<br>
> > location / {<br>
> > try_files $uri @hhvm_backends;<br>
> > }<br>
> > location @hhvm_backends {<br>
> > fastcgi_pass backend-nodes; # upstream hhvm backends<br>
> > fastcgi_cache mycache;<br>
> > ...<br>
> > }<br>
> > error_page 404 @404;<br>
> > error_page 500 @500;<br>
> > location @404 { echo "404: file not found!"; }<br>
> > location @500 { return 500; } # default nginx error page<br>
> > }<br>
> ><br>
> ><br>
> > Right now, if the server is down and location is stale in cache, I<br>
> get the<br>
> > default nginx 500 error page.<br>
> > According to debug log, the problem with this one is that error_page<br>
> > handling takes over before fastcgi_cache_use_stale has a chance to<br>
> do its<br>
> > thing.<br>
> ><br>
> > Is there an easy way to fix this?<br>
> ><br>
> > Thanks<br>
> ><br>
> > Posted at Nginx Forum:<br>
> > <a href="http://forum.nginx.org/read.php?2,255298,255298#msg-255298" target="_blank">http://forum.nginx.org/read.php?2,255298,255298#msg-255298</a><br>
> ><br>
> > _______________________________________________<br>
> > nginx mailing list<br>
> > <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
> > <a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
> ><br>
> _______________________________________________<br>
> nginx mailing list<br>
> <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
<br>
</div></div>Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?2,255298,255307#msg-255307" target="_blank">http://forum.nginx.org/read.php?2,255298,255307#msg-255307</a><br>
<div><div><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>