Azure帳號開戶服務 Azure虛擬機連不上外網怎麼排查

第一章：先別急著改設定，先把現象講清楚

「連不上外網」看似一句話，但實際上可能是幾種完全不同的失敗模式：是完全沒有出站，還是DNS 解析失敗，或是能解析但TCP/443 被擋。在 Azure 上，這些差異會導向不同的排查路徑。

建議你先用兩個測試把問題定性：一個測「名字」，一個測「連線」。例如：

• 測 DNS：用可解析的域名，例如執行 ping 或 nslookup（若系統支援）。
• 測連線：用 IP 或固定域名去測端口，例如測 443（HTTPS）或 80（HTTP）。

如果你的結果顯示：連 IP 不行、連域名也不行，多半是出站路由、NAT、NSG/防火牆或網路路徑問題；若是連 IP 可以、連域名不行，多半是 DNS 設定；若是解析可以但 443 不行，就要回到安全規則或中間設備（例如防火牆、NVA、Web 代理、企業安全政策）。

接下來我會用「從外到內、從網路到主機」的順序帶你排查，確保每一步都能縮小範圍。

第二章：確認虛擬機是「真的在那裡」連網

2.1 檢查網卡與 IP：你要確認它不是靜態錯誤或被綁錯子網

先回到 Azure 入口網站或你使用的資源查詢工具，檢查這幾點：

• 虛擬機所在的VNet與子網是否正確。
• 網卡（NIC）是否正常「啟用」，IP 是否有效（主要/次要 IP 的配置是否正確）。
• 若是靜態 IP，是否存在衝突或被改動過。

很多「看似連不上外網」其實是因為子網選錯或 IP 設定不對，導致根本沒有正確路由。

2.2 檢查 NSG：出站失敗最常見的不是出站規則被擋，是看漏了方向

在 Azure 中，NSG（Network Security Group）的規則方向分為入站（Inbound）與出站（Outbound）。一般使用者直覺會盯著入站，但出站規則被擋同樣常見。

排查方式：

• 到子網或 NIC 對應的 NSG 規則檢查是否有「出站拒絕」針對外部 IP 或 0.0.0.0/0。
• 特別注意是否只允許特定目的地（例如只允許公司內部地址段），導致外網被拒。
• 確認優先順序（數字越小優先級越高）。

如果你看到有一條規則「Allow 到內網但 Deny 到 Internet」且優先級更高，那就是明顯原因。

Azure帳號開戶服務 第三章：路由是關鍵：UDR、虛擬網路閘道與 NVA 都可能把你導到錯的地方

3.1 檢查 Effective Route：你的封包到底要走哪條路

在 Azure 里最重要也最實用的工具之一是「有效路由（Effective route）」檢視。因為你可能以為自己沒加路由，但實際上有 UDR、服務端要求或 NVA 影響了路徑。

請針對虛擬機所在子網或網卡查看：

• 目的地 0.0.0.0/0 的下一跳是什麼。
• 是否指向你預期的設備（例如 NAT Gateway 或防火牆/NVA）。
• 是否被指到不存在或沒有回程的下一跳。

如果「0.0.0.0/0」的下一跳出現了奇怪的結果，比如指到你沒有部署的 NVA，或 next hop 類型不符合預期，那通常就是出站失敗的根因。

3.2 NAT Gateway 或防火牆缺失：能到內網不代表能出外網

Azure 的出站連線常依賴 NAT（NAT Gateway 或透過防火牆/NVA 做轉譯）。如果你的子網沒有正確的出站裝置，虛擬機可能只在私網內互通，對外則因缺少公網路徑或缺少可回應的來源地址而失敗。

常見情境：

• 你使用了私有子網（Private Subnet），但沒有為它配置 NAT Gateway 或防火牆。
• 你把 UDR 指向防火牆，但防火牆沒有允許從該子網出去的流量，或回程規則沒有設好。
• 你以為系統有直接上網，但實際上出站需要經過中間設備。

這時候你要回到架構：你希望流量如何「出網」？是直接上 Internet，還是走 Azure NAT，或走第三方/自建防火牆？不同架構對應不同排查點。

第四章：DNS 是第二大兇手：連不上外網不一定是路由問題

4.1 先區分：DNS 失敗還是 TCP 失敗

如果你執行 nslookup/查詢時域名解析失敗，或返回超時，你可能把「連不上外網」誤認成「無法連 TCP」。很多環境 DNS 被關掉、DNS 轉發沒設、或 NSG 擋了 UDP 53/ TCP 53。

