最近我碰到一个挺头疼的问题，正好分享给大家——我维护的一个Web应用，访问某些路径时会间歇性弹出**“File not found.”**错误，没什么规律可言，但经常是连着错个10次，又连着正常20次，刷新页面大多时候能恢复。而且这个问题只在访问/run目录下的文件或路径时才会出现，一开始我完全摸不着头脑，不知道是Nginx配置错了，还是这些路由加载的数据太多导致的问题。

还有个奇怪的点：出现错误的时候，Nginx的access日志根本没记录这条请求，但正常加载时日志就会正常打出来。我当时就纳闷了——明明浏览器收到了服务器返回的错误，怎么请求连日志都没进？

排查过程 #

1. 先查Nginx配置
   我第一时间翻了Nginx的配置文件，重点看针对/run路径的location块：

• 确认是不是用错了alias和root（这俩很容易搞混，alias会替换路径前缀，root是拼接路径）
• 检查/run目录的权限，确保Nginx和PHP-FPM的运行用户（比如www-data）有读写权限

2. 转向PHP-FPM日志排查
   因为是PHP应用，请求最终会交给PHP-FPM处理，我去看了FPM的error日志，果然发现了几条和/run目录相关的报错，时间点正好和用户反馈的错误时段对上！原来应用会在/run下生成临时文件，但这些文件有时候会被系统的临时文件清理机制（比如systemd-tmpfiles）自动删掉，而应用没有处理文件不存在的异常，导致FPM返回文件找不到的错误，Nginx直接把这个错误返回给浏览器，而且因为请求没走到正常的日志流程，所以access日志没记录。

解决方法 #

• 调整临时文件清理规则：在/etc/tmpfiles.d/下新建一个专属配置文件（比如my-app.conf），内容如下：

  d /run/my-app 0755 www-data www-data 1d -
  

  这样系统只会每天清理一次/run/my-app目录下的文件，避免临时文件被过早删掉。
• 修复应用代码：给访问/run下文件的逻辑增加存在性检测，如果文件不存在，先重新生成再继续处理，而不是直接抛出错误。
• 优化Nginx日志配置：在对应location块里加上log_not_found on;，确保即使出现文件不存在的错误，也能把请求记录到access日志里，方便后续排查。

现在调整完这几点，问题就再也没出现过了。总结一下，这种间歇性的“文件找不到”问题，大概率和临时文件生命周期、进程资源或者权限配置有关，排查的时候一定要多结合Nginx和PHP-FPM的错误日志，往往能找到关键线索！

备注：内容来源于stack exchange，提问作者Patrick Cullen