AWS企業帳號開戶 AWS EC2遠端連接失敗解決
前言：連線失敗的「罪魁禍首」到底在哪？
AWS EC2連線失敗？別擔心，你不是第一個遇到這種煩惱的人！無論是新手還是資深工程師，都可能被這突如其來的「拒絕連接」嚇一跳。但別慌，AWS的問題通常有跡可循，只要按部就班排查，90%的問題都能快速解決。今天就來帶你拆解常見的五大原因，手把手教你如何找回伺服器控制權。
一、安全組規則設置錯誤
安全組就像是伺服器的保全人員，如果規則設錯，連你自己都進不了門。常見錯誤包括：規則未開放正確埠、來源IP範圍寫錯、協議類型選錯等。
1.1 檢查入站規則
打開AWS控制台，點擊「EC2」>「安全組」，找到對應實例的安全組。點擊「入站規則」標籤，檢查是否存在允許22埠（SSH）或3389埠（RDP）的條目。注意「來源」欄位是否正確，例如若想從家裡連接，應設為「我的IP」或具體公有IP（如123.45.67.89/32）。常見錯誤是將來源設為192.168.x.x（內網IP），導致無法從外網連接。也曾有工程師把埠號寫成「2222」，結果發現實際需要的是22，這種低級錯誤卻經常發生！
1.2 開放正確埠號
不同服務對應不同埠，SSH預設為22/TCP，Windows Remote Desktop則是3389/TCP。檢查規則時，務必確認協議類型（TCP/UDP）和埠範圍。例如，若想開放所有TCP埠，應填寫「0-65535」而非單一埠。曾有人將RDP的埠設為22，結果SSH連接成功卻無法使用RDP，這類細節往往被忽略，導致無謂的排錯時間。
二、密鑰對問題
密鑰對就像房間的鑰匙，丟了或用錯就開不了門。常見問題包括密鑰檔遺失、權限錯誤、或指定錯誤的密鑰。
2.1 密鑰檔是否正確
使用SSH連接時，必須指定正確的私鑰檔案。Linux/macOS用戶執行：ssh -i '/path/to/key.pem' ec2-user@ip-address。若使用Putty，需先用PuttyGen將.pem轉為.ppk格式。注意：密鑰檔名稱不可有空格或特殊字元，曾有使用者將檔案名稱寫成'my key.pem'，導致SSH指令報錯，必須改為'my_key.pem'才能正常讀取。
2.2 權限設定問題
在Unix-like系統中，密鑰檔權限必須設為600。執行命令：chmod 600 key.pem。若權限過高（如644），SSH會拒絕使用並顯示「Permissions for 'key.pem' are too open」。Windows使用者需注意，PuttyGen轉換後的.ppk檔案權限由系統管理，但若權限設定不當，同樣會失敗。建議直接在Putty中配置密鑰，避免手動修改權限。
三、實例狀態異常
實例可能看似運行中，但實際上出現問題。例如系統崩潰、磁碟空間滿、或服務異常。
3.1 檢查實例狀態
在AWS控制台，查看實例的「狀態檢查」欄位。若顯示「無法通過狀態檢查」，代表實例自身出現問題。常見原因包括系統崩潰、磁碟空間滿、或核心崩潰。此時可透過「執行個體設定」>「取得系統日誌」查看詳細錯誤。曾有客戶因磁碟空間耗盡，導致系統無法啟動，日誌中顯示「No space left on device」，清理磁碟後即可恢復。
3.2 系統日誌分析
系統日誌是診斷問題的關鍵。在AWS控制台，進入EC2實例頁面，點擊「執行個體設定」>「取得系統日誌」，可查看實例啟動時的完整日誌。常見錯誤包括：
- 「Kernel panic」：核心崩潰，可能需要重啟或修復系統。
- 「Mount failed for /dev/xvda1」：根目錄磁碟掛載失敗，可能是檔案系統損壞，需進入救援模式修復。
- 「Failed to start SSH service」：SSH服務啟動失敗，檢查配置文件或依賴服務。
曾有客戶因磁碟空間滿，導致日誌中出現「No space left on device」，清理/var/log後即可恢復。建議定期監控磁碟使用率，避免類似問題。
四、網路ACL與VPC設定
很多人容易混淆安全組與網路ACL，其實兩者角色完全不同。安全組是實例層級的防火牆，而網路ACL是子網層級的。安全組僅記錄連接狀態（Stateful），而網路ACL是無狀態的，必須明確設定入站和出站規則。
4.1 網路ACL規則
網路ACL預設允許所有流量，但若手動修改了規則，可能出錯。例如，入站規則允許22/TCP，但出站規則卻拒絕所有流量，導致SSH連接建立後無法傳輸資料。檢查時需注意：每條規則都有序號，較低序號優先。若序號100設為拒絕，序號200設為允許，則拒絕優先，導致流量被擋。曾有案例是網路ACL的出站規則設為「拒絕所有」，導致SSH連接建立後無法傳輸資料，出現連線超時，這類問題往往被忽略。
4.2 子網與路由表
實例所在的子網必須有正確的路由。例如，公有子網需要路由表中包含指向Internet Gateway（igw-xxxx）的路由，目標0.0.0.0/0。若路由表缺失該路由，實例無法訪問外網。進入VPC控制台，查看子網的「路由表」，確認是否存在正確路由。曾有工程師將子網誤關聯到私有子網的路由表，導致實例無法連接外網，只需調整路由表即可解決。另外，若使用NAT Gateway，需確認路由指向正確的NAT實例。
五、系統防火牆與服務狀態
即使AWS安全組開放，實例內部的防火牆仍可能攔截連線。
5.1 檢查本地防火牆
AWS企業帳號開戶 Linux系統的防火牆設定常被忽略。以Ubuntu為例，若使用ufw防火牆，執行：
sudo ufw status verbose
若22埠未允許，執行：
sudo ufw allow 22/tcp
sudo ufw enable
對於CentOS 7+，firewalld的設定如下：
sudo firewall-cmd --list-all | grep ssh
若未顯示，則：
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload
曾有使用者在系統更新後，防火牆規則被重置，導致SSH服務被攔截，只需重設規則即可恢復。建議將防火牆規則寫入腳本，避免重啟後失效。
5.2 SSH服務是否運行
確認SSH服務是否啟動：
systemctl status sshd # CentOS/RHEL
systemctl status ssh # Ubuntu
若服務停止，啟動：systemctl start sshd。若服務啟動但仍無法連接，檢查配置文件：/etc/ssh/sshd_config，確認Port設為22，且PermitRootLogin是否允許。曾有客戶修改配置文件後重啟服務，但忘記註釋掉「Port 2222」，導致服務監聽錯誤埠，連接失敗。
結語：穩扎穩打，問題迎刃而解
AWS EC2連線失敗看似頭痛，但只要按步驟排查，幾乎都能解決。建議從最基礎的安全組和密鑰開始，逐步檢查實例狀態、網路設定和系統服務。若遇到複雜問題，AWS官方文件或技術支援都能提供專業協助。下次遇到連線問題，別慌張，拿出這份指南，一步步來，你也能成為解決問題的高手！畢竟，雲端服務的挑戰，就是這樣一關一關攻克的。
