云服务器访问失败原因?从这些“罪魁祸首”说起，帮你一步步找回连接

那是一个普通的周二上午，我正在给客户做远程演示，突然浏览器里的网站页面转起了圈圈。一圈，两圈，三圈……最后干脆弹出一行冰冷的字：“无法访问此网站”。我赶紧打开终端尝试SSH连接，结果同样失败，连接超时。客户的电话紧跟着就打了过来，语气里满是焦虑：“怎么回事?网站打不开了!”我相信很多使用云服务器的朋友，都经历过这种“突然失联”的绝望时刻。

云服务器访问失败，说起来就是连不上、打不开、登不进。但是导致这个问题的原因却五花八门，有时候是配置上的一个小疏忽，有时候是服务商那边的问题，还有时候甚至是你自己电脑的网络出了毛病。今天我就从这些年亲身踩过的坑和解决过的案例出发，把云服务器访问失败的各种原因掰开揉碎了讲清楚，希望能帮你在下一次“失联”的时候快速找到症结所在。

在讲具体原因之前，我想先说一个很重要的思路。当云服务器无法访问时，千万不要只盯着服务器本身看。网络访问是一条完整的链路，你的电脑、家里的路由器、运营商网络、云服务商的入口、安全组规则、服务器内部的服务、防火墙……任何一个环节卡住了，都会导致访问失败。排查要像侦探破案一样，从外到内，从近到远，一步步缩小范围。

接下来，我把最常见的几类原因一一道来。

第一类，也是最容易被忽略的一类，是你自己本地网络的问题。

很多人一发现云服务器连不上，第一反应就是服务器挂了或者被攻击了，慌慌张张去登录云控制台。但实际上，问题可能就出在你自己的网络上。比如你办公室的路由器突然断网了，或者你连的WiFi信号不好，又或者你所在地区的运营商出现了线路故障。

我有一个真实的经历。有一次在外地出差，住在酒店里，晚上想连公司的云服务器处理一个紧急事务，结果怎么都连不上。我反复确认了IP地址、端口、密钥，都没有问题。折腾了半小时，我突然试了一下打开百度，发现也打不开。这才意识到是酒店的网络本身有问题，并不是云服务器的事。换到手机热点之后，一切恢复正常。所以当你发现云服务器访问失败时，第一件事不是去控制台重启服务器，而是先试试能不能访问其他常见的网站，比如百度或者腾讯。如果其他网站也打不开，那问题就在你自己的网络上，该检查路由器就检查路由器，该联系运营商就联系运营商。

第二类，云服务商控制台的安全组或者防火墙规则配置错误。

这是云服务器访问失败最常见的原因之一，尤其是对于刚接触云服务器的朋友来说。安全组可以理解为云服务器外面的一个虚拟防火墙，它控制着哪些IP地址、哪些端口可以访问你的服务器。如果你忘了在安全组里放行SSH的22端口，那你就永远无法通过SSH登录。如果你忘了放行HTTP的80端口或者HTTPS的443端口，那你的网站就没人能访问。

有一个案例我印象很深。一位做个人博客的朋友，买了一台云服务器，兴致勃勃地部署好了网站环境，输入域名一看，打不开。他又试了直接用IP地址访问，还是打不开。他怀疑是Web服务器没启动，检查了Nginx，发现运行正常。他又怀疑是代码问题，查了半天也没查出毛病。最后我问他，你在安全组里放行80端口了吗?他愣了一下，说什么是安全组?后来他去控制台一看，安全组里只放行了一个22端口，80和443都没有添加。加上之后，网站立刻就通了。你看，有时候问题就这么简单，但如果你不知道这个环节，就会在错误的路上浪费大量时间。

所以排查的时候，一定要先登录云服务商的控制台，检查你的实例关联的安全组。入方向规则里有没有允许你需要的端口来源IP范围是否正确。如果你是从家里或者办公室访问，不要设置成0.0.0.0/0允许所有，但为了测试，可以先设置成0.0.0.0/0看看是不是IP范围的问题。生产环境再根据实际情况收紧。

