Redis使用RESP二进制/文本协议运行在TCP上，不是HTTP服务。普通HTTP代理不能把GET、SET当网页请求处理。即便通过CONNECT或SOCKS建立TCP隧道，Redis Cluster还会把客户端重定向到其他节点，单一入口的网络设计很容易在此处失效。
一、先确认Redis部署模式
| 模式 | 客户端行为 | 代理重点 |
|---|---|---|
| 单节点 | 连接固定主机 | TCP、TLS、ACL与连接池 |
| 主从加Sentinel | 向Sentinel发现当前主节点 | Sentinel及Redis节点均需可达 |
| Redis Cluster | 获取槽位并访问多个节点 | 拓扑地址、MOVED/ASK与TLS |
| 托管代理端点 | 由服务商代理拓扑 | 以服务能力和文档为准 |
二、HTTP CONNECT与SOCKS能做什么
HTTP代理允许CONNECT到Redis端口时，可以建立TCP隧道，但客户端库需支持；SOCKS5也可转发TCP。两者都不会自动理解Cluster槽位或改写节点元数据。企业网络还需审批目标端口和访问范围。
三、Cluster为什么在代理后失败
客户端最初连接种子节点，获取槽位映射。执行命令时，如果槽位属于其他节点，服务端返回MOVED或ASK及目标地址。该地址若是内网IP、容器名或代理外不可达主机，客户端会超时。解决需从集群公布地址、网络路由或专用网关架构入手。
四、Sentinel也会返回节点地址
Sentinel客户端先连接Sentinel获取当前主节点，再连接Redis。只放通Sentinel端口没有意义，返回的主从地址也必须从客户端可达。故障转移后地址变化，还要验证新主节点路径。
五、TLS如何与网关配合
若TCP网关透传TLS，客户端仍验证Redis节点证书；网关终止TLS则改变信任边界，需要明确后端是否重新加密。Cluster多个节点的证书应覆盖客户端实际使用的主机名。不要通过关闭主机名验证解决拓扑配置错误。
六、Redis ACL和代理认证是两套机制
SOCKS或HTTP代理可能有出口凭据，Redis使用ACL用户名、密码或客户端证书。407属于代理层，NOAUTH、WRONGPASS或NOPERM属于Redis。密码不要写入命令行历史、连接URL日志或监控标签。
七、连接池为何会保留旧节点
客户端连接池会复用到种子、主节点和Cluster节点的连接。拓扑或代理变化后，旧池可能继续访问原地址。应使用客户端支持的拓扑刷新和连接生命周期，避免在运行中修改共享全局代理。
连接复用原理可参考代理切换后旧连接仍生效。
八、空闲超时和健康检查如何设置
代理可能回收长期空闲TCP，客户端从池中取出时才发现连接失效。可使用客户端健康检查、合理的空闲连接回收和重试，但不能对非幂等Lua脚本或事务盲目重放。超时应区分连接、命令与读取阶段。
九、为什么不建议跨公网直接暴露Redis
Redis应位于受控网络，使用TLS、ACL、防火墙和最小访问范围。固定公网IP或代理端口不等于安全认证。对跨地域访问，应评估延迟、数据合规、专线、VPN或托管服务能力。
十、排查日志要看什么
- 客户端库、部署模式和种子地址；
- 实际连接的节点与槽位；
- MOVED、ASK、NOAUTH和超时；
- 连接池新建、复用和淘汰；
- TLS证书主机与代理节点。
十一、测试顺序
- 确认单节点、Sentinel或Cluster模式；
- 验证所有发现地址的DNS和TCP；
- 分别测试TLS与Redis ACL；
- 在Cluster中覆盖多个槽位；
- 模拟主从或节点切换；
- 保持连接超过代理空闲超时；
- 检查连接池和错误重试语义。
十二、结论
Redis代理连接的难点在拓扑发现。单节点入口可达只是开始；Sentinel和Cluster返回的所有地址都必须可达、可验证，连接池和故障切换也要在真实路径上测试。
