Azure帳號充值服務 解決 Azure 連接埠不通與安全組配置

第一章：為什麼會出現「連接埠不通」

很多人第一次把服務丟到 Azure 後，遇到的第一個訊號通常很簡單：外部連線逾時、內部連線失敗、或只有部分端口能通。你會以為是「開錯連接埠」，但現實往往更像是一個分層拼圖：同一個端口在不同層都有各自的允許或拒絕條件。只要任一層不放行，結果就會變成「不通」。

Azure 服務的常見路徑包含公網入口（Public IP）、負載平衡或閘道、虛擬網路（VNet）、子網、網路安全群組（NSG）、以及可能的 Azure 防火牆或第三方防火牆；此外還有 OS 層的防火牆與應用程式本身是否真正監聽在該連接埠。你要解決的不是單純的「開/關」，而是把整條路徑上每個「門」都對齊。

本文目標是讓你能用一套邏輯把問題收斂到最小範圍：先排除「服務根本沒在聽」的可能，再確認「路由與目的」是否正確，接著把焦點放在 NSG、安全組（NSG）規則與方向性（inbound/outbound）。最後我會提供一份可複用的檢查清單，讓你下次部署時少走彎路。

第二章：先搞清楚你在問哪一種「不通」

Azure帳號充值服務 在動手改 NSG 之前，先回答三個問題：你要測的是哪個來源、哪個目的、哪個協定（TCP/UDP）？連接失敗的「表現」也能給線索：是立即拒絕（connection refused）還是長時間逾時（timeout）。這兩種通常對應不同原因。

2.1 連線逾時 vs 立即拒絕

如果你看到的是「逾時」，在網路層多半代表封包被丟掉或沒打到目的端（例如被 NSG deny、被上游防火牆阻擋、或路由不通）。如果是「立即拒絕」，代表封包其實到了主機，但主機上沒有服務在該端口或 OS 防火牆拒絕（視情況）。當然，這不是絕對，但很常見。

2.2 來源與目的要精準到可驗證

請確認你是在從「哪裡」測。例如：你從公司網段連到 VM 的公網 IP，還是從同一個 VNet 的內部機器測？如果你用的是跳板或 VPN，來源 IP 可能不是你以為的那個地址。NSG 規則通常是依來源/目的 IP 或網路標籤來匹配的，一旦來源 IP 不符合 allow 規則，就會直接被拒。

目的也要確認：你以為打的是 443，其實服務其實只在 8443；或你以為打到 VM，但實際上流量應該先到負載平衡器、再轉發到後端。理解路徑，能避免你在「錯的地方」設定正確但無效的規則。

2.3 協定與連接狀態

NSG 允許與否針對的是協定與埠。例如 TCP 端口 22/3389 與 UDP 端口 53 是不同的規則。測試時也要用正確工具：HTTP 用 curl，SSH 用 ssh，DNS 用 dig；不要只用「能不能開網頁」來推斷其他端口狀態。

第三章：最小假設排查法（先服務、再網路）

好的排查方法是讓你每一步都能排除一大類可能性。建議採用「由內向外」的順序：先確定目的端服務與 OS 層，再確定網路層（NSG/路由），最後才看更上層的安全設備或應用限制。

3.1 先確認應用程式真的有在聽

登入 VM（或部署的目的端）後，先檢查該服務是否在監聽：Linux 可以用 ss -lntp 或 netstat -lntp；Windows 可以用對應的網路檢查工具或 PowerShell 查詢。你要確認的不只是「服務啟動」，而是它真的綁定到正確的 IP 與端口。

常見坑是：服務只綁在 127.0.0.1（本機回環），導致外部連線永遠不通；或服務只綁在內部 IP，但你拿公網去打；又或者服務使用了另一個端口但你以為是原設定。

3.2 檢查 OS 防火牆與本機服務策略

即使 NSG 放行，OS 防火牆仍可能阻擋。Azure VM 預設可能未開放某些入站；或你用過自訂映像，裡面的防火牆規則跟你以為的不一致。

