WordPress切换PHP后，为什么大量WebP缩略图突然404？

6次阅读

没有评论

一次帮人处理站点维护中，PHP运行环境切换完成，首页和文章页却出现了成片的缩略图空白。浏览器请求这些图片时返回404。

原始JPG、PNG还能打开，部分旧WebP也正常。异常集中在主题后来生成的特定尺寸WebP缩略图。这个对照很关键：Nginx仍能提供静态文件，故障更靠近“缩略图生成、文件落盘与路径缓存”这一段。

本文来自真实排障过程。站点域名、主题名称、服务器目录和业务信息已经匿名化。

第一步：把404分成几组

先挑同一张图片的三个地址做对照：原图、一个已存在的旧WebP、页面里报404的新缩略图。

在有权限的服务器或管理终端上，可以先看HTTP状态：

bash

curl -I 'https://example.com/uploads/source.jpg'
curl -I 'https://example.com/uploads/existing.webp'
curl -I 'https://example.com/uploads/missing-size.webp'

本次案例得到的组合是：原图200，已有WebP 200，新尺寸WebP 404。

这组结果说明静态文件服务和WebP MIME类型并没有整体失效。下一步要确认404地址对应的文件是否存在，而不是立刻重写Nginx规则。

如果原图也404，应先查上传路径、CDN回源和Nginx映射；如果文件存在但HTTP仍404，再查root、alias、权限和缓存层。

第二步：确认页面引用和磁盘文件是否一致

从页面复制一条失败URL，再把URL路径映射到上传目录。不要靠文件名猜目录。

bash

stat '/data/www/example/wp-content/uploads/2026/08/missing-size.webp'
namei -l '/data/www/example/wp-content/uploads/2026/08/missing-size.webp'

stat显示文件不存在时，404就是正常响应。此时改MIME类型不会生成文件。

namei -l用于检查父目录的属主和权限。生成进程需要对目标目录有写权限，Nginx读取进程需要有读取和穿越权限。不要为了省事把上传目录改成777；先确认PHP-FPM实际运行用户，再修正到最小权限。

第三步：核对真正处理请求的PHP环境

切换PHP后，命令行和PHP-FPM可能指向不同版本。CLI里看到GD支持WebP，不等于网站请求使用的FPM也具备同样能力。

可以先记录版本和模块：

bash

php -v
php --ri gd
php -r 'var_export(function_exists("imagewebp"));'

随后在服务器配置中确认站点连接的FPM套接字或端口，并检查对应版本的模块。WordPress站点健康信息也能提供当前Web请求环境的线索。

不要把包含完整环境变量和路径的phpinfo()长期暴露在公网。若临时创建检查页，限制访问来源，用完立即删除。

第四步：检查“返回了路径”是否等于“写出了文件”

本次案例里，GD已经支持WebP，目录权限也没有整体错误。继续跟踪主题的图片处理流程后，发现问题在更里面：缩略图函数计算出了目标路径，但某些分支没有确认WebP文件已经写入磁盘；缓存随后记住了这个目标路径，页面便一直引用一个不存在的文件。

可靠的处理顺序应包含四步：

解码源图并生成目标尺寸。
调用WebP编码器写入临时文件。
检查写入返回值、文件大小和最终文件是否存在。
原子替换到目标路径，成功后再写缓存。

伪代码可以写成：

text

target = build_target_path(source, size)
ok = encode_webp(source, temporary_file)

if ok and file_exists(temporary_file) and file_size(temporary_file) > 0:
atomic_move(temporary_file, target)
cache(target)
else:
remove(temporary_file)
report_failure()

这段逻辑的重点是“先验证文件，再缓存路径”。生产站点修改主题或插件前，应在测试环境复现，并保留原文件和回退版本。