Azure快速開戶 解決 Azure 虛擬機動態 IP 變更問題

第一章：問題為什麼會發生

在 Azure 用得久的人，通常都遇過同一種困擾：你明明把某台虛擬機（VM）連到網路，也設定了連線方式（例如遠端桌面、特定白名單、防火牆來源），結果過幾天或重啟後，對外或內部 IP 竟然變了。你以為是「網路抽風」，但更常見的原因是：Azure 的網路指派機制與你在系統內做的設定之間，存在落差。

先把範圍切清楚。你說的「IP 變更」可能是兩種層級：

• 內部 IP（Private IP）變更：VM 所在 VNet/子網內的 IP 改了，導致同子網或依賴內部地址的服務失效。
• 公網 IP（Public IP）變更：你用公網 IP 連 RDP/SSH，或把公網 IP 寫進防火牆白名單，結果地址換掉。

兩者的解法不完全一樣，但背後的共同核心是「誰擁有最終決定權」。Azure 網路介面（NIC）、子網 DHCP 與公網 IP 資源，決定了地址如何被分配。若你只在 OS 內改設定卻忽略 Azure 端的配置，地址仍可能在某些事件後重新指派。

最常見的觸發事件

以下是實務上最常見讓 IP「看似不該變卻變了」的情況：

• VM 重啟或停止/啟動：如果你的 NIC 或公網 IP 使用了動態/重用策略不明確，重啟可能引發重新指派。
• 調整網路介面或部署方式：例如刪除重建 NIC、改子網、變更部署模板，或用自動化流程重跑資源。
• 子網 DHCP 行為：內部 IP 若依賴 DHCP，地址可能在租期到期或網路狀態變更時重分配。
• 你以為「改了 OS」就會固定：在 Windows/Linux 內把 IP 設成靜態，但 Azure NIC 端仍可能有衝突設定或策略，導致最終仍有可能出現不一致或你在後續操作時被覆寫。

因此，解題不是只找一個設定選項，而是建立一套「地址固定」的系統性做法：在 Azure 端把地址的生命週期鎖住，再在 OS 端做一致的網路配置與驗證。

第二章：先判斷你遇到的是哪一種 IP

要有效解決問題，第一步是把現象對上原因。很多團隊把時間花在猜測，結果其實是「看錯層級」。你可以用簡單的方式快速判斷。

判斷內部 IP 是否在變

在 VM 上執行以下操作（以 Linux/Windows 都可對應）記錄目前：

• 私有 IP（Private IP / IPv4）
• 子網（Virtual Network / Subnet）
• 網卡名稱與路由

然後在你確認變更後的時間點，再次比對。若只要重啟或變動後私有 IP 改了，多半是 NIC 端仍在走動態指派，或你在 OS 端設定不完整。

判斷公網 IP 是否在變

接著檢查你對外連線使用的地址。若你用的「公網 IP」在幾天後換了，通常意味著你所用的公網 IP 資源不是「固定指派」。常見情況包括：公網 IP 為 dynamic，或你每次重新部署都建立了新 IP 資源。

你可以回到 Azure 入口網站或自動化腳本輸出，查每次部署/重建時的公網 IP。若 IP 資源本身會被重建，那就不是「你在 OS 端能控制」的範圍。

第三章：內部 IP 的正解做法（Private IP 固定）

內部 IP 固定通常要同時考慮兩層：

• Azure 的 NIC / 子網指派：讓 NIC 使用你指定的靜態地址。
• VM 內 OS 網路設定：確保 IP、閘道、DNS 一致且可被系統正確維持。

很多人只盯著 VM 作業系統內的 IP，卻忘了 Azure NIC 可能仍被允許使用動態方式取得地址。當你期望「穩定」，就要把控制權留在最上游。

在 Azure 為 NIC 設定靜態內部 IP

在 Azure 的虛擬機或 NIC 設定中，你可以把內部 IP 從動態（Dynamic）改為靜態（Static）。重點是：你要在 NIC 層級指定固定的 Private IP，避免每次 DHCP 行為導致變動。