如果你能從同一台 VM 本機測到，但外部不通，通常不是 OS 服務問題，而是網路路徑或 NSG。若連本機也打不通，則先把應用層解決。

3.3 再檢查「路由」與「目的是否在同一條路」

NSG 是控制「誰能不能進來」，但路由決定「封包走不走得過來」。如果你的子網使用了自訂路由（UDR），或有網路虛擬設備（NVA）在路徑上，可能需要額外設定下一跳或防火牆策略。最終會出現：你在 NSG 開了 allow，但封包根本沒到目的子網。

因此你要理解你目標 VM 所在子網的路由：是否指向某個防火牆設備？如果是，允許規則要同時在防火牆端生效，而不是只改 NSG。

第四章：NSG、安全組配置的核心邏輯

Azure帳號充值服務 NSG 的規則看似直覺，實際上最容易踩坑的在於方向性、優先序（priority）與規則覆蓋順序。要「解決連接埠不通」，你通常要做到：規則存在、匹配條件正確、優先序足夠低（數值小優先）、且方向正確。

4.1 入站（Inbound）與出站（Outbound）不是同一回事

你可能只在 Inbound 開了端口，卻忽略 Outbound。對許多服務來說，回程（return traffic）會依賴狀態偵測（stateful）。Azure 的 NSG 是 stateful 的：若允許了入站，回程通常會自動允許回應。不過這並不代表你可以完全忽略 Outbound，尤其當你使用了非預期的協定流程、或服務建立連線到不同目的端（例如反向回連、主動連線到第三方），Outbound 就可能成為瓶頸。

更重要的是，如果你是從特定 IP/端點進行測試，Outbound 規則也會影響連線建立階段（例如你用的是某種握手流程或需要 DNS 解析）。因此在排查時，至少要確保 Inbound 與必要的 Outbound 都符合預期。

4.2 優先順序（priority）決定命中哪條規則

NSG 規則是依 priority 從小到大比對。若有多條規則符合封包條件，最小 priority 的那條會先命中。許多人把「允許」加在比較大的 priority，結果卻永遠被前面較小 priority 的 deny 規則擋住。

另一個常見情境是：你以為你在子網 NSG 設了 allow，但其實網卡（NIC）上也綁了另一份 NSG，兩份加總後仍以「拒絕」結果為主。你必須知道 NSG 可能被套在不同層：子網層與網卡層都可能存在。

因此排查時的最佳策略是：暫時在目標 NSG 上建立一條清楚的 allow 規則，且 priority 設得非常靠前（數值小），確認封包能進來。若仍不行，就代表問題可能不在 NSG，而在路由、OS 防火牆或其他安全設備。

4.3 來源/目的與服務標籤（service tag）的匹配

NSG 規則可用來源/目的 IP 或服務標籤。服務標籤（例如 AzureLoadBalancer、AzureCloud 等）可以簡化設定，但前提是你使用的場景確實符合標籤定義。若你把來源寫成錯的 CIDR 範圍，或把「測試用來源」當作另一個網段，規則就不會命中。

此外，destination（目的）要跟你打的目標一致。例如你打的是公網 IP，但規則目的設在內網 IP 範圍；雖然在很多情況下 Azure 會映射，但你仍可能遇到匹配不一致。排查時，建議先用較寬條件（允許特定埠 + 來源為你的測試機 IP）來快速驗證方向。

4.4 預設規則與隱性拒絕

許多 NSG 會有預設 allow/deny。即便你「新增了一條 allow」，也要確認沒有其他較高優先序的 deny 仍在攔截。例如預設可能允許來自特定來源，但你的測試來源不在那個範圍內；你以為 allow 一定會生效，結果卻是被先前規則拒絕。

一個實務技巧是：在排查階段，先把方向、協定、埠完全對齊後，讓 allow 規則優先命中。驗證成功後，再逐步收斂到最安全的來源範圍，而不是一開始就把條件寫得過於複雜。

第五章：把問題定位到具體規則（搭配連線測試）

