Azure企業帳號服務 微軟雲服務器多 IP 配置詳細流程

第一章：先把問題想清楚

很多人第一次做「多 IP 配置」時，腦子裡想到的往往只是：把更多地址加到網卡上，然後就完成了。但在微軟雲（常見為 Azure）裡，多 IP 的實現方式其實與「你想達到的效果」高度相關。你需要先問自己三個問題，後面所有操作才不會走彎路。

1. 你要的「多 IP」是指哪種場景？

常見有三類需求：

• 同一台虛擬機同時對外提供多個 IP：例如同一主機上部署多個服務，希望用不同地址分流或更細粒度做訪問控制。
• 內網多地址：例如需要同時接入多個內網段，或讓某些服務綁定特定網段 IP。
• Azure企業帳號服務 多網卡、多網段：例如一台主機既要連內網（管理網），又要連業務網（數據網），甚至還要有獨立的出口網。

不同場景，最佳實現路徑差異很大。

2. 你想讓這些 IP「從哪裡來」？

在 Azure 中，IP 主要來源於網卡（Network Interface）及其關聯的 IP 配置。

• 靜態私有 IP：最常見的做法，適合內網服務、需要固定地址的程式或白名單。
• Azure企業帳號服務 公網 IP：若你希望外網訪問，往往要有公網入口（Public IP）或配合負載均衡/閘道。
• 多地址綁定方式：也可能是同一公網入口下用不同端口或路由規則達到「看起來像多 IP」的效果，但這又是另一套思路。

3. 你需要哪些可用能力？

例如：

• 需要 IPv4 還是 IPv6？
• 是否要求高可用（HA）與自動故障切換？
• 是否要跨子網通信、是否需要自訂路由（UDR）？
• 服務綁定是「綁定到 IP」還是「綁定到 0.0.0.0」？

把這些需求決定清楚，後面你就不會把精力浪費在不必要的配置上。

第二章：前置條件與網路規劃

在動手操作前，請準備好幾個基礎資訊。沒有這些，你會在 UI 裡找很久，也容易配置錯地址段。

1. 準備資訊清單

• 資源群組（Resource Group）名稱
• 虛擬網路（VNet）與目標子網（Subnet）名稱
• 你要分配的 IP 段範圍（例如 10.10.1.0/24 中的哪些地址可用）
• 虛擬機（VM）名稱、現有網卡（NIC）名稱
• 是否需要公網（Public IP）以及是否有現成的負載均衡器（LB）/NAT
• 操作系統與網卡內部名稱（Windows 的網卡介面名、Linux 的網卡設備名）

2. 子網與地址規劃的基本原則

多 IP 配置常見失誤是：選了子網內不存在的地址，或選了已被占用的 IP。Azure 對地址分配有嚴格一致性要求。

• 確保你選定的靜態私有 IP 落在該子網的 CIDR 範圍內。
• 避免與現有 VM、其他 NIC 的 IP 衝突。
• 如果你要把某些 IP 綁定到特定服務，最好在規劃時就定好「IP 的角色」：例如 10.10.1.10 給管理端口，10.10.1.20 給 API 服務。

3. 安全組（NSG）別等到出問題才改

多 IP 配好之後，外部連不進來的情況特別常見。原因通常不是 IP 配置錯，而是 NSG（或防火牆）把流量擋了。

你需要確認：

• 入站規則是否允許你要的端口（例如 80、443、22、3389 等）。
• 是否有「來源 IP 白名單」策略，導致測試時不通。
• 是否有拒絕規則優先於允許規則（NSG 有優先順序）。

第三章：多 IP 的主流做法（先選方案）

在 Azure 中，實現多 IP 通常有幾條路。你不用全部掌握，但必須理解差別。

Azure企業帳號服務 方案 A：同一張 NIC 加多個 Private IP

這是最直觀、也最常用的方式：一台 VM 保持一張 NIC，但在 NIC 的 IP 配置中新增多個 IP。

• 優點：操作相對簡單、服務端也容易綁定不同 IP。
• 注意：某些情況下路由與回應路徑要留意（尤其跨子網或多出口場景）。

方案 B：增加額外 NIC（多網卡）

當你希望不同 IP 來自不同子網，或希望管理面與業務面分離時，多 NIC 會更乾淨。

• 優點：網路隔離更清楚，策略更容易管理。
• Azure企業帳號服務 代價：後續排查時需要留意哪張網卡對應哪個接口名稱。

方案 C：公網層面用 LB / NAT / Gateway 達成「多入口」

如果你要的是「外網看起來有多個地址或多條路徑」，那可能不是純粹多私有 IP，而是公網入口架構的一部分。

• 常見需求：多域名/多服務同時對外、需要健康檢查、需要彈性伸縮。
• Azure企業帳號服務 要點：這通常涉及負載均衡器（Standard LB/Basic LB）或應用閘道（App Gateway）。

本文後續以「方案 A：同一 NIC 加多個 Private IP」為主線，因為它最貼近「多 IP 配置流程」的直覺需求；在關鍵步驟會補充方案 B 的差異點，並在最後給出驗證與排查清單。