第三类，云服务器操作系统内部的防火墙设置。

安全组是云服务商层面的一道墙，而云服务器内部的操作系统往往还有自己的防火墙，比如Linux系统中的iptables或者firewalld，Windows系统中的Windows防火墙。有时候安全组放行了端口，但系统内部的防火墙没有放行，同样会导致访问失败。

我之前帮一个客户处理过一个问题。他的云服务器突然无法通过SSH连接了，但是安全组里明明放行了22端口。通过云控制台的远程连接功能登录到服务器内部之后，我检查了sshd服务的状态，是正常运行的。然后我查看防火墙规则，发现他之前为了测试某个服务，执行了一条命令把所有的INPUT链默认策略设置成了DROP，但是没有放行已建立的连接和SSH端口。重启之后规则没保存，但一重启，规则依然存在，因为他是用firewalld做的配置。后来我临时添加了一条放行22端口的规则，SSH连接立刻就恢复了。然后他再把默认策略改回ACCEPT，问题彻底解决。

当你的云服务器连不上时，如果你能通过云控制台提供的管理终端登进去，那一定要检查一下系统防火墙的规则。可以用iptables -L -n查看当前规则，看看有没有放行你需要的端口。如果没有，就添加相应的放行规则，并且注意保存规则，防止重启后失效。

第四类，云服务器内部的服务没有正常启动或者监听地址错误。

安全组和防火墙都放行了，但你还是访问不了，那就要看看服务本身了。比如你想访问网站，那Web服务器比如Nginx或者Apache有没有启动。你想SSH登录，那sshd服务有没有在运行。你想连接MySQL数据库，那MySQL服务有没有在监听。

不光要检查服务有没有启动，还要检查服务监听的地址对不对。很多服务默认只监听127.0.0.1这个地址，意思是只允许本机访问。如果你想让外部访问，需要修改配置文件，让服务监听0.0.0.0或者服务器的内网IP地址。

我遇到过这么一件事。一个开发者在云主机上部署了一个Node.js写的API服务，他告诉我说外网访问不了。我登上去一看，服务确实在运行，用curl命令在服务器本机上访问也是正常的。但是我检查了一下监听端口的情况，执行netstat -tunlp | grep node，发现监听地址是127.0.0.1而不是0.0.0.0。这就意味着这个服务只能在服务器内部访问，外网根本进不来。他修改了代码中的监听地址重新启动服务之后，外网访问就正常了。

所以当你访问失败时，别忘了登录服务器检查两件事。第一，服务进程是否存在，用ps命令看一下。第二，服务监听的地址和端口是否正确，用netstat或者ss命令确认一下。

第五类，域名解析出了问题。

很多人访问云服务器上的网站是通过域名而不是直接敲IP地址。如果你的域名解析配置错了，或者域名过期了，或者DNS缓存有问题，都会导致访问失败。具体表现就是浏览器里输入域名打不开，但是直接输入云服务器的公网IP地址却能打开。这个现象基本就能判断是域名解析的问题。

有一个做电商的朋友，他的店铺突然打不开了，客户纷纷投诉。他用IP地址访问是正常的，但域名就是不行。我让他检查一下域名的DNS解析记录，他去域名注册商那里一看，域名解析的A记录指向的IP地址是一个旧的IP，而他前两天刚刚迁移了云服务器，换了新的公网IP，忘记去更新域名解析了。问题找到之后，他赶紧把A记录改成新IP，然后等待解析生效。几个小时后，域名访问恢复正常。不过这里也要注意，DNS解析的生效时间不是即时的，短的几分钟，长的可能需要二十四小时。所以迁移服务器的时候，最好先降低DNS记录的TTL值，等迁移完成并确认生效后再改回来。