你改了 NSG，但不知道究竟是哪條規則在起作用。這時候最有效的是「觀測」。Azure 提供多種觀測手段：連線記錄、NSG 流量記錄、或透過診斷日誌。不同訂閱/資源可能開啟方式不同，但核心思想一致：讓你看得到封包是否命中預期規則。

5.1 用連線測試縮小範圍

從測試主機連到目標端口時，建議依序做：

• 測 TCP：用對應工具直接連到端口（例如 telnet/PowerShell Test-NetConnection、或 curl 換成非 HTTP 的端口測試）。
• 測 UDP：用對應工具（例如 dig 對 DNS 53）。
• 測內外：若能從內部子網連通，卻外部不通，NSG 可能在公網入口或負載平衡層；反之則多半在內部子網或 NIC NSG。

你要做的是建立「可重現」的測試步驟，並在每次修改規則後立刻重測。這樣你不需要猜。

5.2 檢查是否同時套用在子網與網卡

當你說「安全組配置」時，常見是兩個層級都存在 NSG：子網 NSG 控制子網入站/出站，NIC NSG 控制網卡。兩者都生效，最終仍可能被其中一層 deny。排查時請先列出目標 VM 的 NIC 所套用 NSG、以及它所在子網所套用 NSG，逐一檢視規則。

一個迅速定位的方法是：在預期應允許的那份 NSG 上建立最高優先的 allow 規則（較低 priority），其他 NSG 先保持原樣。若仍不通，就很可能是其他層（或路由/防火牆）在擋。

5.3 將規則對齊到「協定 + 埠 + 方向」

許多事故其實是「規則寫對一半」。例如你開了 TCP 80，但實際服務是 TCP 443；你以為用的是 inbound，但應用需要從外部回連到特定埠；或你開了 port 3389，但實際要的是 22。當你面對多個端口時，先逐一測試，確保你每次改的規則都對應測到的端口。

第六章：實際修復流程（從零到可用）

下面是一個實務修復流程，你可以把它當作部署時的 SOP。假設情境是：你希望外部能連到 VM 的某個服務端口（例如 SSH 22 或 Web 443），但目前連不上。

6.1 建立測試基準（在改動前就先記錄）

Azure帳號充值服務 在修改任何設定前，先記錄：

• 來源：你的測試機公網 IP（或 VPN 出口 IP）。
• 目的：VM 的公網 IP（或負載平衡器 IP）。
• Azure帳號充值服務 協定與端口：TCP 22、TCP 443 等。
• 現象：逾時或拒絕。

記錄這些是為了避免你後續改錯方向仍繼續「追新問題」。

6.2 確保服務端真的在聽（跨跳檢查）

登入 VM，確認該服務監聽狀態與綁定 IP。若服務不在聽，就算 NSG 開放也沒有意義。

同時檢查 OS 防火牆是否放行該端口。你可以先用本機測試（例如本機 curl 或本機 ssh）確認應用本身正常。

6.3 在 NIC NSG 或子網 NSG 先放行「單一條件」

Azure帳號充值服務 接著回到 NSG。選擇你要優先測試的層（通常先 NIC NSG，因為它更精準）。新增一條入站規則：

• 方向：Inbound
• 協定：TCP 或 UDP
• 目的埠：你的目標埠
• 來源：先用你的測試機 IP（最小化條件），必要時可用更寬暫時驗證
• 動作：Allow
• Azure帳號充值服務 優先順序：比既有 deny 規則更靠前

新增後立刻重新測試連線。

6.4 若仍不通，依序往上排除：子網 NSG、路由、防火牆

Azure帳號充值服務 如果你在 NIC NSG 已放行但仍不通，請依序檢查：

• 子網 NSG 是否也有 deny 命中該流量。
• 是否存在 Azure 防火牆或第三方防火牆，並且需要在防火牆規則放行該目的埠與目的目標。
• 是否有自訂路由或 UDR 導致流量走到非預期路徑。
• 是否使用負載平衡器（LB）或應用程式閘道（Application Gateway），需要設定前端規則、後端埠或健全性（health probe）相關設定。

