AWS帳號快速辦理 AWS EC2 Windows 實例 RDP 遠端桌面連線逾時？防火牆與網關排查
先分清楚：是逾時，還是登入失敗
很多人一碰到 Windows EC2 連不上遠端桌面，就急著重開機、換密碼、改安全群組，結果折騰半天還是逾時。其實第一步不是修，而是先判斷問題落在哪一層。RDP 逾時通常代表 TCP 3389 根本沒有成功建立連線，常見原因不只是 Windows 防火牆，還可能是安全群組、網路 ACL、路由表、閘道，甚至是你的本地網路把 3389 擋掉了。
如果畫面是輸入帳號密碼後失敗，那是另一種問題；如果是一開始就卡在「正在連線」最後超時，重點就是先查網路路徑。這篇文章就照著實際排查順序來，不繞圈子，從外往內看，先找出哪一層把 3389 擋住。
第一層：先確認實例真的有對外入口
要從網際網路連到 EC2 Windows 實例，前提不是「有一台機器在跑」就夠了，而是它必須真的有可達的公網入口。最常見的誤判就是實例明明開著，卻放在私有子網，或者雖然有 Public IPv4，卻沒有正確的路由通往 Internet Gateway。
檢查三件事
- 實例是否為 running 狀態，且通過兩項狀態檢查。
- 是否有 Public IPv4 或 Elastic IP。
- 所在子網是否能透過路由表連到 Internet Gateway。
AWS帳號快速辦理 這三項只要有一項不成立，RDP 就算在 Windows 內部完全正常，外面也一樣連不上。特別要注意的是，停止再啟動 EC2 之後，若沒有綁定 Elastic IP，原本的公網位址可能已經改變。很多人把舊 IP 存在遠端桌面捷徑裡，結果一直連不到，其實只是打到了過期的位址。
第二層：安全群組不是開了 3389 就沒事
AWS 安全群組是最常被調整，也最常被誤判的地方。它是狀態型防火牆，入站放行後，回程通常不需要另外開規則。但「放行 3389」這句話太簡單，實務上還有好幾個坑。
先看來源 IP 有沒有寫對
很多人為了方便，先把 3389 開給 0.0.0.0/0，之後覺得不安全再收回來，結果改成自己的辦公室 IP 後就忘了 VPN、家用網路、手機熱點的出口 IP 其實不一樣。你人在公司、用的是家裡設定好的規則，當然會逾時。最直接的驗證方式，是從目前真實對外 IP 來測試，不要只看你以為的固定 IP。
如果你的辦公網路會走代理或防火牆，還要確認是否允許出站 TCP 3389。某些企業網路雖然能上網，但把遠端桌面當成高風險流量直接封掉，這時候 AWS 端再怎麼開也沒用。切換到手機熱點往往是最快的測試方式。
安全群組本身也可能掛錯位置
有些人以為自己改的是實例的安全群組，實際上卻改到另一個沒掛上的群組。EC2 可以同時掛多個安全群組，只要其中真正生效的那個沒有放行 3389，一樣逾時。排查時不要只看規則畫面，還要回到實例詳細資訊，確認目前綁定的是哪幾個安全群組。
AWS帳號快速辦理 第三層：網路 ACL 常被忽略，但它會直接切斷連線
如果安全群組像門口警衛，網路 ACL 就像整棟大樓的總閘。它是無狀態的，入站和出站都要各自放行。這也是許多人會卡住的原因：明明 3389 開了，結果 ACL 擋了回程封包，RDP 就會表現成「一直連線中，最後逾時」。
RDP 不只用到 3389
遠端桌面雖然主要使用 3389，但建立連線過程中還會牽涉到回程流量與臨時埠。若你在網路 ACL 裡只放行入站 3389，卻把出站限制得太死，連線仍然會失敗。最穩妥的做法，是先用較寬鬆的規則驗證路徑，確認可以連線後，再慢慢收斂成最小權限。
實務上，排查 NACL 時要同時看子網入站與出站方向，並確認規則順序沒有被更高優先級的拒絕項目攔下。只要碰到自訂 ACL，尤其是從安全模板複製過來的環境，就很容易出現「看起來有開，實際上被前面的 deny 擋掉」這種狀況。
第四層：Windows 內部的防火牆與遠端桌面服務
如果 AWS 端都沒問題，那才輪到 Windows。本機防火牆把 3389 擋掉，是非常常見的原因，尤其是使用自訂映像檔、硬化過的模板，或是公司內部建立的金鑰機器。很多安全基線會預設關閉遠端桌面或限制特定網路類型，導致你在 AWS 控制台看得到執行中，外面卻始終進不去。
先看遠端桌面功能是否真的啟用
Windows 需要先允許遠端桌面連線，系統層的遠端設定若沒打開，服務即使存在也不會接受外部連入。接著要看 Remote Desktop Services 是否正常運作，以及防火牆的入站規則是否允許來自外部的 3389。若系統剛被重整過、套用過群組原則，規則很可能被重寫。
防火牆規則不要只看「已啟用」
遠端桌面相關規則可能只允許某一種網路設定檔，例如私人網路或網域網路。如果實例被判定成公用網路，規則看起來開著，實際上仍然無效。這種情況常發生在剛建立的 Windows 實例上，尤其是網卡設定、DNS、網域識別還沒完成時，系統會把它判成較保守的設定檔。
若你能透過 Systems Manager、串列控制台或其他管理方式進到機器內，先暫時確認防火牆與遠端桌面服務狀態，再逐步恢復規則，通常比盲目重裝省很多時間。若連內部管理通道也沒有，就得回到 AWS 端檢查是不是根本還沒打通網路。
網關與路由：真正讓很多人卡關的地方
RDP 逾時最容易被誤會成防火牆問題，但實際上，真正的斷點常常在閘道與路由。只要子網沒有正確連到 Internet Gateway，或者路由表沒有把預設路由導出去，就算安全群組和 Windows 防火牆全開，外部連線還是進不來。
公有子網要有正確的預設路由
一個能被外網 RDP 的 Windows EC2，通常應該放在公有子網，並且該子網的路由表要有 0.0.0.0/0 指向 Internet Gateway。還要確認這張路由表真的有關聯到目前所在的子網，不是你新增了規則，卻忘了把子網掛過去。這種錯誤非常常見，而且從外部看起來只會像是連線逾時。
另外還要留意網卡與公有 IP 的關係。EC2 的主網卡會綁定公網位址，但如果你把實例搬到別的子網、換了 ENI，或者做了某些網路調整，原本看似正常的對外能力可能已經變了。當你不確定時，直接回到子網、路由表、Internet Gateway 這三個地方逐一確認，不要只憑印象判斷。
AWS帳號快速辦理 私有子網不能直接用網際網路 RDP
這是初學者最容易踩的坑：以為只要實例有 Windows、開了 3389，就能從外面連進去。其實如果實例在私有子網，沒有公網位址，也沒有經過跳板機、VPN 或其他受控入口，外部根本無法直接打進來。NAT Gateway 只能讓內部對外連線，不能接受外部主動連入。這一點一定要分清楚。
如果你的架構本來就是私有子網，正確做法通常是用跳板機、AWS Client VPN、Site-to-Site VPN 或公司內網專線，再從內部去 RDP。這種情境下，逾時不是故障，而是路由設計本來就不允許你直接從公網進去。
一個實用的排查順序
真正排查時，不要東查一下西查一下，最容易把自己搞亂。建議照這個順序走：
- 先換網路測試，確認本地端沒有封鎖 3389。
- 確認實例有正確的 Public IPv4 或 Elastic IP。
- 確認子網是公有子網，路由表有指向 Internet Gateway。
- 確認安全群組入站允許你的來源 IP 連到 3389。
- 確認網路 ACL 沒有擋掉入站或出站流量。
- 最後再看 Windows 防火牆與遠端桌面服務是否正常。
這個順序的好處，是先把最外層、最容易出問題的地方排掉。只要你一開始就跳進 Windows 裡面找原因，常常會花很多時間，因為真問題其實根本不在系統內。
幾個最常見的真實案例
案例一：安全群組放行了 3389，卻放錯來源 IP
這種情況最多。使用者在辦公室改過規則，回家後用另一條網路連線，結果一直逾時。最後只要把目前真實出口 IP 加回安全群組，立刻就通。這時候別懷疑實例，先懷疑你的網路環境。
案例二：實例有公網 IP，但子網路由表沒接 Internet Gateway
表面上看起來一切正常，實例也顯示有 Public IPv4，可是路由表沒有 0.0.0.0/0 指到 IGW，外面就是打不進去。這類問題很迷惑，因為控制台的資訊看起來很多都對，但少了那條關鍵預設路由，整條鏈就斷了。
案例三：Windows 防火牆關閉了遠端桌面規則
這通常發生在做過加固、套用模板，或是有安全團隊統一部署政策的環境。AWS 層都放行了，RDP 還是逾時，最後進系統一看，防火牆把遠端桌面封得死死的。這時只要恢復對應入站規則，問題就解決了。
如果你要快速定位，記住這句話
RDP 逾時不是單一問題，它是「連線路徑上某一層拒絕了你」的結果。排查時要從外到內看：本地網路、AWS 安全群組、網路 ACL、子網路由、Internet Gateway、Windows 防火牆與 RDP 服務。只要按照這個順序，一層一層縮小範圍，通常很快就能找到真正的阻斷點。
最後再提醒一次：如果你是在私有子網，沒有跳板機或 VPN，直接用外部網路連 Windows EC2，本來就不會成功。這不是故障，是架構。把這個前提先釐清，很多看似複雜的 RDP 逾時，其實一下就解開了。