另外还有一个常见的情况，就是你本地的DNS缓存没有更新。即使域名解析已经改过来了，你的电脑可能还记着旧的IP地址。这时候可以在命令行里执行清除DNS缓存的命令，Windows上是ipconfig /flushdns，Mac和Linux上也有相应的命令，清理之后重新访问就好了。

第六类，云服务器资源耗尽导致服务无响应。

有时候安全组、防火墙、服务、域名都没问题，可访问就是时断时续，或者极其缓慢，甚至完全没反应。这种情况往往是云服务器的资源被耗尽了。比如CPU长时间跑满，或者内存被用光导致系统开始杀进程，又或者磁盘空间满了导致系统无法写入日志甚至无法正常响应请求。

一个比较典型的案例是，某个人在云服务器上运行了一个爬虫程序，代码里没有做频率限制，也没有用异步或者多线程的合理控制，结果CPU长时间保持在百分之百。这时候sshd服务还能勉强响应，但非常慢，输入一个命令要等几十秒。而Web服务就更糟了，因为Nginx需要CPU来处理请求，CPU满负荷的情况下，新的请求只能排队，甚至超时。解决办法是先把爬虫程序停掉，然后优化代码逻辑，或者给爬虫程序单独设置CPU使用上限。如果优化后资源还是不够，那就需要考虑升级服务器配置，但这不是唯一的路，很多情况下代码优化就能解决大部分问题。

还有一种情况是磁盘写满了。我曾经处理过一个故障，客户的云服务器网站访问时返回500错误，SSH连接虽然能连上，但执行某些命令时会提示“设备上没有剩余空间”。检查磁盘使用率，发现根分区已经到了百分之一百。原因是日志文件把磁盘塞满了，不仅仅是Web访问日志，还有系统日志、数据库日志等等。处理方法是先临时删除一些大的日志文件，释放出几GB的空间，让服务能恢复运行。然后配置日志轮转，比如使用logrotate工具，让日志定期压缩、归档和删除。这样就不会再出现磁盘写满的问题了。

第七类，云服务器公网IP被限制或者被封锁。

这种情况比较特殊，但也不少见。如果你的云服务器被攻击了，或者发出了异常的流量，云服务商可能会暂时封锁你的公网IP，或者将你的实例隔离。还有一种可能是你服务器的IP被某些地区的运营商封掉了，或者被某些防火墙列入黑名单。最典型的例子就是使用某些代理或者VPN工具之后，IP被目标网站屏蔽，但这不是云服务器本身的问题，而是目标网站的限制。

我碰到过一个做外贸网站的朋友，他的客户在欧洲访问他的网站非常慢，有时候甚至打不开。但是他自己在国内访问却很正常。后来他检查了云服务器的监控数据，发现来自欧洲某个国家的请求数量确实很多，但并没有达到攻击级别。最后他用在线工具测试了一下，发现他云服务器的IP被欧洲某个运营商的网络节点做了限速。这种情况自己很难解决，他最后是联系了云服务商，更换了一个公网IP，问题就没有再出现了。

第八类，SSH连接时的密钥、密码或者用户配置问题。

对于经常通过SSH登录云服务器的朋友来说，访问失败常常表现为“Permission denied”或者“Too many authentication failures”。这通常是认证信息出了问题。你可能输入了错误的密码，或者使用了错误的密钥文件，又或者密钥文件的权限不对。在Linux系统中，私钥文件的权限要求非常严格，必须是600或者400，如果你的私钥文件权限是644或者777，SSH客户端会拒绝使用它，认为不安全。

另外还有一个小细节，有些云服务器默认禁止root用户通过SSH密码登录，只允许密钥登录或者只允许普通用户登录后再切换。如果你用root和密码连不上，可以试试用默认的系统用户，比如ubuntu或者centos，然后再用sudo切换。

