Azure帳號快速開戶 Azure 開戶防火牆端口開放

前言：我以為我已經開了，結果服務還是「不理我」

Azure 開戶之後，第一個常見的心路歷程大概是：你創建了資源、配好了基本設定，信心滿滿按下部署完成，然後外部用戶端一連串測試……結果就是「連線失敗」。此時你心裡會浮現一個很有畫面感的問句：明明防火牆端口不是我有開嗎？怎麼還是不通？

老實說，這種情況在 Azure 幾乎是「宇宙固定現象」。原因常常不是你忘了開，而是開錯層級、或開了但規則順序/優先權、來源地址、協定、或甚至目標其實不是你以為的那個服務埠。本文就以「Azure 開戶防火牆端口開放」為核心，帶你把整個流程理清楚，讓你開得明確、查得有效、關得安全。

先釐清：你要開的是哪一層防火牆？

Azure 的網路可不是只有一個「防火牆」。你可能會同時遇到多層規則，例如：

• NSG（Network Security Group，網路安全群組）：通常套在子網或 NIC（網卡）。決定哪些流量進出。
• Azure 防火牆（Azure Firewall）：更集中式的出口/入口控制（常見於 Hub/Firewall 架構）。
• 作業系統防火牆（例如 Windows 防火牆或 Linux iptables/ufw）：即便 Azure 放行，主機端還是不會自動允許。
• 應用程式自身的設定：例如 Web 服務監聽的埠、管理介面的綁定 IP、TLS/憑證等。

所以你要先問自己：我到底要讓哪種流量進來？是從公網到 VM？還是只有內部網路？是要開 Web（80/443）還是要開資料庫（例如 1433/5432）？不同需求對應的「開法」也會不一樣。

Azure 開戶後常見需求與對應埠

很多新手看到「端口開放」就想要一個萬用清單，但我得先潑一點冷水：埠可以列，策略卻不能亂來。最好的方式是依用途最小化開放。

1）網站/入口服務（Web）

• Azure帳號快速開戶 HTTP：80
• HTTPS：443

通常你會把 NSG 針對 TCP 80/443 加入入站允許，但來源地址不建議直接放 0.0.0.0/0（除非你就是要全世界都能打，而且你確定你扛得住）。

2）SSH / 管理（VM 管理）

• SSH：22（Linux）
• RDP：3389（Windows）

這類埠建議嚴格限制來源 IP，例如只允許你公司網段或你的跳板機位址。

3）資料庫（高風險，請慎重）

• SQL Server：1433
• MySQL：3306
• PostgreSQL：5432

資料庫不建議直接暴露公網。更好的做法通常是：把 DB 放在私有網路、只允許應用程式子網的流量、或使用 Azure 服務提供的安全連線方式。

4）自訂服務

例如你自己寫的 API、監控代理、或某些第三方工具：請你以「服務實際監聽的埠」為準，而不是以網路上看到的預設埠。

NSG：Azure 最常見的「開端口」工具

若你在 Azure 裡要快速開放端口，NSG 幾乎是新手最常用的選擇。NSG 的概念是：你用規則（Rule）描述「允許/拒絕」哪種方向、協定、埠、來源/目的地址。

入站（Inbound） vs 出站（Outbound）

• Inbound：誰能連到你的資源（例如外部連進 VM 的 443）
• Outbound：你的資源要連到外部（例如 VM 需要連到更新伺服器）

很多人只看了 Inbound，但實際問題是 Outbound 被擋；也有人只加了「允許入站」，結果應用回呼時出站流量卻沒放行，狀況依舊。

優先順序（Priority）別亂填

NSG 規則會依 Priority（優先順序）從小到大比對。如果你有一條「Deny」設定在前面，那即使你後面有「Allow」，也可能照樣被擋。新手最常見的情況是：你新增了一條允許，但資料卻被原本既有的拒絕規則卡死。

來源與目的（Source/Destination）怎麼填

開端口時你會遇到幾個常見設定：

• Source / Destination：例如「Any」、「特定 IP」、「特定子網」。
• Service Tag：例如 AzureLoadBalancer、VirtualNetwork 等（看你服務需求）。

若你要提供公網服務，可能會需要允許來源為 Any，但仍建議搭配其他安全措施（WAF、速率限制、Fail2ban、防火牆規範等）。若是內網服務，就把來源限制在你實際的子網。