第四章：在 Azure 端完成多 IP 配置（核心流程）

Azure企業帳號服務 下面以「你已有一台虛擬機，現在要在它的其中一張網卡上新增多個私有 IP」為例，從進入控制台到完成保存。

步驟 1：找到 VM 的網卡（NIC）

1. 進入 Azure 入口網站。
2. Azure企業帳號服務 找到你的虛擬機（Virtual Machines）。
3. 點進該 VM 的詳細頁面。
4. 在「網路（Networking）」或「設定（Settings）」類似區域，找到 NIC 名稱。

你會看到虛擬機當前至少有一張網卡。點進 NIC，接下來才是 IP 配置的重點。

步驟 2：在 NIC 內新增 IP 配置

在 NIC 的頁面裡，找到「IP 配置（IP configurations）」或類似欄位。

1. 查看現有的 IP 配置列表，通常會有一條配置對應主 IP。
2. 點選「新增（Add）」或「+」新增 IP 配置。
3. 填入以下資訊（常見項目，實際 UI 可能略有不同）：
   • Azure企業帳號服務 名稱：例如 nic-ip-1、nic-ip-2（建議規律命名，後續便於比對）。
   • 子網（Subnet）：一般可選同一子網。
   • 私有 IP 地址（Private IP address）：選擇靜態並填入目標地址，或使用系統分配（你要固定就選靜態）。
   • 配置類型：通常保持預設。
4. 保存（Save）。

完成後，你應該會在 IP 配置列表看到新增的條目。

步驟 3：如需要多 IP，重複新增

如果你要 3 個私有 IP，就需要新增兩次（在原本主 IP 的基礎上）。每一次都要確保地址不衝突。

建議在新增時就整理好用途：

• IP1：對外 API
• IP2：對外 Web
• IP3：內部管理

等你進到系統內部綁定服務時，不會混亂。

步驟 4：如果 VM 沒有立即生效，考慮重啟或更新網路

Azure 的網卡變更後，客戶端系統通常會自動感知，但在某些情況下你可能需要讓系統重新獲取接口配置。實務中常用做法：

• Windows：嘗試重啟網卡或重啟 VM（看你環境允不允許）。
• Linux：重新啟用網路服務或重啟網卡，必要時重啟 VM。

若你正在維運生產環境，先用「低影響」的方式嘗試（例如重啟網路服務），仍不行再考慮重啟整機。

第五章：在虛擬機內完成多 IP 使能與綁定

Azure 已經把 IP 發給網卡了，但你的服務要「真正用起來」，通常還需要系統層面的確認：接口是否出現了多個地址、是否有防火牆規則、服務是否綁定到了正確 IP。

Windows 虛擬機確認與綁定

1. 打開「網路連線」或進入「網路和 Internet」查看。
2. 找到該網卡對應的介面（名稱可能包含 NIC 的顯示名稱）。
3. 確認「IPv4 地址」是否顯示多個地址。

如果系統沒有立刻顯示新增 IP：

• 嘗試禁用再啟用該網卡。
• 或在命令行執行網路重新初始化（具體命令依版本而定）。

接著，當你要把服務綁到特定 IP 時，請在服務設定裡指定綁定地址。例如 Web 服務通常可以指定「監聽 IP」，而不是只監聽 0.0.0.0。

Linux 虛擬機確認與綁定

Linux 下常用驗證方式：

• 用 ip addr 查看網卡是否出現多個 IPv4 地址。
• 用 ip route 檢查路由是否正常。

若你已看到多個地址出現，服務綁定就更簡單：把程序的綁定 IP 設為其中某個地址即可。

如果你需要確保「重啟後仍保留多 IP」，通常在 Azure 的情境下多 IP 由雲端 NIC 資訊下發，Linux 多半會在啟動時自動配置；但如果你有額外網路管理（如 NetworkManager 或自建網路腳本），要避免腳本覆蓋雲端配置。

第六章：防火牆、NSG 與安全策略的關鍵點

多 IP 配好之後，連通性才是最常被忽略的部分。你要把「雲層」和「主機層」一起看。

Azure企業帳號服務 1. NSG 層

NSG 是子網或網卡級的策略。當你新增了 IP 配置，它通常不會自動放行任何流量。你要確保：

• 入站規則允許目標端口。
• 若你設了來源限制，測試用的來源 IP 要符合。
• 若用到探測（health probe）或負載均衡器，探測來源及端口也要允許。

2. 主機防火牆層

即便 NSG 允許，主機仍可能擋住。

• Windows：檢查防火牆入站規則是否允許該端口與服務。
• Linux：檢查 iptables / nftables 或 UFW（依你實際環境）。

如果你的服務只綁定在某個 IP 上，那防火牆規則通常不受影響；但某些應用型防火牆可能與綁定地址有關，這時就要更細看。

Azure企業帳號服務 3. 回應路徑與來源地址（易踩坑）

當你有多個 IP 時，一個經典問題是「請求打到了某個 IP，但回應卻走錯地址」。雖然 Azure 網卡一般會處理回應，但在某些複雜路由、或多出口環境中，仍可能出現不一致。

Azure企業帳號服務 你應該：

