redis acl 的 &pattern 对 subscribe 无效，因其仅在 redis 6.2+ 启用 acl-pubsub-default 后作用于 publish 校验，subscribe 完全绕过该匹配逻辑；真正权限控制必须依赖应用层鉴权、tls 加密和实例隔离。

Redis 本身不支持频道级订阅权限控制，ACL 无法按频道名限制 SUBSCRIBE 行为——必须靠应用层拦截 + TLS 加密 + 实例隔离三者配合才能真正落地权限控制。

为什么 ACL 的 &pattern 对 SUBSCRIBE 无效？

ACL 中的 &metrics:* 看似能匹配频道，但实际只在 Redis 6.2+ 且启用 acl-pubsub-default 后才生效；即使配置了，它也仅作用于 PUBLISH 命令的频道校验，对 SUBSCRIBE 无约束力。实测中：

• ACL SETUSER reader on >pass ~* &user:123:* +SUBSCRIBE → 订阅 user:456:notify 仍成功（& 不参与 SUBSCRIBE 权限判断）
• ACL LIST 显示规则存在，但 SUBSCRIBE 操作完全绕过 & 匹配逻辑
• 唯一能拦住订阅的 ACL 配置是禁用命令本身：-SUBSCRIBE，但这等于关闭整个功能

怎样让不同用户只收到自己权限内的频道消息？

必须在服务端做鉴权，不是靠 Redis 配置。典型流程是：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 客户端连接时携带 token 请求 /api/v1/pubsub/channels
• 后端解析 token 得到用户 ID 和角色，查 DB 或缓存生成白名单，例如 ["user:123:notify", "org:789:report"]
• 客户端只对白名单里的频道执行 SUBSCRIBE，禁止硬编码泛化频道名如 all 或 admin
• 频道命名必须带业务前缀和权限粒度，如 org:789:report:update，便于后端按冒号分段提取 org_id 校验

开启 TLS 是防止敏感信息泄露的底线

未启用 TLS 时，SUBSCRIBE 和 PUBLISH 的频道名与消息体全程明文传输，中间节点可直接抓包。必须：

• 服务端启用 tls-port 6380，并配置 tls-cert-file、tls-key-file、tls-ca-cert-file
• 客户端使用 rediss:// 协议连接，显式传入 CA 证书；自签名证书需设 ssl_cert_reqs=None
• 关闭非 TLS 端口（注释掉 port 6379 或防火墙 DROP），否则攻击者会降级到明文连接

ACL 能真正起效的 Pub/Sub 场景只有两个

ACL 在 Pub/Sub 中仅对两类操作有实际约束力：

• +PUBLISH + &pattern：限制用户只能向匹配 pattern 的频道发消息，例如 &order:* 允许发 order:123，但拒绝 user:456
• acl-pubsub-default resetchannels（Redis 6.2+）：默认禁止所有频道访问，再用 & 显式放开，避免误开全量通道

频道名匹配是 glob 模式（不是正则），&logs:* 不匹配 logs（无冒号）或 app:logs（前缀不符），这点容易被忽略。