如何用 ss + ps 精准定位本机 Redis 的“隐形”消费者？

💡 引言 / 背景

在日常运维和服务器安全审计中，我们经常会遇到这样的场景：阿里云等云厂商告警提示"Redis 弱密码/未授权访问"，或者我们需要梳理服务器上到底有哪些业务在使用 Redis。

很多人习惯用 ss -tnp | grep :6379 来查找连接，但往往觉得"不准"或"信息太少"。今天，我们就通过一个真实的线上排查案例，演示如何通过网络层命令结合进程分析，精准揪出使用 Redis 的底层业务。

🔍 第一步：从网络层捕获"案发现场"

首先，我们通过 ss 命令查看当前与 Redis (6379端口) 建立的 TCP 连接：

复制代码

ss -tnp | grep :6379

输出结果：

复制代码

ESTAB 0 0 127.0.0.1:6379    127.0.0.1:54700   users:(("redis-server",pid=2872,fd=11))
ESTAB 0 0 127.0.0.1:54700   127.0.0.1:6379    users:(("php",pid=610,fd=4),("php",pid=609,fd=4))

📝 关键信息解读

双向连接 ：前两行其实是同一个 TCP 连接的两端。一端是服务端 redis-server (PID 2872)，另一端是客户端 php。
多进程共享 Socket ：注意客户端显示有两个 PID（610 和 609），且文件描述符（fd）都是 4。这说明这两个 PHP 进程共享了同一个底层 TCP Socket。这是典型的主子进程模型特征（父进程创建连接后 fork 出子进程，子进程继承了 fd）。
纯本地通信 ：IP 均为 127.0.0.1，说明是单机内部调用，排除了外部恶意连接的可能。

⚠️ 避坑指南

为什么有时 ss 查不到 Redis 连接？因为 ss -tn 只能抓取执行瞬间处于 ESTAB 状态的 TCP 连接。如果应用使用的是 Unix Domain Socket，或者采用极短的连接池/短连接，就很容易漏掉。因此，网络层抓包只是起点，必须结合进程分析。

🕵️‍♂️ 第二步：顺藤摸瓜，还原业务真身

拿到了可疑的 PHP 进程 PID（609, 610），接下来用 ps 命令查看它们的真实身份：

复制代码

ps -fp 609,610

输出结果：

复制代码

UID   PID  PPID C STIME TTY  TIME       CMD
root  609  1    0 Apr23 ?    00:00:00   WorkerMan: master process start_file=/www/wwwroot/
root  610  609  0 Apr23 ?    04:14:14   WorkerMan: worker process none none

📝 真相大白

PID 609 (Master)：PPID 为 1，说明它是脱离终端运行的守护进程主节点。启动时间远在几个月前（Apr23）。
PID 610 (Worker) ：PPID 为 609，证实了我们在 ss 中看到的"父子进程共享 Socket"的猜想。它的 CPU 累计时间长达 4 个多小时，说明这是一个长期驻留内存、持续高频处理任务的进程。
业务定性 ：这不是普通的 Web 请求（如 Nginx+PHP-FPM），而是基于 Workerman 框架的常驻内存应用。结合它长期持有 Redis 连接的特征，该业务极大概率是在做消息队列消费（Queue Worker） 、WebSocket 推送服务 或实时数据订阅。

🛠️ 第三步：闭环验证与安全加固

定位到 Workerman 后，排查工作并未结束，还需要完成以下闭环：

代码级确认 ：进入 /www/wwwroot/ 目录，搜索 Workerman 的启动脚本及 Redis 配置，确认其具体业务逻辑（如搜索 new Redis()、subscribe、pop 等关键字）。
补齐监控盲区 ：既然确认了是 Workerman 这种常驻进程，后续监控不应再依赖 ss 瞬时状态，而应检查 Supervisor/Systemd 的托管状态，或在 Redis 中使用 CLIENT LIST 查看长连接的 name 标识。
安全加固 ：针对此类本机长连接业务，强烈建议将 Redis 的 TCP 监听改为 Unix Domain Socket，并通过文件权限控制访问。这不仅能彻底杜绝 SSRF 攻击风险，还能消除云厂商的"弱密码/未授权"告警，同时提升本地 IPC 通信性能。

🎯 总结

排查本机 Redis 使用者，不能仅停留在"谁连了 Redis"，更要搞清楚"它用 Redis 做了什么"。

ss -tnp 提供了网络连接与进程 PID 的映射，而 ps -fp 则揭开了进程的架构面纱。当两者结合时，我们就能从冰冷的端口号中，还原出 Workerman 队列消费、缓存读写等真实的业务图景。掌握这套组合拳，无论是应对安全审计还是故障排查，都能做到心中有数、手中有刀。