Redis端口老跳来跳去到底啥情况，搞得我一头雾水不知道咋整

你遇到的这个问题,说白了就是Redis服务器的端口号在你不知情的情况下发生了变化，导致你的应用程序一会儿能连上，一会儿又断线，报一些连接被拒绝的错误，确实非常让人头疼，这种情况就像你家的门牌号老是变，送快递的当然会找不着北，别急，这事儿虽然烦人，但原因就那么几个，咱们一个一个来捋清楚。

最应该怀疑的就是配置文件被修改了，Redis服务在启动的时候，会读取一个叫 redis.conf 的配置文件，这里面就明确规定了它要“蹲在”哪个端口上干活，默认是 6379，如果这个文件里的 port 这个设置项被人为改动过，或者被某个自动化脚本、配置管理工具（比如Ansible、Puppet）给覆盖了，那么下次重启Redis的时候，它自然就跑到新端口上去了，你得去检查一下这个配置文件，看看里面的 port 后面跟的数字是不是你期望的那个，有时候可能有好几个配置文件，Redis启动时加载了错误的那个，也会导致这个问题。

要留意启动命令或者服务脚本，有些人可能为了临时测试，或者记不住配置文件在哪，会直接通过命令行启动Redis，并且用 --port 参数来指定端口，redis-server --port 6380，如果这个临时命令被写进了开机启动脚本（比如Linux系统的systemd服务文件或者老的init.d脚本）里，那么每次系统重启，Redis都会按照这个命令行的指示，在6380端口启动，你得去检查一下启动Redis的那个命令，看看有没有这种“霸道”的参数指定。

第三个常见原因是安全软件或防火墙的干扰，这种情况比较隐蔽，有些主机安全软件或者云服务商（比如阿里云、腾讯云）的安全组，它们出于安全考虑，可能会认为某些端口的访问是危险的，如果它们检测到Redis运行在默认的6379端口，可能会自动阻止连接，甚至有些激进的软件可能会尝试“隔离”这个服务，强制它换到一个别的端口上去运行，虽然不常见，但确实存在这种可能性，尤其是在云服务器上。

第四个可能性是有多个Redis实例在运行，你可能在不经意间，或者通过某些安装脚本，在同一台机器上启动了多个Redis服务进程，一个通过系统服务方式启动，占用了6379端口；另一个你可能自己手动从命令行启动，占用了6380端口，如果你的应用程序的配置没有写死，或者被动态更改了，就可能出现一会儿连到这个实例，一会儿连到那个实例的情况，看起来就像是端口在“跳来跳去”，你可以用像 ps aux | grep redis 或者 netstat -tunlp | grep redis 这样的命令，检查一下到底有几个Redis进程在跑，它们分别占用了哪些端口。

第五个,也是很容易被忽略的一点，是动态配置，特别是在使用Redis哨兵（Sentinel）模式做高可用的时候，当主节点（master）发生故障，哨兵会自动选择一个从节点（slave）升级为新的主节点，如果你的应用程序是通过哨兵来获取当前有效的主节点地址，那么在主从切换发生后，应用程序连接到的IP和端口自然就变了，这虽然是正常的高可用机制，但如果你不了解这个背景，就会觉得端口莫名其妙地变了，你需要检查你的应用连接配置，是不是指向了哨兵，而不是直接写死了某个Redis实例的地址和端口。

那到底该怎么整呢？你可以按照下面这个步骤来排查，就跟破案一样：

1. 现场抓现行：当连不上的时候，立刻用命令（如 netstat -tunlp | grep 63）看看当前到底哪个端口上有Redis进程在监听，确认一下它现在到底在哪儿。
2. 查户口（配置文件）：找到Redis的配置文件（通常是 redis.conf），打开看看 port 这一行到底是怎么写的，确保这是你想要的端口。
3. 查案底（启动方式）：检查Redis是作为系统服务启动的还是手动启动的，如果是系统服务，就查服务的配置文件（比如systemd的 .service 文件）；如果是手动启动，看看启动脚本或者历史命令。
4. 问保安（安全策略）：检查一下服务器上的防火墙规则（iptables/firewalld）和云服务商的安全组设置，确保没有规则在阻拦或重定向你的Redis端口。
5. 清场子（避免多实例）：确保同一时间只有一个你期望的Redis实例在运行，把多余的关掉。
6. 看说明（应用配置）：仔细检查你的应用程序连接Redis的配置代码，确保它没有在运行时被动态修改，或者配置本身就是指向一个会变化的源（如哨兵）。

基本上,把这几个地方都检查一遍，九成九能揪出那个让端口“跳来跳去”的罪魁祸首，这事儿就是个细心活儿，别慌，一步步来总能解决。