實作時要特別注意：

• 所選的 IP 必須在子網範圍內。
• 該 IP 不能與其他裝置衝突（例如其他 VM、負載平衡器、或手動配置的靜態地址）。
• 你要確保你知道子網 DHCP 用的範圍（避免 DHCP 自動分配到你指定的 IP）。

一旦 NIC 端固定，VM 重啟通常不會再導致內部 IP 變更。

在 OS 內同步靜態配置（避免衝突）

接著回到 OS 端，把 IP 設定成靜態，讓系統網路堆疊與 Azure NIC 指派一致。常見做法：

• 設定 IP 地址 = Azure NIC 的固定 Private IP
• 設定子網遮罩 = 子網掩碼
• 設定預設閘道 = 子網的預設閘道（通常由 VNet 自動提供，你可查路由表）
• 設定 DNS = 你需要的 DNS（可用 Azure DNS 或內部 DNS）

若你 OS 使用 DHCP，但 Azure 已固定 NIC 的私有 IP，理論上仍可能「看起來穩定」。但一旦未來你調整網路或更換網卡，OS 的 DHCP 行為就會重新拿回控制，風險仍在。所以更保險的是一致化：Azure 固定，OS 也一致。

驗證：從「能不能連」到「能不能持續」

修好後不要只做一次連線測試。你至少要驗證：

• 重啟 VM 後，Private IP 是否仍相同
• 在你預期的日常流程（例如部署、擴縮容、重新開機）後，地址是否仍一致
• 依賴該 IP 的服務是否仍正常（例如內部資料庫連線、監控 agent、憑證綁定）

如果你的環境有自動化部署，建議把「IP 是否維持固定」列入驗證清單，否則下次改版又可能把問題引回來。

第四章：公網 IP 的正解做法（Public IP 固定）

若你問題發生在對外連線、或防火牆/白名單依賴公網 IP，解法通常更直接：使用「固定」的公網 IP 資源，並避免每次部署都建立新資源。

為公網 IP 選擇 Static / 使用保留（Reserve）

在 Azure 中建立公網 IP 時，選擇固定（Static）的配置。若使用動態公網 IP（Dynamic），在某些情況下地址可能變更。當你希望它不變，最好的方式就是：

• 公網 IP 使用 Static
• 資源生命週期固定，不要在部署流程中被無意刪除或重建

你也可以把公網 IP 視為一個「需要被保護的資產」。當自動化流程、資源刪除或腳本重跑導致資源重建，就算你的其他設定正確，對外地址仍會變。

把公網 IP 與 NIC/VM 綁定方式設計好

有些團隊把公網 IP 綁定在 VM 上，但每次重新部署都讓 VM 重新生成 NIC，或用新的 NIC/新的資源搭配新的公網 IP。結果就是「永遠用著新的公網 IP」，你就算選 Static 也會失去長期一致性。

因此你需要在部署策略上做到兩件事：

• 確保 NIC 與公網 IP 的關聯在更新時不被打斷
• 確認你的自動化腳本不會無意刪除舊資源

如果你用 Infrastructure as Code，建議把公網 IP 做成明確可重用的資源，而不是隨機生成。

DNS 與憑證：別讓 IP 變成唯一入口

就算你把公網 IP 固定了，仍建議在應用層使用 DNS 名稱，而不是硬綁 IP。尤其是使用 TLS 憑證、或內部/外部連線都要長期維運時。

最佳實務通常是：對外提供一個穩定的 DNS 名稱（例如 yourapp.example.com），然後讓 DNS 指向固定公網 IP。未來即使你要搬遷或更換 VM，你仍可以透過更新 DNS 讓服務切換。

當然，DNS 本身也有 TTL 與快取問題，所以你需要合理規劃更新時機與 TTL 值。但這比起直接在每個地方改 IP，成本會低很多。

第五章：不要忽略的「細節坑」

