阿里雲帳號充值優惠 阿里雲安全組配置教學

前言：安全組不是魔法，是保全系統

很多人在阿里雲上部署服務時，第一反應通常是：「網路怎麼怪怪的？為什麼我放行了還是連不上？」然後開始懷疑人生、懷疑人生的電腦、甚至懷疑宇宙是不是也封了端口。

其實大多數問題都跟一件事有關：你可能理解的是「安全組像防火牆」，但你實際操作時遇到的是「安全組怎麼評估規則、怎麼綁定資源、怎麼寫 CIDR、怎麼看日誌」。安全組不是魔法，它比較像一個很認真的保全：來訪者要先符合門禁規則，否則就算你喊破喉嚨也進不去。

下面我用比較完整、好讀、而且盡量避免踩雷的方式，手把手帶你完成 阿里雲安全組配置教學。你看完應該能：建立安全組、加入入站/出站規則、綁定ECS、驗證連線、以及在出錯時快速定位原因。

先搞懂安全組是什麼：入站、出站、以及「默認」

安全組（Security Group）是一套套用在雲端網路資源上的訪問控制規則。重點是：它控制的是網路流量，尤其是你 ECS（或其他支持安全組的資源）在收到/發出流量時，是否符合規則條件。

入站規則：別人要打進來，你要不要放行

阿里雲帳號充值優惠 入站（Ingress）規則是外部流量進到你的實例時，是否被允許。常見例子：放行 22（SSH）、80（HTTP）、443（HTTPS）、或 3389（RDP）。

出站規則：你要出去，你要不要放行

出站（Egress）規則是你的實例對外發起連線時，是否被允許。很多人只管入站，卻忽略出站，最後發現「我能連進來，但更新套件失敗」、「連外 API 連不到」。

默認策略：你以為已經放行，其實沒有

在實務上，安全組常見的策略是：未匹配到允許規則的流量會被拒絕。也就是說，你不能只想像「我好像應該算放行了」。你需要確認規則條件（協議、端口範圍、來源/目的 CIDR）真的匹配上。

教學前準備：你要知道的三件事

在開始操作安全組之前，先做三個小功課，成功率會高很多。

1）你的服務用哪些端口？

例如：

• SSH：22
• HTTP：80
• HTTPS：443
• 自訂 API：例如 8080、3000、5000
• 資料庫（不建議暴露到公網）：例如 MySQL 3306、PostgreSQL 5432、Redis 6379

如果你不知道端口，先用你的程式或容器設定確認。別猜，猜會浪費你一整個下午。

2）你的來源是誰？

來源（Source）可以是特定 IP（例如你自己的辦公室/家裡 IP），也可以是網段（CIDR，例如 203.0.113.0/24）。

你如果把來源寫成 0.0.0.0/0，代表「全世界都可以打你端口」。有些情況可以用（例如 80/443），但不是每個服務都該這樣放行。

3）你的目標是哪些資源？

安全組要綁定到你的 ECS/ENI（或支持的網路接口）。你可能已經配好規則，但如果沒有正確綁定到目標實例，那就會出現「怎麼永遠連不上」的經典劇情。

開始配置：建立安全組

下面是典型流程（實際 UI 可能會因介面更新略有不同，但邏輯一致）。

步驟 1：進入安全組管理頁面

登入阿里雲控制台，找到「VPC」或「網路與安全」相關選單，進到「安全組」。通常會有「建立安全組」或「新增安全組」。

步驟 2：選擇 VPC 與網路

安全組通常需要指定所属 VPC（以及可能的安全域）。你選對 VPC 之後，才談得上綁定。

如果你的 ECS 在 A VPC，你卻在 B VPC 建安全組，那就會變成你很努力，但努力的方向不對。

步驟 3：命名與描述

命名建議包含用途，例如：

• prod-web-https
• dev-ssh-office
• db-private-only

描述可寫你放行的端口與範圍，方便未來你（或你未來的同事）看到就懂，不用再猜。

阿里雲帳號充值優惠 配置入站規則：讓外面能用，但不要讓外面亂用

接下來是最常用的部分：入站規則。

範例 1：放行 SSH（22）只給你的 IP

如果你想從你自己的網路管理伺服器，建議把來源限定成你自己的 IP 或辦公網段。

• 阿里雲帳號充值優惠 協議：TCP
• 端口範圍：22
• 來源：你的 IP（例如 203.0.113.10/32）
• 描述：SSH only for office/home

為什麼要這樣？因為把 22 對全世界開放，會讓機器每天收到一堆「友善的攻擊」。它們未必都成功，但你會得到一堆日誌和偶爾的壓力。

