今天为了折腾那套 WordPress 环境，真是差点把键盘给敲烂了。

事情起因很简单：我用 wordpress:6.9-php8.2-fpm 镜像搭了个环境，外面套了一层宿主机的 Nginx 做转发。本以为这种教科书级别的配置，闭着眼睛都能跑通，结果浏览器一刷新，屏幕上冷冰冰地躺着四个大字：“File not found.”。

我反手就是一个 cat 检查了宿主机的权限和文件内容，www-data 用户读写正常，路径也对得上，Nginx 配置里的 fastcgi_pass 更是直连容器端口。这种“文件明明在，但它死活说没有”的感觉，就像是你在兜里摸到了钥匙，但锁却告诉你门没关、只是你手感不对。

这时候，我本着“能问 AI 绝不自己抠脑壳”的原则，先去问了下豆包。结果这哥们儿给我绕了一大圈：先是让我查 Linux 文件权限，接着让我改 Nginx 的 user，最后甚至开始教我怎么重新安装 php-ext-install。折腾了半天，权限改成了 777，镜像重构了好几次，问题依然稳如泰山。那一刻，我真想问问它：你是不是在跟我玩“运维消消乐”？

抱着试一试的心态，我转头把同样的 Nginx 配置和报错丢给了 Gemini。

结果 Gemini 连一句废话都没有，直接点出了那个被我忽略的“盲点”：路径隔离。

我宿主机的 Web 根目录在 /opt/wordpress/html，Nginx 的 $document_root 也是这个。但我忘了，PHP-FPM 是住在 Docker 容器这个“样板间”里的，在它的世界观里，压根就没有 /opt 这个路径。它只认官方镜像默认的 /var/www/html。

当 Nginx 傻乎乎地把 /opt/wordpress/html/index.php 这个路径传给容器里的 FPM 时，FPM 当然只能回敬一句“File not found”。

解决办法简单到想哭：只需要在 fastcgi_param SCRIPT_FILENAME 那里，把 $document_root 换成容器内部的绝对路径 /var/www/html 就可以了。

说实话，这次排障让我感触挺深的。现在的 AI 模型很多，但像 Gemini（哪怕只是 Flash 版本）这样能一眼看穿系统架构逻辑的真的不多。它不是在机械地检索关键词，而是真的理解了“宿主机-容器”这种双重空间下的路径映射逻辑。相比之下，那些只会复读权限指令的 AI，确实显得有些“人工智障”了。

有时候，强大的模型并不在于它能写多长的代码，而在于它能多快定位到那一个让你抓狂的小变量。

最后的小贴士： 如果你也在搞 Nginx 转发 Docker FPM，记住：Nginx 是个传声筒，它说的话（路径），听众（容器）得能听懂才行。