Azure代理帳號充值 香港微軟雲伺服器怎麼搭建：從建立實例到配置網路安全組完整操作

前言：你其實在做三件事

很多人把「搭建香港微軟雲伺服器」理解成填表、開機、能連上就算完成。但在實務上，你真正要處理的是三件事：第一，建立一台可運行的主機（虛擬機或容器節點）；第二，讓網路路徑正確（VNet、子網、路由、公共入口）；第三，確保安全策略可控（特別是網路安全組 NSG：哪些封包能進、哪些能出、誰能連、連到哪裡）。

本文會以「在 Azure（香港區域）搭建一台可連線的虛擬機」為主線，並把重點放在網路安全組的配置，讓你理解背後邏輯，而不是只照著選項抄作業。

第一章：建立實例前先想清楚需求

在你按下「建立」之前，先用五個問題把需求釘牢。因為你後面在 NSG 配規則，端口選擇、來源 IP、是否允許管理介面，都會被這五個答案牽著走。

第一節：你要跑什麼服務？

Azure代理帳號充值 常見情境：

• Web 服務：通常需要 80/443（或 8080/8443）
• SSH 管理：通常需要 22
• 資料庫：例如 MySQL 3306、PostgreSQL 5432、SQL Server 1433（但建議限制來源，不要對全網開）
• 遠端桌面：Windows 可能需要 3389（更建議改用 VPN 或限制來源 IP）

你要先列出「對外必須開哪些端口」，再決定「哪些端口只能從內網或特定來源進」。

第二節：你允許誰連線？

很多事故不是因為“忘了開安全”，而是因為一開始就把規則設成「允許所有來源」。你可以採用更務實的策略：

• 管理入口（SSH/RDP）只允許你自己的固定 IP，或企業辦公網路 IP 段
• Web 服務可以允許全球訪客，但應搭配 WAF/速率限制（若你後續需要可以再加）
• 資料庫入口盡量不做公網直連，改由內網或透過跳板主機

第三節：你要不要指定區域與可用性需求？

本文目標是「香港」。Azure 的香港區域通常可用於大多數服務，但你仍要注意：

• Azure代理帳號充值 選擇對應的區域（例如 East Asia / Hong Kong 對應的區域代碼會在介面中顯示）
• 如果你有嚴格可用性需求，後續可以用多實例與負載平衡，而不是只靠單台主機

第二章：建立香港區域虛擬機實例（從零到可開機）

接下來進入實作。我會以 Azure Portal 的典型流程描述；不同帳號權限或介面版本可能略有差異，但核心步驟不變。

第一節：準備資源群組與基本命名

你需要一個資源群組（Resource group），把相關資源納入同一管理範圍。建議用規範命名，例如：

• rg-hk-prod-web-01
• rg-hk-dev-app-01

命名的價值在於：你將來刪除、擴容、追蹤費用時會非常省時間。

第二節：選擇虛擬機基本設定

進到「建立」→「虛擬機」，你通常會看到需要填：

• 訂用帳戶（Subscription）
• 資源群組（Resource group）
• 區域（Region）：選香港區域
• 虛擬機名稱（VM name）
• 映像（Image）：選 OS（例如 Ubuntu Server、Windows Server 等）
• 大小（Size）：依 CPU/記憶體/預期流量決定

若你只是初學或測試，選一個通用型大小即可；但注意：後續你要調整 NSG 或掛載磁碟，規模太小會在效能上造成挫折。

第三節：設定認證方式（SSH 或密碼）

Azure代理帳號充值 對 Linux 虛擬機，最常見是 SSH 金鑰。建議你使用金鑰方式，不要用弱密碼。

• 選擇認證類型：SSH 公開金鑰
• 填入你的公鑰內容
• 確保私鑰妥善保存

對 Windows 虛擬機，通常會要求設定管理員帳號與密碼。若你要長期使用，請遵循密碼複雜規則，並考慮搭配限制來源 IP 的 NSG。

第四節：網路設定先做對，後面才不會重來

在建立虛擬機時，系統往往會引導你選擇：

• 虛擬網路（VNet）
• 子網（Subnet）
• 公用 IP（Public IP）：是否分配
• Azure代理帳號充值 網路介面（NIC）是否使用預設設定

