一直在排查Redis连接主机的问题，就是连不上主机，真是头大

引用自知乎用户“码农小张的日常”的分享帖子和CSDN博客用户“爱编程的老王”的技术日志）

一直在排查Redis连接主机的问题,就是连不上主机，真是头大，这事儿得从上个礼拜说起，那天下午我正准备给测试环境部署一个新功能，一切都准备好了，代码也检查了好几遍，满心以为点了发布就能顺利跑起来，结果倒好，服务启动是启动了，但是日志里刷刷地报错，清一色的连接Redis超时，我当时心里就“咯噔”一下，心想，完了，又卡在这老熟人身上了。

最开始我以为是小问题,可能就是网络有点波动，我首先想到的是不是Redis服务本身挂了？于是我就用远程工具连上那台放Redis的服务器，输入命令一看，Redis进程好端端地运行着呢，我又试着用命令行客户端从本机连了一下Redis，输入密码后居然成功进去了，还能正常读写数据，这就奇怪了，为什么我的应用就是连不上呢？真是头大。

既然服务没问题,那是不是我应用的配置写错了？我赶紧打开项目的配置文件，像个侦探一样一个字一个字地检查，主机地址（host）、端口号（port）、密码（password），反反复复对了三遍，确认和运维给我的文档一模一样，连个标点符号都没错，我还特意把配置信息复制出来，手动拼成连接字符串，用命令行工具测试，结果还是能连上，这就更让我困惑了，配置没错，服务也没问题，那问题到底出在哪儿？这种感觉就像你知道钥匙肯定在房间里，但就是找不到，急得人团团转。

这时候我开始怀疑是不是网络层面的问题了,我想起来之前好像听运维同事提过一嘴，服务器之间有些端口是有限制的，难道是这个Redis用的6379端口被防火墙拦住了？我赶紧联系运维，让他们帮忙查一下，等了十几分钟，运维回复说，从我的应用服务器到Redis服务器之间的6379端口，防火墙策略是开放的，没有阻拦，这条路又被堵死了，头大的感觉又加深了一层。

我坐下来喝了口水,强迫自己冷静一下，既然直连不通，那会不会是更“底层”一点的原因？Redis的配置绑定了特定的IP地址？我记得Redis有个配置项叫“bind”，它决定了Redis服务监听哪个网络接口，我再次登录Redis服务器，打开它的配置文件，果然，我发现“bind”后面只跟了一个127.0.0.1，这个地址的意思是，Redis只允许本机上的程序来连接它，其他服务器的连接请求它一概不理，这很可能就是问题的根源！我就像发现了新大陆一样，赶紧把这个配置改成了“0.0.0.0”，意思是监听所有网络接口，然后重启了Redis服务，满心期待地回到我的应用，重新启动——结果，日志里依然无情地显示连接超时，我简直要崩溃了，感觉头已经不是自己的了。

时间已经过去两个小时了,我有点黔驴技穷，没办法，只能使出终极武器——抓包，我在应用服务器上打开了网络抓包工具，然后再次尝试启动应用，看着屏幕上滚动的网络数据包，我仔细寻找着发往Redis服务器IP和端口的数据，我发现，应用确实发出了连接请求的包（SYN包），但是一直没有收到对方的确认回复，这说明请求包可能根本没到达Redis服务器，或者服务器的回复被什么东西吃掉了，既然运维说防火墙是通的，那会不会是Redis服务器本机的防火墙呢？我忽然意识到我忽略了这个可能性，我立刻登录Redis服务器，检查了它自身的防火墙规则，果不其然！这个服务器启用了防火墙，而且开放端口列表里根本没有6379，我赶紧添加了一条规则，允许6379端口的传入流量，并重新加载了防火墙配置，做完这一切，我怀着最后一丝希望，回到我的电脑前，颤抖着手点击了应用的启动按钮，这一次，日志安静地滚动着，再也没有出现那个让我头大了一下午的连接错误提示，问题终于解决了！

回想整个过程,就像走了一个巨大的迷宫，从怀疑服务状态，到检查应用配置，再到排查网络防火墙，最后才发现是目标服务器自身的防火墙在作祟，每一个环节看起来都有可能，都需要耐心地去验证和排除，虽然问题解决了，但这种“头大”的经历，真是让人又爱又恨，每一次排查都是一次深刻的教训和经验积累，下次再遇到类似问题，我肯定第一个就会先去检查服务器本机的防火墙了。