IP 固定看似簡單，但真正讓人頭痛的是：你以為已經固定，卻仍在某些事件後出現差異。下面是常見坑位。

子網 DHCP 範圍與你指定的靜態 IP 互相打架

你可能在 NIC 設定靜態 IP，但子網的 DHCP 範圍包含了那個地址。當 DHCP 釋出、或某些裝置因為租約變更又拿回地址，衝突就可能發生。衝突未必馬上顯現，但會導致連線間歇性失敗。

對策是確認 DHCP 範圍，並把固定要用的 IP 從 DHCP 分配範圍排除。這需要你理解子網的地址規劃，而不是只做「快速能用」。

你在 OS 設了靜態，卻沒有處理網卡命名與多網卡情境

某些 VM 可能有多張 NIC、或系統升級後網卡名稱（例如 eth0、ensX）變動。你如果把 IP 設在錯的介面，結果就會出現「看似設了，其實沒生效」。

建議做法是：確認 OS 內 IP 設定是套用到正確的介面，並查看系統路由表與對應介面的綁定狀態。

Azure快速開戶 部署模板或自動化更新覆寫網路設定

Azure快速開戶 當你用腳本或模板反覆部署時，可能出現下列情況：

• 部署流程建立新的 NIC 或替換資源
• 部署流程重置公網 IP 或改成動態
• 部署流程在更新時把舊資源清掉

你在手動介面中改過設定，下一次自動化又把它還原。這會讓人誤以為「Azure 又在變」。實際上是部署流程在重寫你的修正。

對策是把網路設定納入版本化的基礎架構描述，確保每次部署都維持一致。

只固定 IP，卻忘了防火牆規則依賴的是「來源」而非「目的地」

Azure快速開戶 另一個常見誤會是：你把 VM 的 IP 固定了，卻發現遠端桌面仍然不通。原因可能是安全規則使用了舊的「來源 IP」或某些 NAT 行為。

你需要確認防火牆（NSG、Azure 防火牆、或在 OS 端的防火牆）所使用的規則方向、來源/目的條件是否仍符合你實際的連線路徑。

例如：你以為「連線到 VM 的目的地」是舊 IP，但規則可能是針對「連線來源」的 IP 白名單。若你的來源 IP 本身是動態的（例如你公司網路出口會變），那就算目標固定也無法解決。

第六章：一套可落地的排查與修復流程

下面給你一套可以照著做的流程，適合排查「到底是哪裡在指派地址」，也適合作為團隊維運的 SOP。

步驟 1：收集三組資訊（出問題前後）

• VM 的內部 IP、子網與網卡對應
• VM 的公網 IP 是否變、變到哪個新地址
• 最近是否有重啟、部署、調整 NIC/子網或重建資源

如果你只有「現在和之後」的地址差異，卻不知道事件時間點，很難定位。

Azure快速開戶 步驟 2：檢查 Azure NIC 與公網 IP 的配置類型

• NIC 的 Private IP 是 Dynamic 還是 Static
• 公網 IP 是 Dynamic 還是 Static
• VM 是否被重新建立 NIC 或替換過

這一步通常就能直接找出主因。若你看到 NIC 使用 Dynamic，那內部 IP 變動基本就有答案。若公網 IP 是 Dynamic，那對外地址變動就合理。

步驟 3：在 OS 端確認網路設定一致

確認：

• OS 內設定的 IP 是否等於 Azure NIC 固定值
• 閘道、DNS 是否正確
• 沒有多餘網卡或錯配介面

必要時重啟網路服務或重新啟動 VM，並觀察地址是否保持。

步驟 4：更新依賴項（連線、白名單、DNS、監控）

如果你的流程中有以下依賴，就需要同步修正或改成更穩定的做法：

• 遠端連線工具的連線設定（主機名或 IP）
• Azure快速開戶 NSG/OS 防火牆白名單
• 監控/告警系統的目標地址
• 應用程式的連線字串或憑證綁定
• 內部服務的固定路由或 hosts 檔

