docker port是唯一能准确查询容器运行时真实端口映射的命令，输出如80/tcp -> 0.0.0.0:8044表示宿主机8044端口正转发至容器80端口；若无输出则未用-p映射，外部不可访问。
docker port 命令查容器真实映射端口
容器启动后，docker port 是唯一能准确告诉你「宿主机哪个端口正转发到容器内哪个端口」的命令。它不依赖配置文件或文档描述，只读取运行时实际绑定关系。
执行方式很简单：
docker port <container-name-or-id>
例如：
docker port frankenphp-app
输出类似：
立即学习“PHP免费学习笔记（深入）”；
80/tcp -> 0.0.0.0:80<br>443/tcp -> 0.0.0.0:443<br>443/udp -> 0.0.0.0:443
这表示：容器内 80 和 443 端口已通过 -p 映射到宿主机对应端口；443/udp 表明 HTTP/3 支持已启用。
- 若无任何输出，说明该容器没用
-p或--publish暴露端口，外部无法直连（常见于仅内部通信场景） - 若只看到
9001/tcp -> 0.0.0.0:9001，但你没配 FPM 反代，大概率是误暴露了内部 FPM 接口，应删掉 -
0.0.0.0:80中的0.0.0.0表示监听所有网卡；若显示127.0.0.1:80，则仅本机可访问，外网请求会被拒绝
为什么 docker ps 的 PORTS 列有时不准
docker ps 输出的 PORTS 列只是摘要，容易漏掉 UDP 端口、host 网络模式下的端口，或被截断显示（尤其多端口时）。它也不区分是否真正生效——比如你写了 -p 8080:80，但 FrankenPHP 实际监听的是 :8080（因 SERVER_NAME=:8080），这时 docker ps 仍会显示 8080->80/tcp，但请求会失败。
关键判断依据永远是两件事是否对齐：
- 容器内 FrankenPHP 监听的地址（由
SERVER_NAME或 Caddyfile 决定） -
docker port显示的宿主机→容器端口映射关系
不对齐就会出现「能连上但返回 404」「curl 超时」「HTTP_HOST 不匹配」等问题。
容器内自查监听地址用 netstat 或 ss
进入容器内部，确认 FrankenPHP 进程到底在监听什么：
docker exec -it frankenphp-app sh -c "netstat -tlnp | grep :"
或更轻量的：
docker exec -it frankenphp-app ss -tln
你会看到类似：
LISTEN 0 4096 *:80 *:* users:(("frankenphp",pid=1,fd=6))<br>LISTEN 0 4096 *:443 *:* users:(("frankenphp",pid=1,fd=7))注意：*:80 表示监听所有 IPv4 地址的 80 端口；[::]:443 表示监听 IPv6 的 443；如果只看到 127.0.0.1:8000，说明 FrankenPHP 被限制在本地回环，docker port 即使有映射也无效。
常见陷阱：
-
SERVER_NAME=localhost:8080→ Caddy 忽略端口部分，fallback 到默认行为（可能监听:443） - 用了
--network host模式，docker port就不会显示任何端口映射（因为没做 NAT），此时必须看容器内ss -tln和宿主机ss -tln | grep :端口 - 容器启动后改过
SERVER_NAME环境变量但没重启，进程仍按旧配置监听
别信 Dockerfile 或 compose.yaml 里的 ports 声明
Kubernetes 的 containerPort 或 Compose 的 ports 列表只是声明性配置，不是运行时事实。它们不保证端口真被监听，也不校验 FrankenPHP 是否响应。
比如这个 Compose 片段：
ports:<br> - "80:80"<br> - "443:443"
看起来很完整，但如果环境变量是 SERVER_NAME=:8080，FrankenPHP 实际监听的是 :8080，而宿主机 80 端口转发到容器 80 —— 容器里根本没人听 :80，结果就是连接被拒绝。
所以最终验证必须分两步走：
- 查容器内监听地址：
docker exec ... ss -tln - 查宿主机映射关系：
docker port <name>
二者端口号一致，才代表服务真正可访问。少做一次，就可能卡在「配置写了却不通」的死循环里。
