frankenphp容器间通信无需-p端口映射，只要同属一个docker网络（如自定义bridge），即可通过容器名+默认fpm端口9001直连；需确保目标容器监听0.0.0.0:9001而非127.0.0.1，且调用方使用fastcgi://容器名:9001。
FrankenPHP容器间通信不需要发布端口
同一 Docker 网络（如自定义 bridge 或 default bridge）内的 FrankenPHP 容器，只要彼此能通过容器名或服务名解析，就可直接通信，无需 -p 发布端口到宿主机。发布端口只影响「宿主机 → 容器」或「外部 → 容器」的访问路径，对容器间直连无作用。
容器内如何访问另一个FrankenPHP容器的FPM端口
FrankenPHP 默认以 PHP-FPM 模式暴露后端服务，监听 9001（不是传统 9000）。其他容器要调用它，需满足：
- 两个容器在同一个
--network下（例如docker network create mynet，启动时都加--network mynet） - 发起请求的容器用目标容器名（如
frankenphp-app）作为 host，拼上:9001，例如fastcgi://frankenphp-app:9001 - 目标容器未显式绑定
127.0.0.1:9001—— 默认监听:9001即所有接口，符合跨容器通信要求 - 若目标容器用了
--fpm-port 9002，则调用方必须同步改用:9002，且containerPort（K8s 场景下）也得对齐
为什么加了-p反而可能干扰容器间通信
-p 本身不破坏容器网络，但容易引发两个典型误操作：
- 误以为“没加 -p 就连不上”，于是给本该只内网通信的服务也暴露宿主机端口，增加攻击面
- 混用
--network host和-p：Docker 会忽略-p并警告，但开发者可能因日志混乱而怀疑网络不通 - 在 compose 中为服务配了
ports:却没关掉expose:，造成配置冗余，还可能误导他人以为该端口必须开放
常见错误：curl localhost:9001 在容器里失败
这是最典型的混淆点——localhost 在容器内指代的是「自己」，不是宿主机，更不是同网络下另一容器。所以：
- 在 A 容器里执行
curl http://localhost:8080，访问的是 A 自己的 HTTP 服务（如果它开了） - 想访问 B 容器的 HTTP 服务，应写
curl http://b-container:8080（前提是 B 监听了:8080且网络互通） - 想访问 B 的 FPM 接口，应写
fastcgi://b-container:9001（PHP 应用中）或用nc -zv b-container 9001测试连通性 - 若 B 是用
--network host启动的，它没有独立网络命名空间，A 容器无法用容器名解析它——此时必须让 A 也走host网络，或改用宿主机 IP（如host.docker.internal）
关键不在“要不要发布端口”，而在“通信双方是否在同一个网络平面、是否用对了目标地址”。容器名解析、端口监听地址（0.0.0.0 vs 127.0.0.1）、以及防火墙（如 iptables 对 docker0 的限制）才是实际卡点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
