Ⅰ 為什麼阿里雲伺服器遠程桌面經常連不上
連不上，大多原因是網路問題。
首先，判斷是不是機房網路問題，可以嘗試訪問其他網站，排除本地線路故障。
其次，針對雲伺服器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