範例 2：放行 HTTP（80）與 HTTPS（443）給公網

如果你要讓網站對外服務，通常需要放行：

• 阿里雲帳號充值優惠 TCP 80：來源 0.0.0.0/0
• TCP 443：來源 0.0.0.0/0

但請注意：就算放行了 80/443，你也要確保你的 Web 服務（Nginx/Apache/容器）真的在監聽這些端口。很多「安全組開了，但連不上」其實是你服務沒啟動或綁錯 IP。

範例 3：只放行應用端口（例如 8080）給特定來源

假設你有一個內部測試服務在 8080，但不打算讓全世界連：

• TCP 8080
• 來源：你的測試機網段或公司出口 IP

記得：能限制就限制，安全組永遠比較希望你把門鎖得緊一點。

配置出站規則：別讓程式卡在「連外失敗」

出站規則很多人乾脆預設不動，但這在某些情境可能會讓你突然遇到「奇怪的網路問題」。

常見需求：讓 ECS 能下載更新、連外 API

一般情況你會需要允許：

• TCP 443（連 HTTPS）
• 以及必要時的 80（HTTP）
• DNS（通常是 UDP/TCP 53）

如果你做了很嚴格的出站限制，導致 DNS 查不到或 HTTPS 連不到，你會覺得「安全組是不是又壞了」。實際上它只是很盡責地拒絕你。

建議：除非你在做資安強化，否則別太早把出站鎖死

新手階段建議先確保可用，再談強化。你想做的是穩定，而不是一上來就把自己關在外面。

綁定安全組：沒綁就是白開

規則再漂亮，只要沒綁到資源上就等於你把鑰匙配好了，但門根本沒打開。

步驟 1：找到你的 ECS 實例

到 ECS 控制台，選擇你的實例。

步驟 2：管理網路/安全組

通常會有「網路」或「網路介面」相關選項，其中可以管理安全組綁定。

如果你的實例有多個網卡（ENI），你可能需要確保你把安全組綁到正確的那個 ENI 上。

步驟 3：確認綁定成功

綁定後，最好回頭檢查安全組頁面或實例頁面，看是否顯示該安全組已關聯。

驗證連線：用「證據」而不是「感覺」

當你配好安全組後，不要憑直覺以為「應該可以」。你需要驗證。

本地測試（最常用）：telnet、curl、nc

依服務不同：

• 測 22：使用 nc -vz 你的IP 22
• 測 80：curl -I http://你的域名或IP
• 測 443：curl -I https://你的域名或IP

如果你能連到端口但 404/500，那是應用層問題，不是安全組問題。

從雲端內部測：確認服務真的在聽

登入 ECS，在裡面檢查監聽端口：

• Linux：ss -lntp 或 netstat -lntp

你會驚訝於有多少次「安全組放行了」但服務其實只監聽在 127.0.0.1，外部當然連不上。

看日誌：安全組也有「拒絕的證據」

如果控制台提供安全組事件或流量日誌，你可以用來確認是被拒絕還是已放行但其他原因失敗。

排錯很重要的一點：你要知道「它是被拒絕」還是「它自己掛了」。

常見誤區與踩雷點（保證你能遇到至少兩個）

誤區 1：以為規則會依序套用，結果條件沒匹配

安全組通常不是「先來先到」那種完全靠順序，而是基於規則條件是否符合。你要確認協議、端口、來源 CIDR 完全正確。

例如你以為寫了 80，但實際端口填的是 8080；或來源寫成了錯誤網段，流量當然不會命中規則。

誤區 2：CIDR 寫法不正確

最常見的是把單一 IP 寫成了網段或忘了 /32。

例如：

• 你 IP 是 203.0.113.10，請寫：203.0.113.10/32
• 如果你寫：203.0.113.10（少了 /32）可能導致規則不如你想像

另外，注意你到底要允許「整個網段」還是「單一主機」。網段太大也不安全。

誤區 3：忘了同時檢查系統防火牆（例如 UFW / firewalld）

安全組只是雲端網路層的控制。你的 ECS 裡面還可能有 OS 防火牆。如果 OS 防火牆沒放行，那你即使安全組開了也連不上。

所以排錯順序可以是：

• 先看安全組是否允許
• 再看 ECS 服務是否監聽
• 最後看 OS 防火牆

誤區 4：開了安全組，但你的實例實際沒綁對安全組

這個在多人協作環境非常常見。你 A 先配規則，B 又把實例替換或重建，結果安全組綁定變了。

解法很簡單但很容易被忘：每次改完都回去確認綁定狀態。

誤區 5：只放行 TCP，但你的服務其實是 UDP

