Hyperf外部无法访问的主因是宿主机防火墙拦截9501端口，应通过ufw或iptables精准放行该端口及Docker自定义网段（如172.172.0.0/24），而非关闭防火墙；同时需确认服务监听0.0.0.0:9501、Docker端口映射正确、容器网络配置无误。
Hyperf 默认监听 9501 端口，但服务启动后外部无法访问，常见原因不是代码或配置错误，而是宿主机防火墙拦截了该端口。关闭防火墙只是临时验证手段，真正可靠的做法是精准放行端口，兼顾安全与连通性。
确认当前防火墙状态
先判断系统用的是 ufw 还是 iptables/nftables：
- Ubuntu/Debian 系统常用：sudo ufw status —— 若显示 inactive，说明未启用；若为 active，需进一步查看规则
- CentOS/RHEL 系统常用：sudo iptables -L -n 或 sudo nft list ruleset
- 无论哪种，只要输出中没有允许 9501 端口的规则，外部请求就会被 DROP 或 REJECT
放行 Hyperf 端口（推荐方式）
不建议直接关闭防火墙，应添加明确规则。以 9501 为例：
- ufw 用户执行：sudo ufw allow 9501/tcp
- iptables 用户执行：sudo iptables -A INPUT -p tcp --dport 9501 -j ACCEPT，并保存规则（如 sudo iptables-save > /etc/iptables/rules.v4）
- 若使用 Docker 且服务运行在自定义网络（如
172.172.0.0/24），还需放行该网段内互访：sudo ufw allow from 172.172.0.0/24 to any port 9501 proto tcp
验证端口是否真正开放
仅检查防火墙规则不够，要从外部真实测试：
- 在另一台机器或宿主机上执行：telnet 你的服务器IP 9501 或 nc -zv 你的服务器IP 9501
- 成功返回 Connected 表示端口可达；若提示 Connection refused，说明服务未启动或监听地址不对（比如只绑了 127.0.0.1）；若提示 No route to host 或超时，则仍是防火墙或网络策略问题
- 同时确认 Hyperf 服务确实在监听：ss -tlnp | grep :9501，输出中应含
0.0.0.0:9501或*:9501
容器部署时的额外注意点
Docker 环境下，除了宿主机防火墙，还要看 docker-compose.yml 中是否正确映射端口：
- 确保
ports:下有 - "9501:9501" 这类映射，否则容器内服务即使正常，宿主机也无法访问 - 若用自定义 bridge 网络（如
hyperf_net），宿主机防火墙必须放行该网桥接口（如br-xxxx），不能只认默认docker0 - Consul 等服务发现场景下，
nodes配置若写死为127.0.0.1，即使端口放行也连不通——此时是容器网络层问题，非防火墙问题
