Docker Compose重命名PHP服务后返回503 Service Unavailable的问题

这个问题和Docker Compose的服务重命名机制没有直接冲突，核心原因是Apache容器内的PHP代理配置存在硬编码的主机名不匹配：

• Docker Compose默认会为同一自定义网络下的所有服务生成内置DNS解析记录，服务间互相访问时，直接使用compose里定义的服务名作为目标主机名，就能解析到对应容器的内网IP。
• 你最初搭建这套环境时，Apache镜像内置的虚拟主机配置、PHP-FPM代理规则，大概率是硬编码了php:9000作为FastCGI的后端处理地址——这段配置是当初服务名为php时写入的，和compose里的depends_on配置没有自动联动能力。
• 当你把PHP服务重命名为php_pname后，compose网络里的DNS记录会同步更新，把php_pname映射到PHP容器的IP，但旧的php主机名已经不存在了。Apache还是按照原有配置去找php这个目标，根本找不到对应的FastCGI服务，PHP请求没法被正常处理，自然就会返回503站点不可用。

常见认知误区：depends_on配置仅用于控制容器的启动先后顺序，既不会自动修改容器内部的应用配置，也不会自动调整网络连接的目标地址，这也是很多人调整compose服务名时最容易踩的坑。

• 定位Apache的站点配置：进入项目下的./apache/目录，找到打进镜像的虚拟主机配置文件，搜索和FastCGI相关的配置行，通常会看到类似SetHandler "proxy:fcgi://php:9000"、ProxyPassMatch ".*\.php$" "fcgi://php:9000/var/www/html/"的硬编码规则。
• 替换硬编码的主机名：把配置里写死的php替换成你自定义的PHP服务名php_pname，确保配置里的主机名和compose里定义的PHP服务名完全一致。
• 让配置生效：由于站点配置是打包在Apache镜像内部的，修改完成后执行docker-compose build apache_pname重新构建镜像，再重启整个服务栈即可正常访问。
• 可选优化方案：如果不想每次调整服务名都要修改镜像内的文件，可以给Apache服务配置环境变量传入PHP的上游地址，配合Apache自带的mod_env模块读取环境变量替换配置占位符，后续调整服务名时只要修改compose的环境变量值即可，不需要改动镜像文件。

完全没有这个强制要求。Docker Compose本身不会对PHP服务的命名做限制，你可以根据项目规范把服务名自定义为php_pname或者其他任意名称，只要满足两个基础条件就能正常运行：

• PHP服务和Apache服务接入同一个自定义网络
• Apache配置中指向PHP-FPM的主机名，和compose里定义的PHP服务名完全匹配

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