一步一步：用 NSG 開放 Azure VM 的埠（示範流程）

以下是一個實務導向的流程描述。你可以把它當成「開端口 checklist」，照做通常就能把問題定位。

步驟 1：確認你的目標是哪個資源

例如你部署了一台 VM：
- 你的 VM 網卡是否真的掛在你想套用 NSG 的那個位置？
- 你是套在子網還是網卡 NIC？

常見狀況是：你以為套在 NIC，結果其實套在子網；或反過來。套錯地方就像你把門鎖安錯房間：你很努力，但不是那個門。

步驟 2：打開「有效安全性規則」（Effective security rules）來看實際結果

Azure Portal 通常可以查某個網卡/子網的有效規則。這一步很重要，因為它能告訴你：最後到底允許還是拒絕。

當你測試不通時，先別急著一直新增規則。先用「有效規則」確認現狀，會省你一小時的頭撞牆時間。

步驟 3：新增 Inbound 規則（Allow）

假設你要開放 HTTPS（443）到 VM：

• 方向：Inbound
• 動作：Allow
• 優先順序：選一個比拒絕規則更高（Priority 更小）
• 協定：TCP
• 來源：建議你填你的 IP 或子網（先別一上來 Any/0.0.0.0/0）
• 目的埠：443
• 目的位址：通常是 Any（或依你的部署調整）

如果是要開多埠，也可以用多條規則，或依管理需求合併（但合併也要清楚，不要為了省一點設定而讓日後維運變地獄）。

步驟 4：同步檢查 OS 防火牆是否有放行

Azure帳號快速開戶 Azure NSG 只管「網路層進入」。但 VM 上的 Windows Defender Firewall 或 Linux 的防火牆仍可能擋住。

• Windows：確保入站規則允許 TCP 443（或你要的埠）
• Linux：確保防火牆（ufw/iptables）允許該埠與協定

如果 OS 沒放行，你會得到同樣的「連線失敗」，而你又會再懷疑一次 Azure。請記得：兩邊都要過關。

步驟 5：確認應用程式真的是在聽你要的埠

你開了 443，但應用其實聽 8443？或聽的是 127.0.0.1 只允許本機？那外面當然連不上。

檢查方式依應用不同而不同，但原則永遠一樣：埠要對、綁定要對。

常見誤區：為什麼你「看起來」有開，還是不能用？

下面是我在現場最常遇到的幾種狀況，你可以對照看看你現在是哪一種。

誤區 1：只開了 Inbound，忘了出站

例如你要讓 VM 去呼叫外部 API，結果可能 Outbound 被 NSG 擋住，導致看起來像是「連外失敗」。

誤區 2：套用位置不對（子網 vs NIC）

NSG 可以套子網或 NIC。你可能改了子網規則，但實際 VM 用的是另一個 NIC 規則在蓋掉。

誤區 3：Priority 搞反

你以為「Allow」在上面就會生效，但其實 Deny 比它優先（Priority 數字較小），所以被拒絕。

誤區 4：來源地址太寬/太窄

來源太寬（Any/0.0.0.0/0）會有安全風險；來源太窄則會導致你自己連不上（常見於你測試用的 IP 跟公司出口 IP 不一致）。

誤區 5：協定填錯（TCP/UDP）

很多服務用 TCP，但你不小心填成 UDP，就會讓測試永遠失敗。

如何做更有效的排查：讓問題不要靠玄學

當你遇到「開了還是不通」，最有效的策略不是一直加規則，而是做系統性排查。

Step A：先用 Azure 的診斷工具看流量路徑

Azure Portal 通常提供「疑難排解連線」（依 UI 可能顯示為 Connection troubleshoot、Network watcher flow logs 或類似功能）。目的就是要確認：流量在哪一層被擋。

Step B：用有效規則確認最後狀態

看「有效安全性規則」會比你憑記憶更可靠。你改了幾次規則後，腦袋會自動把自己騙了。

Step C：同時檢查 NSG 與 OS 防火牆

只看 NSG 會漏掉 OS；只看 OS 會漏掉 NSG。正確做法是兩邊都確認。

Step D：用測試埠與測試協定縮小範圍

如果你要測 443，但也有可能是應用層問題。你可以先測純連線（例如用簡單工具測 TCP 通不通），再測 TLS/HTTP 是否正常。

