Ⅰ 为什么阿里云服务器远程桌面经常连不上
连不上，大多原因是网络问题。
首先，判断是不是机房网络问题，可以尝试访问其他网站，排除本地线路故障。
其次，针对云服务器IP做路由测试，追踪是不是线路路由中间节点问题，进一步确认是否机房线路问题。
最后，大致可以锁定是机房线路问题，需要联系对方技术人员协助解决。
当然，连不上还有2种情况，一种是系统设置问题，由于系统某个软件设置导致或设置了远程端口号都有可能连不上。另一种是本地问题，如果本地做有策略无法使用远程。
希望中电华联的回答能够帮助到你。
Ⅱ 阿里云远程桌面无法连接怎么办
这种情况经常遇到，无法连接没有办法，只能重启服务器。
登陆阿里云账号，进入控制台。
选择实例——选择你服务所在的区域，单击实例后面的管理。
进入管理页面，直接重启阿里云服务器或者停止重新启动。
如果不重启，那么点击更多——连接到终端。
就和连接远程桌面一样，可以通过这里直接连接。不过需要输入管理密码。
END
一直无法连接
无法连接的情况一般是由于服务器端没有开启远程桌面功能，或者是某些优化软件将远程桌面禁用了，开启即可，本经验一win server 2012为例。
打开控制面板——系统和安全——允许远程访问。
勾选允许连接到此计算机。这样就可以连接了。
如果还不可以，那就直接把防火墙关掉再试试。
Ⅲ 阿里云服务器运行中总是无法访问怎么办
延迟高、或者安全组没有添加对应端口，都有可能导致这个问题。
Ⅳ 阿里云海外服务器国际端口不稳定,远程总是连不上
连不上，大多原因是网络问题。
首先，判断是不是机房网络问题，可以尝试访问其他网站，排除本地线路故障。
其次，针对云服务器IP做路由测试，追踪是不是线路路由中间节点问题，进一步确认是否机房线路问题。
最后，大致可以锁定是机房线路问题，需要联系对方技术人员协助解决。
当然，连不上还有2种情况，一种是系统设置问题，由于系统某个软件设置导致或设置了远程端口号都有可能连不上。另一种是本地问题，如果本地做有策略无法使用远程。
Ⅳ 记一次解决阿里云服务器偶尔连接不上的问题（由tcp_tw_recycle参数引发的）
阿里云服务器偶尔连接不上的问题出现在我做了一些TCP优化之后，出现了公司内网偶尔会出现连接不上服务器的问题，但是切换袭冲其他的网络就可以正常连接。
1，登陆服务器查看资源使用top，vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层。
2，本地使用ping服务器外网ip正常返回，无丢包，延迟也正常。
3，登录服务器查看tcp相关数据。
发现在卡顿时有大量tcp syn包被丢弃，数值一直在增长。
在查阅资料并结合实际情况后，发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。
后想起，之前同事为改善time_wait连接数过多问题曾改过该内核参数。
解决办法是，关闭tcp_tw_recycle：
再观察，发现服务已正常，偶尔连接不上的现象消失。
我们先来man一下这两个参数(man tcp)：
cp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）
关于tcp_timestamps详情请见： https://tools.ietf.org/pdf/rfc7323.pdf
开启tcp_tw_recycle会启用tcp time_wait的快速回收，这个参数不建议在NAT环境中启用，它会引起相关问题。
tcp_tw_recycle是依赖tcp_timestamps参数的，在一般网络环境中，可能不会有问题，但是在NAT环境中，问题就来了。比如我遇到的这个情况，办公室的外网地址只有一个，所有人访问后台都会通过路由器做SNAT将内网地址映射为公网IP，由于服务端和客户端都启用了tcp_timestamps，因此TCP头部中增加时间戳信息，而在服务器看来，同一客户端的时间戳必然是线性增长的，但是，由于我的客户端网络环境是NAT，因此每台主机的时间戳都是凳禅卜有差异的，在启用tcp_tw_recycle后，一旦有客户端断开连接，服务器可能就会丢弃那些时间戳较小的客户端的SYN包，这也就导致了网站访问极不稳定。
主机A SIP:P1 (时间戳T0) ---> Server 主机A断开后
主机B SIP:P1 (时枣穗间戳T2) T2 < T0 ---> Server 丢弃
经过此次故障，告诫我们在处理线上问题时，不能盲目修改参数，一定要经过测试，确认无误后，再应用于生产环境。同时，也要加深对相关内核参数的认识和理解。
本文解决灵感来自于 https://blog.51cto.com/hld1992/2285410
https://blog.csdn.net/chengm8/article/details/51668992