當你遵循這個順序，就不會陷入無限試錯。

6.5 通了之後再收斂成安全版本

驗證成功後，不要立刻把規則維持在寬鬆條件。把來源縮回必要範圍（例如只允許公司 VPN 網段或跳板機 IP），並確保 priority 與其他規則不會造成「遮蔽」問題。

同時，你可以考慮把多埠需求拆成多條清楚規則，而不是用寬範圍的單一規則。清楚可維護的規則能降低未來誤刪或誤放行的風險。

第七章：常見錯誤與對策

很多「連接埠不通」並不是你不努力，而是遇到特定套路的陷阱。下面列出常見錯誤與應對方式。

7.1 把規則寫在錯的層

例如 VM 在子網 A，子網 A 有 NSG1；VM 的 NIC 又有 NSG2。你只改 NSG1，NSG2 卻仍拒絕該流量。對策是先確認套用層級，再做最少必要修改。

7.2 priority 設錯導致 allow 永遠不命中

你新增一條 allow，但它的 priority 比 deny 大，結果封包先命中 deny。對策是把 allow 規則 priority 設到能先命中用於驗證，驗證成功後再調整成符合你的治理標準。

7.3 協定與端口對不起來

你開了 TCP 80，但服務實際使用 TCP 8080；或你開了 UDP 53，但測的是 TCP 53。對策是把「測試」與「配置」一一對齊，逐端口驗證。

7.4 以為 NSG 是唯一的安全控制

若你啟用了 Azure 防火牆或 NVA，NSG 放行也可能仍不通。對策是把路徑上的安全裝置逐一確認。

7.5 忽略回程或 DNS 解析需求

雖然 NSG stateful 能處理回程，但應用可能仍需要 outbound 進行 DNS 解析或連到第三方服務。若 Outbound 被限制，可能表面看起來像 inbound 不通，實際是服務無法建立連線。對策是同時檢查必要 outbound。

第八章：安全且可維護的配置清單

當你解決了「不通」，下一步是讓配置能長期維護，並降低未來變更導致的風險。以下是一份你可以直接在團隊中使用的清單。

8.1 規則設計原則

• 最小權限：來源盡量縮小到可驗證的 CIDR 或單一 IP。
• 最少規則：用清楚的多條規則表示不同埠需求，不用大範圍神祕規則。
• 可讀性優先：規則命名/標記（若你的流程允許）清楚描述用途與責任。
• 優先順序治理：把 allow/deny 的 priority 做成規範，避免未來新增規則時遮蔽既有邏輯。

8.2 變更流程（建議）

• 每次只改一個變因：例如只調整 NSG 規則，不要同時改路由與應用。
• 修改後立即測試：用可重現的測試指令與步驟。
• 保留證據：記錄你改了哪條規則（日期、方向、埠、來源範圍、priority）。

8.3 部署後檢查

• 確認服務監聽正確：IP 綁定、端口、協定。
• 確認 OS 防火牆：至少對應目標端口放行。
• 確認 NSG：NIC 與子網都檢查，且方向、priority、來源目的匹配正確。
• 確認上游安全：若有防火牆、閘道或 LB，前端/後端/健康檢查與端口必須一致。

第九章：把排查變成能力，而不是運氣

你以後再遇到「Azure 連接埠不通」，就不必靠直覺猜測。把它當成系統工程：先證明服務層可用，再證明網路層可達，最後才談安全策略。NSG 的配置不是背規則，而是理解匹配與優先序；安全組的效果不是你以為的「單點設定」，而是跨層合併後的結果。

最關鍵的是，你要建立可重現的測試流程。當你能穩定重測，就能把問題定位到具體規則與具體端口，並且在每次修改後快速驗證是否真的前進，而不是在黑盒裡反覆猜。

如果你把本文的流程落地，你會發現：連接埠不通不再是難以解釋的意外，而是可以被拆解、可以被修復、也可以被預防的工程課題。