超时本质是服务节点不可达，而非等待超时；需检查nodes配置是否为容器可解析地址、宿主机防火墙是否放行跨容器流量、服务是否监听0.0.0.0而非127.0.0.1。
超时不是随机发生的，而是服务节点不可达的明确信号。当 JsonRpcHttpTransporter 在调用前无法从负载均衡器拿到可用节点，就会直接抛出超时或 Cannot select any node from load balancer. 错误 —— 这本质是「连不上」，不是「等不及」。
检查 nodes 配置是否指向了真实可通的服务地址
Hyperf 的 JSON-RPC 客户端依赖 config/autoload/rpc_client.php 中的 nodes 列表来建立连接。如果这里写的是 127.0.0.1 或 localhost，在 Docker 容器间调用时必然失败：
- 容器内
127.0.0.1指向自身，不是服务提供者容器 - 必须使用宿主机 IP、Docker 网络内可解析的容器名，或固定分配的 IP（如你创建的
172.172.0.0/24网段） - 若用 Consul 做服务发现，
nodes应为空数组，由服务治理组件自动填充；但一旦手动填了nodes，Hyperf 就会跳过服务发现，只从这个静态列表里选节点
示例错误配置：
'nodes' => [
['host' => '127.0.0.1', 'port' => 9501],
],
应改为（假设服务提供者容器名为 hyperfServer，同属 hyperf 自定义网络）：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
'nodes' => [
['host' => 'hyperfServer', 'port' => 9501],
],
Docker 容器间通信被内网防火墙拦截
即使 nodes 写对了，Linux 宿主机上的 iptables 或 nftables 仍可能默认 DROP 跨容器流量，尤其当你启用了 ufw 或企业级安全策略时：
- 检查宿主机是否启用防火墙：
sudo ufw status或sudo iptables -L -n - 确认 Docker 网桥接口（如
br-xxxx）未被规则屏蔽；常见误配是只放行docker0，而忽略自定义网络桥接设备 - 临时关闭防火墙验证问题：
sudo ufw disable（仅测试用，勿在线上长期关闭） - 更稳妥的做法是添加白名单规则，例如允许
172.172.0.0/24网段内所有 TCP 流量互通
验证节点连通性不能只靠 ping
ping 走 ICMP，而 JSON-RPC HTTP 协议走的是 TCP 80/443/自定义端口（如 9501）。容器能 ping 通不代表服务端口开放：
- 进服务消费者容器执行：
telnet hyperfServer 9501或nc -zv hyperfServer 9501 - 如果连接被拒绝（Connection refused），说明服务没起来，或监听地址绑定错了（比如只绑了
127.0.0.1:9501，没绑0.0.0.0:9501） - 如果连接超时（No route to host / Connection timed out），才是网络层或防火墙问题
服务提供者容器中检查监听状态：ss -tlnp | grep :9501，确认输出中有 0.0.0.0:9501 或 *:9501，而非仅 127.0.0.1:9501。
真正卡住的地方往往不是协议或代码逻辑，而是 nodes 配置里的一个 IP 写错，或者宿主机防火墙悄悄拦下了 172.172.0.x 的包 —— 这两类问题不会报错“连接拒绝”，只会让请求无声超时。