我曾经帮一个客户重置过SSH访问。他忘记了云服务器的密码，同时密钥文件也丢了。好在他还能通过云控制台的远程管理终端登录进去。进去之后，他修改了sshd_config配置文件中的PasswordAuthentication，把no改成了yes，重启了sshd服务，然后重新设置了密码。这样他就能用密码登录了。等登录进去之后，他又重新生成了密钥对，把公钥添加到authorized_keys文件中，然后把密码登录再次关闭。这个过程虽然麻烦，但是完整地解决了一次访问失败的问题。

第九类，端口被占用或者应用程序崩溃导致端口无法监听。

当你的程序启动后，却无法访问对应的端口，有可能是端口已经被别的进程占用了。这时候你需要找到占用的进程，要么停掉它，要么让你的程序换一个端口。还有一种情况是程序虽然启动了，但运行几秒之后因为某些错误崩溃了，端口也就随之关闭了。这种情况需要查看应用程序的日志来定位崩溃原因。

有一个案例，一个团队在云服务器上部署了一个Java的Spring Boot应用，配置监听8080端口。应用启动后的前几分钟能访问，但过一会儿就访问不了了。他们检查后发现了两个问题。第一个是应用启动脚本里没有加后台运行参数，一旦SSH会话关闭，应用也被结束了。第二个是应用本身存在内存泄漏，运行一段时间后因为堆内存溢出而崩溃。通过修改启动方式，使用nohup或者做成系统服务，并且修复了内存泄漏的代码，问题才彻底解决。

第十类，云服务商底层故障或者机房网络问题。

最后，我们也不能排除云服务商自身的问题。虽然大的云厂商通常有很高的可用性，但偶尔也会出现区域性的网络故障，硬件故障，或者机房电力问题。这种情况你是无法在服务器内部解决的。当以上所有排查都没有结果，而你又看到云服务商的官方状态页面发布了故障公告，那也只能耐心等待他们修复。

我经历过一次某云服务商的某个可用区网络故障，持续了大约四十分钟。期间所有在该可用区的云服务器都无法从外部访问，但是内部的监控数据显示服务器本身运行正常。这种时候你做任何操作都没有意义，因为问题在云服务商的基础设施层面。唯一能做的就是关注故障公告，恢复后立即验证服务是否正常。

说了这么多原因，最后我总结一下遇到云服务器访问失败时的排查思路，希望能帮你形成一个固定的流程，以后再遇到类似问题就不会手忙脚乱了。

第一步，先确认自己本地的网络是否正常，用浏览器随便访问几个常见的网站试试。如果本地网络有问题，解决本地网络。

第二步，如果你是通过域名访问的，试试直接用公网IP访问。如果用IP能通但域名不通，那就是域名解析的问题，去检查DNS记录和本地缓存。

第三步，登录云服务商的控制台，查看实例的运行状态是否正常，有没有被关机、重启或者隔离。同时检查安全组的入站规则，确保你需要的端口和来源IP已经被放行。

第四步，如果你能通过云控制台的远程管理终端登录服务器，那就进去检查系统防火墙规则、服务运行状态、监听地址和端口、CPU内存磁盘等资源使用情况。

第五步，如果所有配置看起来都正确，但就是连不上，可以尝试在本地用telnet或者nc命令测试端口是否开放。比如telnet 你的公网IP 22，如果连不上，说明要么是安全组问题，要么是系统防火墙问题，要么是服务没有监听。

第六步，查看服务器内部的错误日志。SSH连接失败看/var/log/auth.log或者/var/log/secure，Web服务访问失败看Nginx或者Apache的错误日志，应用程序的问题看应用程序自己的日志目录。

第七步，如果以上都查不出问题，而且持续时间较长，可以去看看云服务商的官方状态页面或者社区论坛，看看是不是有普遍性的故障。

云服务器访问失败并不可怕，它就像一个不会说话的伙伴，只是暂时和你失去了联系。每一次排查，每一次找到问题所在，你对云服务器的理解就会更深一层。下次当你看到“无法访问此网站”或者“连接超时”的时候，不妨先深吸一口气，然后按照从外到内的顺序，一步步去检查。相信我，绝大多数问题，你都能自己找到答案并解决它。