你可以選用現有 VNet 或新增 VNet。若你要把流程做穩，建議新增一個專用 VNet（至少先做到清楚可控）。

另外，建立 VM 的時候通常會有選項自動開啟某些端口（例如 SSH/HTTP）。你需要看清楚它做了什麼：它可能直接產生對應的 NSG 規則。若你要完全掌控，建議你不要讓系統自動設定過寬，改成後續手動配置。

第五節：建立與初始化

確認所有選項後提交。建立過程可能幾分鐘到更久。當狀態顯示「執行中」，你就可以進行連線測試。

• Linux：使用 SSH 連到 VM 的公網 IP
• Windows：使用 RDP 連到 VM 的公網 IP（但通常需要 NSG 放行 3389）

如果你現在連不上，先不要急著重建；優先檢查 NSG、網路介面、以及是否真的分配了 Public IP。

第三章：理解 NSG 的作用（你要先會“看懂規則”）

網路安全組 NSG 是 Azure 對網路封包做“進出控制”的機制。NSG 由一組安全規則組成，每條規則包含方向、來源、目的、協定與連接埠範圍，以及動作（允許/拒絕）與優先順序。

在你配置 NSG 時，最重要的觀念有三個：

• 方向（Direction）：Inbound（入站）和 Outbound（出站）是兩套規則，不能混用。
• Azure代理帳號充值 優先順序（Priority）：數字越小優先越高。規則命中後就決定結果，後面的規則可能不再影響。
• 來源/目的（Source/Destination）：你若寫錯了 IP 範圍，結果就是你自己被鎖在外面。

第一節：Inbound 與 Outbound 怎麼分工

通常：

• Inbound：讓外部訪客或你自己管理端進入（例如 SSH 22、HTTP 80、HTTPS 443）。
• Outbound：讓主機回連到更新伺服器、下載套件、連到 API 或資料庫（取決於架構）。

最常見的問題是：只設定 Inbound，卻忽略 Outbound 會影響系統更新或應用外連；或反過來你收緊 Outbound 導致套件安裝失敗。

第二節：規則的“來源 IP”不要想太簡單

來源 IP 你要明確知道它代表什麼。若你用「你的辦公室網段」或「家用網路固定 IP」，那規則才可靠。

若你使用動態 IP（例如家用網路多半會變），那你每次換網都得改 NSG，這對運維很不友善。你可能需要：改用 VPN、跳板機、或至少允許一個合理的來源範圍（但安全性會下降，需要權衡）。

第四章：配置網路安全組（NSG）完整操作

現在進入重點：如何針對你的虛擬機建立一組合理的 NSG 規則，既能連得進，也能避免把伺服器暴露成“公開服務”。

第一節：進入 NSG 與選擇綁定方式

你可以用兩種常見方式使用 NSG：

• 綁定到 網路介面（NIC）：粒度最細，適合單台 VM。
• 綁定到 子網：管理方便，但影響同子網內所有資源。

如果你是一台 VM，建議綁定到 NIC，這樣你不用擔心其他資源被同一套規則影響。

進入 Azure Portal 後找到你的虛擬機 → 網路介面（NIC）→ 查看關聯的 NSG。若你還沒有 NSG，通常可以在網路設定頁面新增或建立。

第二節：建立一個“最小可用”的 Inbound 規則集合

以最典型場景：Linux VM，提供 Web（80/443）並且你需要 SSH 管理。你可以建立以下 Inbound 規則：

• 允許 SSH（22）：來源 = 你的固定公網 IP（/32）。目的 = VM 的主機。
• 允許 HTTP（80）：來源 = Internet（或你需要的範圍）。目的 = 80。
• 允許 HTTPS（443）：來源 = Internet。目的 = 443。

至於是否需要明確加拒絕規則，通常不必。因為 NSG 內建會有預設動作（多數情況是 Deny）。你要做的是把允許規則設對。

第三節：規則參數怎麼填才不會踩雷

當你建立每條規則時，通常會看到類似欄位：

