hyperf redis连接超时大概率是dns解析阻塞，因容器内默认dns配置导致gethostbyname()延迟高；应改用ip、预解析域名、指定可靠dns或通过/etc/hosts硬编码服务地址。
Hyperf Redis连接超时，大概率是DNS解析卡住
Hyperf项目在Docker里访问慢，尤其是Redis报Connection timeout，但直连IP完全正常——这基本不是Redis服务问题，而是gethostbyname()阻塞在域名解析环节。Hyperf的RedisConnection.php在构造连接时会同步调用系统DNS解析，一旦DNS响应慢（比如超过1秒），整个请求就卡死在那里。
常见现象包括：
- 日志里反复出现
Connection reconnect failed，但redis-cli -h redis.example.com -p 6379 ping能通 -
time dig +short redis.example.com返回耗时>500ms - PHP代码中
microtime(true)测出gethostbyname()耗时远超预期
容器内/etc/resolv.conf默认配置极可能拖垮性能
Docker容器默认继承宿主机的/etc/resolv.conf，而宿主机DNS往往指向局域网网关或企业内网DNS服务器，这类DNS在容器网络路径下常出现高延迟、超时甚至丢包。
验证方式很简单：进容器执行
cat /etc/resolv.conf
如果看到nameserver 192.168.x.x或nameserver 10.x.x.x这类内网地址，基本就是罪魁祸首。
临时修复（仅测试用）：
echo "nameserver 8.8.8.8" > /etc/resolv.conf
但更稳妥的做法是在启动时指定：
- 单容器：
docker run --dns 8.8.8.8 --dns 1.1.1.1 ... - Docker Compose：
dns: ["8.8.8.8", "1.1.1.1"]写进服务配置 - 全局生效：修改
/etc/docker/daemon.json加"dns": ["8.8.8.8","1.1.1.1"]并重启dockerd
别让Hyperf每次连接都重新解析域名
Hyperf默认不会缓存DNS结果，只要config/redis.php里填的是域名（如'host' => 'redis'），每次connect()都会触发一次gethostbyname()。高频服务下，这个开销会被放大。
两个务实解法：
- 改用IP地址：把
'host' => 'redis'换成实际IP（需确保IP稳定，比如自定义Docker网络下容器IP固定） - 强制预解析+复用：在
ServerProcess或Command里提前调用gethostbyname()，把结果存进Config或ApplicationContext，后续连接直接取IP - 禁用IPv6回退（常被忽略）：在
resolv.conf加options single-request-reopen，避免IPv6查询失败后重试IPv4导致双倍延迟
自定义Docker网络 + /etc/hosts硬编码是最稳方案
当服务间调用关系固定（如Hyperf连Redis、MySQL），靠DNS解析纯属浪费。Docker自定义bridge网络天然支持服务名自动解析，但默认仍走DNS流程；更彻底的方式是绕过DNS，直接绑定IP。
操作步骤：
- 创建自定义网络：
docker network create app-net - 启动Redis容器时指定静态IP：
docker run --network app-net --ip 172.20.0.10 --name redis redis - 启动Hyperf容器时用
--add-host redis:172.20.0.10，或在docker-compose.yml里写extra_hosts: ["redis:172.20.0.10"] - 此时容器内
/etc/hosts会自动添加172.20.0.10 redis，gethostbyname("redis")瞬间返回，零DNS开销
这个方案不依赖任何外部DNS，也不受dnsmasq并发限制或TTL缓存影响，是生产环境高稳定性场景下最值得优先尝试的路径。