排查要點：

• 虛擬機上目前的 DNS 伺服器是什麼（可查看 /etc/resolv.conf、或 Windows 的網路設定）。
• 子網是否配置了自訂 DNS（Custom DNS settings）或透過 DHCP 給了特定 DNS。
• DNS 伺服器本身是否可達（你可以直接測 DNS 伺服器 IP 的連線或 ping，視環境而定）。

4.2 若 DNS 伺服器不可達：檢查 NSG、路由、以及 DNS 轉發策略

DNS 往往不是「只有主機內設定」就好。若你有 UDR 或防火牆策略，DNS 解析可能需要允許：

• 到 DNS 伺服器的出站（通常是 UDP/TCP 53）。
• Azure帳號開戶服務 回應路由正確（尤其是走防火牆/NVA 的環境）。

常見錯誤是：允許了 HTTP/HTTPS 出站，卻忘記允許 DNS 出站，導致域名永遠解析不到。

第五章：客戶端層級也要查：OS 防火牆、代理與安全軟體

5.1 檢查 OS 防火牆（Windows Defender Firewall / Linux iptables/nftables）

就算 Azure 網路完全正確，主機防火牆仍可能把出站攔掉。排查思路是：

• 確認是否開啟了針對出站的封鎖規則。
• 若有公司安全軟體或 EDR，確認它是否對特定網站或類別做阻擋。

在 Linux 上，nftables/iptables 可能有出站鏈或特定策略；在 Windows 上，Windows Firewall 也可能有「程式」或「規則」級別的出站限制。重點不是猜，而是看規則本身與事件日誌。

5.2 代理設定：你以為在連網，實際上被送去代理或代理失效

很多環境要求透過 HTTP/HTTPS 代理上網。如果代理地址設定錯了，或代理需要憑證但沒提供，你會看到「連外網失敗」但其實是應用層的問題。

排查建議：

• 確認系統層級的 proxy 設定（環境變數、WinINET 設定）。
• 若只是在瀏覽器失敗，但 curl/wget 成功，或反過來，這通常指向「應用設定」差異。
• 測試時儘量用裸連線（例如 curl 直接指定 URL 或測特定端口），避免應用端參數干擾判斷。

第六章：用可觀測的指標定位：Ping、DNS、Tracert、路由表、封包流向

6.1 基礎命令的使用目的：每個測試都回答一個問題

你可以把測試當成「問答題」。例如：

• Ping IP：回答「是否有基礎出站到 Internet 的路徑」。
• nslookup 域名：回答「DNS 是否能用」。
• curl/wget 連 URL（最好指定端口）：回答「TCP/SSL 是否被擋」以及「是否走對路徑」。
• traceroute/tracert：回答「封包在哪一跳開始失敗」。

注意：ICMP ping 在很多安全環境會被封鎖，因此「ping 不通」不等於「完全不能上網」。更可靠的是測 HTTP/HTTPS 連線。

6.2 觀察路由表：你要看「主機看到的路由」

除了 Azure 平台的 Effective Route，也要確認主機自己的路由表是否合理。你可能會遇到：

• 主機路由指向錯誤網關（例如 DHCP 獲得的預設閘道不對）。
• 主機新增了錯誤的靜態路由。
• 多網卡或政策路由導致出站走錯介面。

簡單說：Azure 控制面決定「網路如何轉發」，主機路由決定「封包送到哪個介面」。兩者都要符合你的目標。

第七章：典型案例拆解（你可以對照自己的狀況）

7.1 案例一：只能解析內部域名，外部域名解析失敗

常見原因：DNS 設定只指向內網 DNS，沒有對外轉發；或 NSG 擋了到 DNS 的出站；或 UDR 把 DNS 流量送到沒有允許的防火牆。

解法方向：

• 檢查虛擬機 DNS 伺服器設定。
• 確認到 DNS 的 UDP/TCP 53 出站被允許。
• 若 DNS 由內部伺服器負責轉發，確認內部 DNS 能解析外部並且回應到虛擬機。

7.2 案例二：解析沒問題，但 443 打不出去

Azure帳號開戶服務 解析成功代表 DNS 路徑大致通了。這時候 443 失敗，多半是：

• NSG 出站規則未允許到 Internet 的 443。
• Azure帳號開戶服務 防火牆/NVA 有針對目的地或分類阻擋。
• 代理要求憑證，你在測試工具沒有帶上憑證。