• 檢查路由表（Linux）或 IP 配置狀況（Windows）。
• 確認服務綁定地址與你期望的入口 IP 一致。
• 必要時用抓包或日誌確認回應實際發送的來源 IP。

第七章：驗證連通性與服務可用性

驗證不要只做「ping 通」。多 IP 目的通常是讓不同服務能被正確訪問，所以你要驗證到應用層。

1. 網路層驗證

• 從同一子網測試：用目標 IP 測試端口（例如 telnet/curl 對應服務端口）。
• 從外部測試：若有公網入口，請測試外部可達性。
• 確認每個 IP 是否都在系統內可被綁定並響應。

2. 應用層驗證

針對每個 IP：

• 確認服務是否在正確 IP 上監聽（Listen on）。
• 確認返回的回應頭或頁面中包含的資訊是否符合預期（有的系統會把本機 IP 反饋回客戶端）。
• 做一次真正業務流程測試，而不是只打開端口。

3. 壓測與穩定性（可選但建議）

當多 IP 被用來分流或承載不同入口時，建議做輕量測試確認服務不會因為配置變更出現錯誤，例如：

• 短暫的連線重置
• 應用緩存仍使用舊地址
• 日誌中出現綁定失敗或許可不足

第八章：常見問題與排查清單

你在實際落地時，往往不是因為操作步驟忘了保存，而是因為某個細節導致「看起來配置了，但就是用不了」。下面整理最常見狀況。

問題 1：Azure 端新增了 IP，但 VM 內看不到

• 先確認你新增的是同一個 NIC；有些人以為是在 VM 層做，其實是對錯 NIC。
• 確認系統網卡是否完成刷新。必要時重啟網卡或 VM。
• 檢查是否存在網路管理腳本覆蓋了 IP 配置。

問題 2：IP 出現了，但連不進服務

• NSG 是否允許端口與來源？
• 主機防火牆是否允許？
• 服務是否真的綁定在該 IP？很多應用默認只監聽 0.0.0.0 或只監聽某個地址，導致你測的 IP 不通。
• 若使用 Windows 服務，檢查是否允許在多 IP 下運行與權限。

問題 3：其中一個 IP 正常，另一個不正常

• 核對那個 IP 是否被寫入應用監聽配置或白名單。
• 檢查該 IP 對應的網段與路由是否符合預期。
• 確認防火牆規則是否「按接口」或「按地址」做了限制。

問題 4：跨子網或多網段時回應路徑不一致

• 查看路由表與預設路由（尤其 Linux）。
• 必要時檢查是否有自訂路由（UDR）或路由優先級問題。
• 若涉及多 NIC，確認服務從哪張網卡出站。

第九章：如果你改用多網卡（方案 B）的差異

當你的多 IP 需要來自不同子網時，多網卡通常更符合直覺。其流程雖相似，但思維不同：你不是單純加地址，而是讓主機同時擁有多個獨立網路接口。

方案 B 的核心流程

1. 確定要使用的第二個子網（可能是管理網或業務網）。
2. 新增第二張 NIC 並將其關聯到目標子網。
3. 把第二張 NIC 掛到 VM 上。
4. 在系統內分別確認兩張網卡的 IP。
5. 在應用層指定出入站地址（尤其是多網卡環境更要小心）。

多網卡特別注意

• 路由表可能需要調整（例如你希望管理流量走管理網）。
• 來源地址選擇會影響回應。某些情況需要明確綁定或設置策略路由。
• NSG 與防火牆規則要分網卡套用，而不是只看一個入口。

第十章：把流程做成可複用的「標準作業」

很多團隊在做多 IP 配置時，常常是「今天能用，明天又不行」。真正穩定的做法，是把流程固化成可複用的檢查清單。

建議的交付清單（落地必備）

• 地址清單：列出 IP1/IP2/IP3 的用途、子網、是否靜態。
• 網卡對應：記錄 NIC 名稱與系統內接口名。
• NSG 規則：哪些端口允許、允許哪些來源。
• 主機防火牆：端口是否允許、是否允許特定網段。
• 服務綁定：每個服務是否監聽目標 IP。
• 驗證方法：用什麼工具/命令測，測什麼結論算通。
• 排查路徑：若某 IP 不通，依序檢查雲端→網卡→系統→服務→防火牆。

避免「只看設定不測試」

多 IP 配置最容易出現的情況是：你看到地址都在，但服務其實沒有按你預期去綁定。只要測試到應用層（端到端），就能在最短時間把風險消掉。

結語：把多 IP 配置變成可控的工程

「微軟雲服務器多 IP 配置」看似只是多加幾個地址，但真正難點在於：你要讓雲端配置、網路策略、主機網卡、服務綁定、以及路由回應路徑彼此一致。當你能清楚界定需求（你要多 IP 做什麼）、完成良好地址規劃、並用可重複的驗證流程把結果落到應用層，多 IP 就不再是麻煩事，而會變成你架構設計的一部分。

如果你願意，我也可以根據你的實際目標（例如：要幾個 IP、是否需要公網、是否不同子網、服務是什麼）把流程改寫成更貼近你現場的操作清單。