端口開放的安全原則：別讓「能用」變「好用又好被打」

Azure帳號快速開戶 開端口最容易犯的錯，其實是把安全當成後事。等你上線後才發現被掃描、被爆破、或被撞庫，那就不是工程問題而是生活問題了。

原則 1：最小權限（Least Privilege）

只開必要埠、必要協定、必要來源。能限制 IP 就不要開 Any。

原則 2：寧可用跳板機或 VPN，而非直接暴露管理埠

RDP/SSH 這類埠，除非你真的有成熟的防護策略，否則不建議直接開給全網。

原則 3：管理流量與服務流量分離

例如 Web 對外可以開 443；但管理介面可以走內網或透過 Bastion/跳板。這樣一來，你的攻擊面會小很多。

原則 4：記錄與監控

至少要能看出：最近是誰在連？是正常使用還是掃描？Azure 的監控與 Log 功能要善用，不然你只是在黑暗中摸索。

Azure帳號快速開戶 如果你用 Azure 防火牆（而不是只靠 NSG）

有些架構會在 Hub VNet 使用 Azure Firewall，集中控管。這時候端口開放的概念會從「在每個地方開規則」變成「透過防火牆控制流量」。

你要注意的重點包括：

• Azure Firewall 常見強項在 南北向/東西向流量的集中控管（視架構而定）
• 你仍可能需要 NSG 來控制進入子網/NIC 的允許條件
• 因此你同樣要避免「只看其中一層」造成的誤判

簡單講：有 Azure 防火牆不等於 NSG 可以不管；兩者可以一起出力，也可以一起把你搞混。

給新手的一份「端口開放」快速清單

當你再次遇到「Azure 防火牆端口開放」的需求時，照這份清單走會快很多：

• 確認目標：VM/NIC/子網？還是應用服務？
• 確認方向：Inbound 還是 Outbound？
• 確認埠與協定：TCP/UDP？埠號要準確？
• 確認來源：你測試用的 IP 是否符合規則？
• 設置 NSG Allow 規則，檢查 Priority 與有效規則
• 確認 OS 防火牆放行
• 確認服務監聽在正確埠與正確網卡/介面
• 必要時用連線疑難排解/流量記錄工具定位是哪一層擋住

常見案例：用幾個生活化情境幫你秒懂

案例 1：我開了 3389，但 RDP 還是不進

通常是以下幾種：你開了 NSG 的入站，但 VM 的 Windows 防火牆沒有允許 RDP；或你開的來源是某個 IP，但你其實用的是不同網路出口；或你只是開了某台 VM 的規則，但連線其實打到另一個網卡/另一台。

解法：用有效規則確認 NSG，接著檢查 OS、防火牆規則，再確認你連的目標 IP 是對的。

案例 2：網站開了 443，但瀏覽器說「連線被拒絕」

可能原因是應用程式沒真的在 443 監聽，或只綁在 localhost。NSG 放行只是第一關。

解法：在 VM 上確認服務監聽埠，再用簡單工具測 TCP，再測 HTTP/HTTPS。

案例 3：我能連進來，但 API 回應超慢或失敗

這就比較可能是出站、DNS、或應用依賴的外部服務通訊被擋。你可以先把 NSG Outbound 也檢查一下。

解法：從「請求進來」到「回應出去」拆開看哪一段失敗。

最後的提醒：不要把防火牆當作一次性開關

端口開放不是「開一次就永遠不用管」。隨著需求變更，你可能會調整規則、加新服務、或更換來源 IP。這時候你要能夠回答三個問題：

• 我為什麼開這個埠？服務用途是什麼？
• 目前允許的來源是哪一群人/哪個網段？
• 如果我把它收回，會影響什麼功能？

能回答，代表你不是在做「盲開」。你是在做工程，而且是可維運的工程。

結語：把端口開放變成可控的流程，而不是靠運氣

Azure 開戶後的「防火牆端口開放」看似簡單，其實是網路層、規則層、主機層、應用層四層的共同舞步。你只要記得：先確認是哪一層、再確認允許的規則真的生效、最後再驗證主機與服務本身，你就能把「為什麼還不通」從玄學拉回工程。

願你每次按下測試都不是「連線失敗」，而是「終於通了」——而且通了之後還能放心，因為你開得剛好、關得也剛好。祝你 Azure 上線一路順，端口也順，安全性更順。