Redis集群节点启动报“Address already in use”，绝大多数因端口被占或TIME_WAIT耗尽本地端口池；须用ss -tuln查6379/16379监听状态，再结合sudo lsof -iTCP:6379 -sTCP:LISTEN精准定位占位进程，并检查net.ipv4.tcp_tw_reuse等内核参数是否适配集群双向通信需求。
Redis 集群节点启动失败并报 Address already in use，绝大多数情况不是配置写错，而是端口被占或内核未释放——必须分两层查：先看有没有进程真正在 listen，再看有没有大量 TIME_WAIT 卡住本地端口池。
怎么快速确认是哪个进程在监听 6379（或集群其他端口）
别直接 kill 或改配置，先定位“占位者”。Redis 集群默认每个节点用一个主端口（如 6379）加一个集群总线端口（16379），两者都可能被占。
- 用
ss -tuln | grep ':6379\|:16379'查监听状态，输出里带LISTEN且地址含*:6379或*:16379的行就是目标 - 若看到 PID/进程名（如
redis-server），再执行ps -p <PID> -o pid,ppid,cmd确认是不是你本该停掉的旧实例 - 若没显示进程名（比如只显示
-），说明权限不足，加sudo重试；或者用sudo lsof -iTCP:6379 -sTCP:LISTEN更准 - 特别注意 Docker 容器：
docker ps --format "table {{.ID}}\t{{.Ports}}" | grep '6379'可能暴露桥接映射
为什么杀完进程还是报 Address already in use
常见于频繁启停集群节点的开发环境，本质是内核处于 TIME_WAIT 状态，不是进程没杀干净。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
ss -tan state time-wait | grep ':6379'能筛出连到本机 6379 的客户端连接残留（比如别的节点连它失败后留下的） - 但更关键的是看**本地发起的连接**：集群节点间通信（如
CLUSTER MEET）会主动 connect 其他节点，这些 outbound 连接关闭后进入TIME_WAIT，会占用本地临时端口，不是 6379 本身，但可能耗尽ip_local_port_range - 运行
ss -s，重点看time-wait行数字。如果远超established（例如 2w vs 50），且net.ipv4.ip_local_port_range是默认32768 65535，就说明本地端口池快满了 - 此时即使
6379没被 listen，bind()仍可能失败——因为内核分配不出可用源端口给新连接（集群握手、Gossip 等都需要）
Redis 集群场景下该调哪些内核参数
单机 Redis 可能只需杀进程，但集群节点既是服务端又是客户端，必须同时处理两端的端口压力。
- 必须开启
net.ipv4.tcp_tw_reuse = 1：允许把TIME_WAIT状态的 socket 用于新的 outbound 连接（对集群节点间通信至关重要） - 必须设
net.ipv4.tcp_fin_timeout = 30：缩短FIN_WAIT_2超时，加快连接清理（比默认 60 秒更激进但安全） - 建议扩端口范围：
net.ipv4.ip_local_port_range = 1024 65535（避开 1–1023 权限限制，实际可用端口翻倍） - 禁用已废弃的
net.ipv4.tcp_tw_recycle = 0（NAT 环境下会导致连接失败，K8s 或云厂商 SLB 下必关） - 以上修改后需
sysctl -p生效，且要写入/etc/sysctl.conf防重启丢失
集群配置里容易忽略的 bind 地址陷阱
报错里常出现 *:6379，但实际绑定失败可能是因为 bind 配置不匹配网卡。
- 检查
redis.conf中bind行：若写成bind 127.0.0.1，而集群节点间用的是局域网 IP（如192.168.1.10），则其他节点 connect 失败后反复重试，会堆积TIME_WAIT - 集群模式下推荐显式绑定多地址：
bind 127.0.0.1 192.168.1.10，或干脆注释掉bind（依赖protected-mode no+ 密码控制） -
cluster-announce-ip和cluster-announce-port必须与真实对外地址一致，否则其他节点解析到错误 IP，连接持续失败 → 大量TIME_WAIT - 容器部署时，
host.docker.internal或network_mode: host配置错误，也会导致节点互相 resolve 到 127.0.0.1，形成无效环路连接
真正麻烦的不是 Address already in use 本身，而是它背后混着两类问题：一个是别人正用着那个端口，另一个是你自己发出去的连接太多太碎，把本地端口池堵死了。集群节点双重身份决定了必须两边一起看，漏掉任何一层，都会反复踩坑。
