TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Nginx: try_files Is Evil Too (2024)

80 点作者 dextercd3 个月前

6 条评论

kilburn3 个月前
I don&#x27;t think this is worth it unless you are setting up your own CDN or similar. In the article, they exchange 1 to 4 stat calls for:<p>- A more complicated nginx configuration. This is no light matter. You can see in the comments that even the author got bugs in their first try. For instance, introducing an HSTS header now means you have to remember to do it in all those locations.<p>- Running a few regexes per request. This is probably still significantly cheaper than the stat calls, but I can&#x27;t tell by how much (and the author hasn&#x27;t checked either).<p>- Returning the default 404 page instead of the CMS&#x27;s for any URL in the defined &quot;static prefixes&quot;. This is actually the biggest change, both in user-visible behavior and in performance (particularly if a crazy crawler starts checking non-existing URLs ni bulk or similar). The article doesn&#x27;t even mention this.<p>The performance gains for regular accesses are purely speculative because the author didn&#x27;t make any effort to try and quantify them. If somebody has quantified the gains I&#x27;d love to hear about it though.
评论 #43126640 未加载
KronisLV3 个月前
Didn&#x27;t Apache2 also see some performance penalty due to them also allowing you to have configuration in .htaccess files which must be read in a similar way: <a href="https:&#x2F;&#x2F;httpd.apache.org&#x2F;docs&#x2F;current&#x2F;howto&#x2F;htaccess.html#when" rel="nofollow">https:&#x2F;&#x2F;httpd.apache.org&#x2F;docs&#x2F;current&#x2F;howto&#x2F;htaccess.html#wh...</a> (you can disable that and configure the web server similarly to how you would with Nginx, just config file(s) in a specific directory)<p>The likes of try_files across a bunch of web servers are pretty convenient though, as long as the performance penalty doesn&#x27;t become a big deal.<p>Plus, I&#x27;ve found that it&#x27;s nice to have api.myapp.com and myapp.com as separate bits of config, so that the ambiguity doesn&#x27;t exist for anything that&#x27;s reverse proxied and having as much of the static assets (for example, for a SPA) separate from all of that. Ofc it becomes a bit more tricky for server side rendering or the likes of Ruby on Rails, Laravel, Django etc. that try to have everything in a single deployment.
评论 #43125422 未加载
wildpeaks3 个月前
Sticking to this rule has served me well over the years:<p>- resources that are dynamically-generated are served by API endpoints, therefore known locations with predictable parameters<p>- everything else must be static files<p>And definitely no dynamic script as the fallback rule, it&#x27;s too wasteful in an era of crawlers that ignore robots.txt and automated vulnerability scanners.<p>A backend must be resilient.
EGreg3 个月前
Speaking of NGINX directives that can make a big difference serving files, here is how you we use it to enforce access control:<p><a href="https:&#x2F;&#x2F;community.qbix.com&#x2F;t&#x2F;restricting-access-to-resources&#x2F;195" rel="nofollow">https:&#x2F;&#x2F;community.qbix.com&#x2F;t&#x2F;restricting-access-to-resources...</a>
评论 #43124365 未加载
nwmcsween3 个月前
Just use `open_file_cache`?
huang_chung3 个月前
Fortunately Caddy is not evil: <a href="https:&#x2F;&#x2F;caddyserver.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;caddyserver.com&#x2F;</a>
评论 #43124104 未加载
评论 #43126107 未加载