记一次难忘的redis配置

​ 2023年8月2日晚上11点，我尝试使用golang连接我的redis数据库，虽然这只是为了学习golang的一些包，但总免不了需要配置一下redis。正好，我在6月份白嫖了一份阿里云的半年服务器，可以用来测试远程连接。然而，代码并没有能成功连接上我的redis，而是给出了如下的报错：dial tcp 172.16.136.8:6379: i/o timeout

​ 那时，我并没有意识到这个问题将在未来一天困扰我很久。我上网搜索了一下redis连接的问题，大多给出的答案是redis的配置文件没有设置正确，因此，我按照步骤去做。同时，为了防止是我的代码问题，我选择下载了RDM客户端去连接，在保证能连接上后再去测试我的代码。然而，一直到第二天的凌晨1点，我依旧未能成功连接。似乎，这只是一个小问题，我当晚沉沉睡去。

​ 2023年8月3日晚上10点，我又一次想起了昨晚未能完成的问题。于是我开始高强度去检查我的设置是否有问题。

​ 首先，我怀疑起了服务器的防火墙，然后我一通firewall-cmd --list-all，系统提示：我防火墙压根没开。OK，那还可能是我进站IP设置了规则，于是我又一通：iptables -L，结果告诉我，redis的tcp允许所有连接。

​ 唔，到这里，我开始陷入沉思，难道还有其它的东西。没错，我知道了，阿里云的服务器是需要开启安全组，允许我的Redis的6379端口开放才行，于是我再次打开了阿里云的控制台，设置好了6379端口的安全组规则。这时，我已经非常自信了，一定能连接成功。

​ 但是，很可怕的是，依旧连接失败。我怀疑起了昨晚我是不是没睡醒，虽然我正常来说肯定是晚上很清醒的，但不能保证我昨晚其实并没有配置好redis的文件。而且redis的配置文件又长又难看，难免会搞错，于是我又一通：grep “port” /etc/redis.conf以及grep “bind” /etc/redis.conf，但是结果是，昨晚我的配置并无问题。

​ 事情从这里变得诡异了起来，我开始思考一些玄学的因素，导致我的电脑不能正常连接我的服务器。然而，我依旧能通过远程控制来操作我的服务器，说明肯定不是网络问题。没办法了，只能抓包试试了。

​ 我打开了wireshark的抓包，完成了连接的抓包。他告诉我，我的TCP连接确实从53070端口发了出去，但是却发生了TCP Retransmission。不应该啊，按理来说，我肯定可以连接上我的服务器，因为我正在用远程控制ssh操作我的Ubuntu。很奇怪，我转向在服务器端进行抓包。又是一通：tcpdump -i eth0 port 6379 -c 1 -G 8 -W 1。然而系统久久没有反应，说明我的连接根本就没有到达我的服务器。

​ …事情到这里已经变得很奇怪了，可以排除是服务器的问题，难道是我windows的防火墙，虽然可能性很小，但是我还是尝试了关闭防火墙，设置换了一个网来以防外一。依旧连接失败。

​ 此时已经是11点半了，正当我准备接受现实时，我忽然发现，好像我用ifconfig打出来的IP地址不是很对，那…好像是一个内网ip。我恍然大悟，从阿里云的控制台看了一眼，果然，我的服务器的公网ip根本不是这个。行了，事情到此就解决了。虽然但是，还是做个记录来警醒自己，真的是低级错误。