• Source：來源地址或範圍
• Source port ranges：通常可保留為 *（因為來源端埠通常是隨機）
• Azure代理帳號充值 Destination：目的地址（VM 位址或 *）
• Destination port ranges：你要放行的埠（例如 22、80、443）
• Protocol：TCP/UDP/Any
• Action：Allow 或 Deny
• Priority：優先順序（越小越先命中）

建議你做到“可讀性”：

• 規則名稱清楚：如 allow-ssh-from-home-ip、allow-https-from-internet
• 優先順序採用區間規劃：例如 1000~1999 給管理入口、2000~2999 給網站入口
• 必要時把服務端口固定為單一範圍（避免誤放行）

第四節：OutBound 規則不要一口氣收太緊

很多人看到安全就想把 Outbound 全拒絕。但系統更新、DNS 解析、NTP 同步、套件安裝都可能需要對外連線。若你尚未理解流量需求，建議先採取“只做必要限制”。

一個務實做法是：先維持預設允許 Outbound，確定功能可用後，再針對你確定的外連目的地收斂。

如果你要先收斂到能用的程度，至少要確保：

• DNS（通常 UDP/TCP 53，目的可能是 Azure DNS 或你設定的 DNS 伺服器）
• HTTP/HTTPS（80/443，給系統更新與下載套件）
• NTP（時間同步，有些系統需要）

但不同 OS 與設定會有差異，實務上你應該以實際需求調整，而不是靠想像。

第五節：把“只允許必要端口”落在規則裡

當你的 Inbound 規則只允許 SSH/HTTP/HTTPS 時，其他端口即使主機程式在跑，也會因 NSG 阻擋而不可從外部連入。這是一種非常有效的第一道防線。

因此你要做的是：把可能造成風險的管理服務（SSH/RDP）嚴格限制來源，並把公開服務的端口縮到最小集合。

Azure代理帳號充值 第六節：建立 Windows 場景的差異提醒

如果你是 Windows VM，除了 80/443 之類的 Web 埠，管理通常會用 RDP 3389。這時你更需要限制：

• 不要把 3389 對所有來源開放
• 優先只允許你固定 IP
• 若你沒有固定 IP，建議改用 VPN 或跳板機，或至少在 NSG 中允許一個你可控的來源範圍

第五章：連線測試與排錯（連不上時怎麼查）

NSG 配完後，最怕的是你自己也連不上。下面提供一套排錯順序，能避免你在錯的地方花時間。

Azure代理帳號充值 第一節：先確認“連線到的 IP 是不是正確的”

• 確認 VM 是否有公用 IP
• 確認你連線使用的 IP 是最新分配的 Public IP
• 如果你有 NAT 或額外設備（例如代理），確認路由是否正常

第二節：檢查是否真的放行了對應協定與埠

Azure代理帳號充值 常見錯誤：

• 把 SSH 端口寫成 23 或把 TCP/UDP 選錯
• 目的端埠填錯（例如寫成 22-22 寫成無效格式）
• 來源範圍寫錯（/24 vs /32）

第三節：確認規則 Priority 是否被“更高優先級”打掉

如果你同時存在 Allow 與 Deny，且 Deny 的 Priority 更小，就會優先命中 Deny。你可以在 NSG 規則列表中查看排序，確保 allow 規則優先。

第四節：檢查是否綁錯了 NSG

NSG 可能綁在 NIC，也可能綁在子網。若你在 NIC 建了規則，但實際綁定的是另一個 NSG，那你的修改等於沒生效。排錯時要先確認關聯。

第五節：主機端服務是否真的在聽

即使 NSG 放行了，若你的服務沒啟動或沒綁定到正確的網卡，也會連不上。你需要在 VM 上檢查：

• SSH：sshd 是否運行、是否監聽 22
• Web：Nginx/Apache 是否運行、是否監聽 80/443

通常 Linux 上可以用系統工具檢查端口狀態（如 netstat / ss）。

第六章：把安全做到“可長期維運”的程度

一次性搭起來不難，難的是你未來要維護、擴容、換機還要保持一致。下面提供幾個讓部署更穩的方法。

第一節：把規則變成“規範”，不要靠記憶

建議你在規劃時就列出：

• 管理入口（SSH/RDP）允許哪些來源 IP
• 網站入口允許哪些端口與協定
• 是否需要開放其他服務（例如 API 端口）
• OutBound 允許哪些方向與目的地（先以能用為前提）