解法方向：

• 用 curl 指定 443 測試，並觀察錯誤型態（超時、連線拒絕、TLS 錯誤）。
• 查 NSG/防火牆的規則是否包含到外網的 443 流量。
• 若走代理，先排除代理設定導致的失敗。

7.3 案例三：什麼都連不上（IP/域名都不行）

這通常是路由或 NAT/防火牆缺失。

Azure帳號開戶服務 最常見：

• 子網沒有 NAT Gateway，也沒有防火牆/NVA 提供出站轉譯。
• UDR 把預設路由導到錯的下一跳。
• NSG 對出站 0.0.0.0/0 有拒絕規則或缺少允許規則。

解法方向：

• 先看 Effective Route：0.0.0.0/0 下一跳是什麼。
• 確認 NAT Gateway 或防火牆實際在線且有回程。
• 檢查 NSG 出站規則（尤其是 priority）。

第八章：高階排查：NVA/防火牆回程、SNAT、以及非預期的目的地

8.1 回程路由不完整：你出得去，但回不來

在企業網路或自建防火牆場景中，常見情況是：虛擬機封包確實被送到防火牆，但防火牆不知道如何回覆（或沒有完成 SNAT），導致你看到的是連線超時。

這類問題通常不是「簡單放行」就好，而是要確認：

• 防火牆/路由設備做了正確的轉譯（例如 SNAT/DNAT）。
• 防火牆返回的來源地址與路由策略一致。
• UDR 與防火牆的路由同步一致。

8.2 檢查目的地：有些「外網」其實被你指到內部特殊網段

有時候你的測試目標其實是某個特殊網段（例如特定雲服務的私有端點、或你公司的安全策略把某些流量導向內部）。

排查方法是把測試目標固定、可重現，並且記錄：

• 測試用的域名與對應解析到的 IP。
• 實際連線嘗試的目的端口。
• 是否有代理或應用層重導流量。

你會驚訝於多少「外網連不上」其實是測試目標沒有按預期到 Internet。

第九章：把排查做成流程：一套可重複的檢查清單

下面提供一個你可以照著走、每一步都有判斷依據的流程。你不必每次都做完所有步驟，但至少要能「排除」而不是「憑感覺改」：

1. Azure帳號開戶服務 定性問題：連 IP？解析域名？443？80？錯誤型態是超時還是拒絕？
2. 檢查子網與 NSG：是否有出站規則拒絕到 0.0.0.0/0，優先順序是否影響。
3. 查 Effective Route：0.0.0.0/0 下一跳是否指向 NAT Gateway 或正確防火牆/NVA。
4. 查 DNS：虛擬機的 DNS 指向哪裡；到 DNS 是否有允許流量；DNS 是否能解析外部。
5. 查 OS 防火牆與代理：是否阻擋出站；是否要求代理但設定錯或憑證缺失。
6. 測試並定位跳點：用 traceroute/tracert 看中途失敗的位置（配合路由預期）。
7. 高階檢查：NVA/防火牆是否 SNAT 回程正常；策略是否影響特定目的地。

當你把這套流程用在每次事件，你會越來越快找到真正的根因，也能降低反覆試錯帶來的變更風險。

第十章：常見誤區與更好的做法

Azure帳號開戶服務 10.1 只開放 NSG 入站是不夠的

很多人把 NSG 當成「只影響別人連你」。但外網連不上，通常是你要連出去。出站規則、路由與回程同樣關鍵。

Azure帳號開戶服務 10.2 只看「能不能 ping」會誤判

ICMP 在多數企業環境並不可靠。應該用能反映應用連線的測試（例如 443）。

10.3 不要只在雲端改設定，主機層也要對齊

例如：Azure 網路允許出站，但主機仍啟用 OS 防火牆阻擋；或應用層只在某些工具上設了 proxy。只有把各層對齊，你才會一次解掉問題。

結語：讓排查從「猜」變成「驗證」

Azure 虛擬機連不上外網，真正的難點不是缺少設定，而是問題可能落在多個層級：NSG、路由（UDR/NAT）、DNS、OS 防火牆、代理與中間設備。把握一個核心原則：每次排查都要能驗證假設，而不是靠經驗盲改。

如果你依照本文的順序——先定性（DNS/連線）、再查有效路由與出站安全、最後對齊主機層——你幾乎一定能在較短時間內定位根因，並給出可落地的修正方案。