Nginx 1.24升级后PHP文件被下载而非解析的问题求助

针对Azure App Services中Nginx升级到1.24后PHP文件直接下载的问题，以下是该版本中可能影响PHP解析的核心变更及对应的排查方向：

一、核心模块与请求路由相关变更 #

• try_files与正则location的交互逻辑修复：
  Nginx 1.24修复了try_files指令在处理最后一个参数为正则location时的匹配异常问题，但反过来，若配置中location /内的try_files规则与PHP正则location存在冲突，可能导致请求未正确进入PHP处理块。比如请求/index.php时，若try_files优先匹配静态文件逻辑而非正则location，就会直接返回文件内容。

• if指令的行为优化：
  1.24版本对if块内的rewrite规则执行逻辑做了细微调整，你配置中的if (!-e $request_filename)规则，在新版本中可能导致rewrite后的请求未重新触发正则location匹配，使得动态请求仍被当作静态文件处理。

二、FastCGI模块的关键变更 #

• fastcgi_param默认参数调整：
  Azure App Services的Nginx 1.24镜像中，默认的fastcgi_params文件可能删减或调整了部分参数（如SCRIPT_NAME、REQUEST_URI），若配置仅手动设置了SCRIPT_FILENAME，缺失的参数可能导致FastCGI服务无法正确识别PHP请求，进而Nginx fallback到静态文件返回。

• fastcgi_intercept_errors的逻辑变更：
  1.24版本中开启fastcgi_intercept_errors后，错误页面的拦截逻辑更严格，若FastCGI服务返回非200状态码，Nginx可能直接返回静态错误页而非重试请求，间接导致PHP请求被中断后返回原始文件。

三、针对现有配置的快速修复建议 #

结合上述变更，可尝试以下调整：

1. 调整location匹配优先级：
   给PHP处理的location加上^~前缀，强制优先匹配：

   location ^~ \.php$ {
       try_files $uri =404;
       include fastcgi_params;
       fastcgi_pass 127.0.0.1:9000;
       fastcgi_index index.php;
       fastcgi_intercept_errors on;
       fastcgi_read_timeout 300; 
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       # 补充缺失的FastCGI参数
       fastcgi_param QUERY_STRING $query_string;
       fastcgi_param REQUEST_URI $request_uri;
       fastcgi_param SCRIPT_NAME $fastcgi_script_name;
   }
   

2. 移除冗余的if块：
   配置中的if (!-e $request_filename)规则与location /内的try_files功能重复，1.24版本中两者共存可能导致路由冲突，建议删除该if块，仅保留try_files逻辑。

3. 检查FastCGI服务状态：
   确认PHP-FPM服务是否在127.0.0.1:9000正常监听，1.24版本对FastCGI连接的超时检测更严格，若服务未正常启动，Nginx会直接返回静态文件。

内容的提问来源于stack exchange，提问作者Joey