你把這張清單保存下來，未來換機時能快速複製同樣策略。

第二節：避免“全開”，尤其是管理端

把 SSH 或 RDP 對全網開放，基本等同於把門鎖拿掉。即便你用金鑰，也會增加掃描與嘗試的風險。正確做法是：只允許少數可信來源。

第三節：先上路，再談擴展

很多人一開始就想把負載平衡、私有連線、零信任全部做完。結果是流程複雜，排錯困難，時間成本爆炸。

建議順序：

• 先把單台 VM 建好並可用
• 確保 NSG 可控、你能遠端管理
• 再逐步加安全層（例如只允許必要域名、加入反向代理、WAF、跳板與內網策略）

第七章：一個具體示例（把流程串起來）

為了讓你能對照實作，我用一個具體例子串流程：你在香港部署一台 Ubuntu VM，提供 HTTPS 網站，並用 SSH 管理。

第一節：實例層級

• 建立資源群組：rg-hk-prod-site-01
• 區域：香港
• 映像：Ubuntu Server LTS
• Azure代理帳號充值 認證：SSH 公開金鑰
• 網路：新增 VNet，劃分子網，並為 NIC 分配 NSG（或建立後綁定）
• 公用 IP：分配（因為你要從外部連到網站與管理端）

第二節：NSG 規則（Inbound）

• allow-ssh-from-your-ip：TCP 22，來源=你的固定 IP（/32），動作 Allow
• allow-http-from-internet：TCP 80，來源=Internet，動作 Allow
• allow-https-from-internet：TCP 443，來源=Internet，動作 Allow

如果你網站只需要 HTTPS，也可以不開 80。但很多人會做 HTTP → HTTPS 轉址，因此保留 80 會更方便。

第三節：測試與驗證

• SSH：用本機終端連到 VM 的公網 IP，確認密鑰驗證成功
• Web：用瀏覽器或 curl 訪問 80/443，確認回應正常
• 安全驗證：嘗試連其他埠（例如 3306/3389），確認外部無法連入

第八章：常見坑與實務提醒

以下是我在實際部署中最常看到的坑，很多不是技術難，而是細節漏掉。

第一節：在建立 VM 時讓系統自動開太多端口

一些精靈會讓你選「允許 SSH」「允許 HTTP」。如果你在這一步選了“允許所有”，或選錯端口範圍，後續你以為自己在 NSG 才配安全，但其實已經被自動規則放大攻擊面。

建議：要嘛你完全信任它的模板，要嘛你在建立過程中保守選擇，最後由你手動確認 NSG 規則。

第二節：來源 IP 用了錯的格式

例如你以為填的是單一 IP，其實填成了錯誤範圍，或 /32 寫成 /24。這會導致：

• 你自己仍然可能連得上（因為某些網路位置仍落在範圍內）
• 但實際上你允許了更多來源，安全性不符合預期

規則建立後，務必回看規則的來源欄位。

第三節：忘了測試 Outbound

你把 Inbound 配好了，卻發現系統更新失敗、證書更新失敗、應用外連 API 連不上。這通常是 Outbound 被限制或 DNS/時間同步問題。

解法：在你收斂 Outbound 前，先確保系統基本功能運作。

第四節：優先順序導致 Allow 沒生效

你可能新增了一條 Allow 規則，但同時系統預設或你之前加過 Deny 規則的 Priority 更小。結果是仍然拒絕。

解法：確保你理解優先順序，並檢查規則列表。

結語：你已經完成一台“可用且可控”的雲伺服器

搭建香港微軟雲伺服器的核心，不在於你會不會點按介面，而在於你能不能把網路與安全的邏輯完整串起來。當你能明確說出：外部需要哪些埠、允許誰的來源、NSG 的規則順序如何運作，你就不會在後續擴容或排錯時被拖著走。

Azure代理帳號充值 接下來如果你要更進一步，可以考慮反向代理與 HTTPS 証書管理、只允許必要的資料庫入口、導入跳板或 VPN、再把安全從“封住端口”提升到“限制路徑與身份”。但那是下一步。你現在已經完成最重要的底座：實例建立、網路可用、NSG 可控。