例如你在跑 DNS、某些即時通訊或自訂 UDP 服務，需要確認協議。TCP/UDP 混淆會讓你以為安全組沒效。

一份「可直接套用」的安全組配置清單

下面給你三套常見情境，你可以照著改來源 CIDR、端口，直接丟到安全組裡。

情境 A：對外網站（HTTP/HTTPS）

• 入站：
• TCP 80：來源 0.0.0.0/0
• TCP 443：來源 0.0.0.0/0
• 入站（管理）：
• TCP 22：來源 你的管理 IP（建議 /32）
• 出站：
• 通常保留較寬（至少允許 HTTPS/DNS），避免服務連外失敗

情境 B：開發測試環境（端口更多，但限制來源）

• 入站：
• TCP 22：你的開發 IP
• TCP 3000/8080/5000（依你的框架）：你的開發網段或測試機 IP
• 必要時 TCP 80/443：如果你要走反代或測試域名
• 出站：
• 至少允許 HTTPS/DNS

情境 C：資料庫不對外（內網訪問）

• 入站：
• TCP 3306/5432/6379：來源限制為應用所在的安全組或內網 CIDR
• 阿里雲帳號充值優惠 不要把資料庫端口（例如 3306、6379）開到 0.0.0.0/0
• 管理 SSH：仍然只給你的 IP

進階小技巧：用安全組做「身份」而不是只靠 CIDR

如果你的阿里雲安全組支援用「安全組作為來源」的方式（也就是讓某個安全組的成員可以存取另一個安全組），這會比單純寫 CIDR更乾淨。

概念是：你把「誰可以連誰」用安全組關係表示，當實例擴容或替換時，你不需要重寫一堆 CIDR。當然，具體能力以你帳戶、產品版本與 VPC 配置為準。

排錯流程：當你還是連不上時，照這順序做

阿里雲帳號充值優惠 以下是一個很實用的排錯順序，讓你少走冤枉路。

第一步：確認你要連的端口與協議正確

例如你用 HTTP 測 443 或用 HTTPS 測 80，會出現各種奇怪回應。至少先確認端口。

第二步：確認安全組有放行該端口與來源

看規則：

• 入站協議：TCP/UDP？
• 端口範圍：對嗎？
• 來源 CIDR：你的來源 IP 是否包含在內？

阿里雲帳號充值優惠 第三步：確認安全組已綁定到你的實例（或正確 ENI）

很多問題卡在這一步。你可能改的是 A 安全組，實例用的是 B 安全組。

第四步：在 ECS 內檢查服務監聽

服務是否啟動？是否監聽在 0.0.0.0 還是只有 127.0.0.1？

第五步：檢查 OS 防火牆與應用綁定

例如 firewalld/UFW、iptables、容器網路設定等。你以為你在調雲端，其實在調伺服器裡的門鎖。

第六步：看日誌/事件（如果有）

用日誌確認是否被安全組拒絕，還是流量已進去但在別處失敗。

常見問題 Q&A：我把你最可能問的先回答

Q1：安全組開了就一定能連嗎？

不一定。安全組只是雲端層面，還要看 ECS 服務是否啟動與監聽、OS 防火牆是否放行、以及路由或 NACL 等其他網路因素。

Q2：能不能開 0.0.0.0/0？

能，但要看服務類型。Web 的 80/443 通常相對常見；SSH 與資料庫端口通常不建議暴露到全世界。資安不是口號，是你少挨幾次掃描的理由。

Q3：為什麼我用自己的 IP 還是連不上？

可能原因：你的實際來源 IP 不是你以為的那個（例如家裡網路變動、行動網路出口變了）；或 CIDR 寫錯；或你測的不是同一個實例/同一個區域的安全組。

Q4：我改了安全組要多久生效？

通常是即時或很快，但仍建議你改完後立刻重新測試。若仍不通，回到排錯流程檢查綁定與服務監聽。

結語：把安全組當成「可控的門禁」就會越配越順

阿里雲安全組配置教學的核心其實就一句話：你要明確知道「誰要來、來什麼、走哪個協議/端口、要從哪個來源來」，然後把規則精準填進去，再確保安全組正確綁定到你的資源。

別急著一開始就把所有端口開給全世界，因為你想快速上線，安全組也想快速拒絕你（它拒絕的是風險，不是你的努力）。

如果你願意，你可以把你目前的場景（例如：你要開網站還是開 SSH、你用的端口、你的來源是什麼網段）貼出來，我也可以幫你把安全組規則整理成一份更貼合你需求的「可直接照抄版本」。祝你配完安全組就能連上，連上就能開心，開心就能專心做產品，而不是專心看日誌。