[date: 2019-02-13 10:58] [visits: 577]

一次shadowsocks故障解决

过完年回深圳后发现电脑不能使用Google,导致解决问题能力直线下降,真是要了老命,因此试着寻找问题原因并解决。

置顶

问题原因写在前面,如果你也因为ss出现问题而看到这篇文章,可以试试下面的解决方案:

自己遇到的问题原因是由于服务器IP+端口被GFW封了,因此需要更换服务器IP或ss的监听端口。

前言

很早之前有写过一篇Mac科学上网的文章,里面总结了自己的科学上网方式,在过去的一年里自己一直用的很顺畅,体验非常棒,有兴趣的朋友可以回头看看那片文章。

实现科学上网的核心是借助shadowsocks,而这次突然异常不能使用,琢磨着应该是ss出了问题,所以后面重点就是寻找并解决ss的问题。

解决过程

回家前一天自己还有查收Gmail,且过年期间自己电脑和服务器都没动过,应该不是自己原因导致无法科学上网,但情况就是之前正常,现在打开自动代理后Google依旧无法访问。

想着从服务端开始排查,尝试重启ssserver,问题依旧,接着Baidu了一番“如何看ssserver日志”,只意外找到一种方式:

journalctl -u xxx

命令journalctl用来查询systemd-journald服务收集到的日志,自己的ssserver刚好也是通过systemctl启动的,通过命令看到了一大堆回家过年前的日志内容,对于现阶段定位问题没有太大帮助。

这种日志查看方式,内容不能实时刷新,不好判断client有没有连接到服务器,但随后在/var/log/messages中发现了ssserver的日志内容(CentOS 7.4),因此可通过tail -f messages |grep ssserver实时查看ssserver的日志输出。

由于还怀疑是client问题,检查了一下本地ss-local服务,发现启动无异常,同时怀疑是PAC的代理方式有问题,因此没有使用自动代理,而是在网络设置中设置并打开socks代理,刷新浏览器中的网页发现服务端没有任何内容输出且网页也无法访问,猜测是没有流量到服务器,但如果要寻找client问题,由于没有日志感觉得难度更大。

所以这里借朋友电脑,使用他的图形化shadowsocks再次尝试链接,服务端日志中依旧没有输出,通过两个原本正常的client连接服务器,发现服务端都没有日志输出,依旧不能肯定是哪一端的问题,但认为服务端问题可能性更大。

没日志输出后,自己在阿里云后台检查了一下服务器的访问控制,明确ssserver所使用的端口有打开,同时自己猜测是不是阿里云封了ssserver所在的端口,随后自己使用telnet amsimple.com xxx测试了一下,的确卡在Trying...,但由于知识不牢靠,自己犯了个失误:“不绝对肯定telnet如何判断端口打开或关闭,而且阿里云控制台看到访问规则有打开这个端口,所以自己选择忽视了这个Trying而中断了telnet的运行”,实际上是telnet大约30s后会打印“Operation timed out”,虽然这个timeout不能肯定判断是端口关闭,但是换几个端口做对比测试,应该是比较容易发现这就是阿里云访问控制中非开放端口的表现。

由于失误,自己没有发现ss不能使用的原因是因为端口被封,因此自己又在另外一台机器上搭建了ssserver,随后经测试是可以正常使用的。这说明client是没有问题的,这时自己反应过来可能是服务器被封了IP,而自己的博客依旧可以访问,所以猜测是被GFW封了IP+端口而不是IP,随后改一下配置换一个端口后,就又可以开开心心的使用Google了。

总结

写这篇文章的初始目的仅仅是记录,并无多少其他意义,颇有流水帐的感觉,但在写到用telnet测试端口是否打开时,才意识到自己的错误,如果自己能在当时严谨、敏锐一点的话,就不需要到另外一台服务器上安装sserver发现问题。反省后发现自己因这种浮于表面的做法导致走弯路的现象并不少,这多多少少暴露了自己的一些缺陷,想必这就是写文章和写这篇文章的意义:“发现以及正视自己的不足,努力做到更好”。