Azure快速開戶 如果你把地址固定做好，未來這一步的頻率會下降；但你仍要確保目前的依賴項已回到正確狀態。

步驟 5：建立「不再發生」的驗證點

Azure快速開戶 建議你至少做一次：

• 重啟 VM 後驗證 IP 未變
• Azure快速開戶 執行一次計畫內的部署/更新（若環境允許）驗證地址未被覆寫
• 用實際方式測試你最在意的連線（RDP/SSH、網站、資料庫）

把驗證納入變更流程，問題就不會在下一次人為修改或自動化部署中重現。

第七章：遷移與改版時怎麼避免「修了又壞」

很多團隊不是一次把配置做對，而是修修補補走過去。真正成熟的做法是：把網路地址策略納入變更管理，讓未來改版時你不必再靠經驗猜。

把固定地址當成架構的一部分

固定 IP 不應只是「今天為了讓某個服務通起來」。它是一種架構選擇，應該明確寫在：

• 部署規範（固定用哪個內部 IP、公網 IP）
• 變更流程（什麼情況允許重建 NIC、公網 IP）
• 回滾策略（萬一部署失敗，如何保留原地址）

當規範存在，你就不容易被臨時需求推著走。

把人工操作降到最低

如果你每次都要手動點選 NIC 把 IP 改回靜態，當團隊人員輪替或流程變更，就很容易漏掉。更穩健的是讓配置由程式/模板管理，至少確保「靜態策略」不會在更新時被遺失。

用 DNS 名稱承接變動風險

就算你固定了 IP，仍可能遇到例外：例如安全策略調整、災難復原、或跨區域搬遷。DNS 名稱能把這些變動封裝起來。你可以在切換時只更新解析，而不是全局改程式與防火牆設定。

因此最佳做法是：讓 IP 成為內部依賴的底層細節，而不是外部系統的唯一入口。

第八章：常見問答與實務建議

如果我已經遇到 IP 變更，現在要怎麼補救？

Azure快速開戶 最務實的做法是：

• 立即在 Azure 端把 NIC 的 Private IP 改成 Static（並選擇你要保留的地址）
• 若公網 IP 也變動，改成 Static 並確保不被重建
• 在 OS 端同步網路設定
• 更新依賴項（連線、白名單、監控與程式設定）

然後做重啟驗證，確認未來不再漂移。

我只想解決遠端桌面不通，是否只要固定公網 IP 就好？

不一定。遠端桌面不通可能是以下因素共同造成：

• 公網 IP 變了（目標變了）
• NSG/OS 防火牆規則仍指向舊的來源或目標
• 你使用了 jump host 或 NAT，實際對外來源也可能變

你需要同時確認路徑上每一個「依賴 IP」的地方是否一致。

內部 IP 固定後，為什麼仍偶爾連不上？

這時候通常不是 IP 真正改了，而是以下可能：

• DNS 解析仍指向舊 IP（快取未清或解析不一致）
• 防火牆規則或路由表沒有更新
• 服務監聽的網卡地址綁定錯（只綁在某個舊介面）
• 子網內有衝突（靜態 IP 與 DHCP 分配衝突）

所以解法不能停在「地址固定」；你還要驗證依賴服務是否也同步。

結語：把 IP 變更從「意外」變成「可預期的例外」

Azure 的網路設計並不神秘，它只是把「地址的指派」交給更上游的資源：NIC 與公網 IP。你要做的，是在正確的地方做正確的鎖定，而不是在 VM 內做孤立的修補。

當你把內部 IP 設為靜態、把公網 IP 設為靜態並保留資源生命週期，再配合 OS 端同步與依賴項更新，你會發現 IP 變更問題從根本上下降。更重要的是，你把風險納入流程：驗證、部署一致性、DNS 承接變動，讓系統不再被突發的地址漂移牽著走。

真正的穩定不是「永遠不變」，而是「變得可控、可追溯、可快速修復」。當你用這套方法把地址策略標準化，下一次你再遇到 IP 變更，就不會只是忙著補救，而是能有條理地回到設計與驗證。