Azure企業帳號開戶 Azure Blob 靜態網站託管與自訂域名綁定教學

第一章：為什麼選 Azure Blob 來託管靜態網站

很多人做部落格、行銷頁、文件站、簡單前端專案時，會想找一種「夠快、夠穩、成本可控、部署流程簡單」的方案。Azure Blob Storage 的靜態網站託管剛好符合這個需求：你只要把前端檔案（HTML、CSS、JS、圖片、字型）上傳到指定容器，Azure 就能用特定的主機名把內容以 HTTP 方式提供服務。

更重要的是，使用自訂域名能把網站包裝得更像「正式產品」。使用者不想看長串的 blob 主機名，他們更習慣記住你的網域。因此本文的目標是把兩件事串起來：第一，讓 Blob 靜態網站能正常回傳頁面；第二，把自訂網域（例如 www.example.com）綁定到 Blob，讓訪客直接用你的網址進站。

我會用清楚、可操作的流程寫，並在每一步補上常見錯誤的原因。你照做通常就能成功。

第二章：前置準備與概念釐清

2.1 你需要準備什麼

• Azure企業帳號開戶 Azure 帳戶（可先用免費額度或試用帳戶測試）。
• 一個網域（由你目前的網域商管理 DNS，例如 GoDaddy、Cloudflare、阿里雲或其他）。
• 網站檔案：至少包含 index.html（或你設定的索引文件）與相關資源。

2.2 Blob 靜態網站託管的基本概念

啟用靜態網站託管後，Azure 會對應你的儲存帳戶產生一個靜態網站端點（host name）。你可以把它視為「對外公開的 HTTP 服務地址」。當使用者瀏覽時，Azure 會根據 URL 路徑從 blob 容器裡找檔案回傳。

要注意的是：靜態網站託管更偏向「靜態資源」情境。如果你希望伺服器端運算（例如 PHP、後端 API 直接由 Blob 處理），那就不是它的定位。不過對於一般前端站點、 SPA（單頁應用）或簡單文件頁，它非常適合。

第三章：建立儲存帳戶並啟用靜態網站託管

3.1 建立儲存帳戶

在 Azure 入口網站：

• 開啟「儲存帳戶」並建立新帳戶。
• 訂閱、資源群組自行選擇。
• 儲存帳戶名稱務必注意：這個名稱也會影響後續的端點網址。
• 效能層級與複寫通常可用預設（例如標準/本地冗餘等，依你需求）。
• 重點：確保「啟用 Blob 存取層級」符合你的預期；你後面會需要能公開讀取。

建立完成後，進入該儲存帳戶的「概觀」頁面，先確認你有權限能設定靜態網站與網路規則。

3.2 啟用靜態網站託管

在儲存帳戶左側選單中找到「靜態網站（Static website）」。

• 選擇「啟用」。
• 索引文件（Index document）通常填 index.html。
• 若你有自訂錯誤頁，可填 404.html（或你實際的檔名）。

啟用後，Azure 會顯示一些資訊：例如靜態網站的主機名（常見格式類似 yourstorageaccount.zxxxx.blob.core.windows.net 的變形端點）。你稍後要用它做 DNS 綁定。

如果你啟用後看到主機名欄位、且服務狀態顯示已啟用，代表基礎功能已就位。

3.3 設定網路與公開存取（非常常見的踩雷點）

靜態網站託管能否被外界存取，常常跟你的「公用存取設定」相關。你需要檢查：

• 儲存帳戶裡「防火牆和虛擬網路」或「網路」相關設定。
• Azure企業帳號開戶 是否限制了公用存取或只允許特定網段。
• 如果你希望讓外部網域可以直接讀取，通常要允許必要的公用存取（依 Azure 的設定邏輯）。

有些人把儲存帳戶設得很安全，結果靜態網站啟用了卻無法用瀏覽器打開。這不是靜態網站壞了，而是「網路層沒有放行」。你可以先在開發/測試階段放寬到能驗證工作。

第四章：建立容器並上傳網站檔案

4.1 使用正確的容器與命名

Azure 靜態網站託管對容器有特定要求。依設定，你通常會看到建議使用 $web 容器。啟用靜態網站後，Azure 有時會自動建好，或提示你建立。

• 若尚未建立容器，請建立名為 $web 的容器。
• Azure企業帳號開戶 上傳的檔案要放在這個容器底下，才會被靜態網站端點回應。

4.2 上傳檔案與檔名結構

你的網站結構要完整。舉例：

• 根目錄放 index.html。
• 若你有 /assets 或 /css、/js 資料夾，就要原樣上傳整個資料夾。
• 圖片、字型、SVG 等資源也要確保路徑一致。

SPA（例如 React/Vue 的建置）常見問題是「路徑重新導向」。因為前端路由像 /about 並不一定有實體檔案。這時你需要在伺服器端做 fallback 到 index.html。Blob 靜態網站對 SPA 的支援能力有限或依版本設定不同。你可以先用最簡形式測試：確保 /index.html 可正常開啟；若要支援深層路由，後面章節會提供更實用的處理方式。

4.3 MIME 類型與編碼（避免樣式與腳本失效）

通常 Azure 會自動判斷 MIME types，但偶爾你遇到 CSS/JS 類型顯示錯誤，可能導致瀏覽器拒絕載入或以錯誤方式解析。你可以檢查：

• CSS 是否回傳 text/css
• JS 是否回傳 application/javascript 或 text/javascript
• Azure企業帳號開戶 HTML 是否回傳 text/html

Azure企業帳號開戶 若你用一般上傳流程，大多數情況不會需要手動調整。但當你遇到「頁面打開是空白、控制台報錯 MIME」時，就需要回頭檢查。

第五章：驗證靜態網站端點可用

在「靜態網站」設定頁面，你會看到靜態網站主機名。把它貼到瀏覽器，確認：

• 首頁能否正確載入（能看到你的 index.html 內容）。
• CSS/JS/圖片是否正常。
• 錯誤頁（若設定了 404.html）是否在不存在的路徑出現。

這一步很重要，因為 DNS 綁定一旦開始排查，如果你的網站本身還沒成功提供服務，問題會被混在一起。先把「Blob 端點能正常顯示」確認好，後面綁網域才不會一直猜。

第六章：取得端點主機名並準備 DNS 綁定

6.1 端點主機名怎麼找到

回到儲存帳戶的「靜態網站」設定頁。你通常會看到：

• 靜態網站主機名（Static website host name）
• 有時另有 HTTP/HTTPS 端點資訊（視介面顯示）。

你要做 DNS 時，通常需要用到這個主機名。

6.2 DNS 綁定的目標是什麼

你可能有兩種需求：

• 把根網域（例如 example.com）綁到 Blob。
• 把子網域（例如 www.example.com）綁到 Blob。

DNS 的寫法會略有不同：根網域通常用 A 記錄（對應 IP）；子網域常用 CNAME 記錄（對應主機名）。但這取決於 Azure 靜態網站端點是否提供可用的 IP 或你使用的驗證方式。

在多數靜態網站 + 網域綁定情境中，會以 CNAME 為主：www 指到 Azure 提供的主機名。

第七章：DNS 設定（A / CNAME）實作步驟

7.1 情境：綁定 www.example.com 到 Blob

假設你的靜態網站主機名是：

yourstorageaccount.zxxxx.blob.core.windows.net

你在 DNS 管理介面新增一筆：

• Type：CNAME
• Name：www
• Value：yourstorageaccount.zxxxx.blob.core.windows.net

存檔後等待 DNS 生效。通常幾分鐘到幾小時不等，跟 TTL 有關。

7.2 情境：同時綁定 example.com（根網域）

如果你希望不只有 www，還要讓 example.com 也能打開網站，你會遇到一個限制：DNS 規範中根網域（@）通常不適合直接用 CNAME（很多提供商不允許或有替代方案）。常見做法有兩種：

• 使用「DNS 提供商的網域轉導/網域轉址功能」把根網域轉到 www。
• 若 Azure 或你的 DNS 設備支援，可使用特定的 A 記錄方式指向相應的終端（但靜態網站端點未必能直接提供固定 IP）。

實務上，最穩妥的是先確保 www 可用，再用提供商的「轉導」功能或額外紀錄把根網域導到 www。這樣你不必為不確定的 IP 方案煩惱。

第八章：HTTPS 與憑證的可行路徑（務實做法）

很多人以為「綁了 DNS 就自動有 HTTPS」。但現實是：要讓 https://www.example.com 有效，通常需要憑證與 TLS 組態。Azure Blob 靜態網站託管是否直接提供你想要的憑證管理能力，取決於 Azure 介面與功能是否開啟、以及你採用的具體做法。

以下提供一個務實思路：

• 第一階段先把網站用 HTTP 跑起來（最少確認內容與路徑正確）。
• 第二階段再處理 HTTPS。
• 若你的需求是「自訂網域 + 有效憑證 + 自動續期」，多數情況會走到 Azure Front Door 或 Application Gateway / CDN 類方案，在那裡更容易管理憑證與 TLS。

Azure企業帳號開戶 如果你確定自己要走純 Blob 靜態網站的原生方式，仍建議你在官方設定頁面確認是否有「自訂網域」與「憑證」相關選項。若介面沒有相應功能，就代表你要改用前置服務來完成 HTTPS。

無論選哪條路，你都可以把排查邏輯保持一致：DNS 解析到哪個終端，就由哪個終端提供 TLS 憑證。這也是為什麼有時候「DNS 解析成功了，但 https 還是報錯」——因為解析與憑證是兩層不同工作。

第九章：常見錯誤與排查清單

9.1 解析成功但打不開（404/403/空白）

• 404：可能是 index.html 路徑或名稱不對，或你設定的索引文件不是實際存在的檔案。
• 403：通常是權限或存取層級/網路規則阻擋。
• 空白頁但資源有載：多半是 JS/CSS 的 MIME 類型或路徑相對問題。

排查方式很簡單：先打開瀏覽器開發者工具，查看網路請求是否成功、回傳狀態碼與 Content-Type。

9.2 DNS 生效很慢

• 檢查你改動的 TTL。
• 可先在本機用指令查詢解析是否指向正確的主機名（不同系統命令不同）。
• 避免同時改太多項目，否則你無法判定是哪一步造成問題。

9.3 SPA 深層路徑（刷新後 404）

如果你使用前端路由，例如 example.com/#/route 還好，因為路由在 hash 後面，伺服器不會認為你要存一個真實檔案。但如果你使用 HTML5 history 模式，例如 /about，刷新後伺服器要回應對應資源檔案；若 Blob 沒有 about.html，就容易 404。

解法通常有三種：

• 改用 hash router（若你的產品可接受）。
• 在建置時產生對應的靜態頁（多數 SPA 不建議，因為維護成本高）。
• 用支援 fallback 的前置服務（例如 CDN/Front Door 類）把 404 轉回 index.html。

Azure企業帳號開戶 在不引入前置服務的情況下，SPA 的「深層路徑」體驗很可能不理想。你可以先確認你的需求，再決定要不要多加一層。

第十章：從零到可上線的推薦流程（把步驟串起來）

把上面內容濃縮成一個你可以照做的順序：

1. 建立儲存帳戶。
2. 啟用靜態網站託管，設定 index.html（與 404.html 若需要）。
3. 確認靜態網站主機名可取得。
4. 建立 $web 容器並上傳整套網站檔案（含 assets）。
5. 用 Blob 靜態網站主機名直接測試：首頁、資源、404。
6. Azure企業帳號開戶 在 DNS 新增 CNAME：www 指到 Blob 主機名。
7. 等待 DNS 生效，測試 http://www.yourdomain。
8. 處理 HTTPS：若原生不足，改用合適的 Azure 前置服務完成憑證與 TLS。

第十一章：更貼近實務的細節：檔案快取與更新策略

網站一旦上線，更新頻率可能不高也可能很頻繁。Blob 靜態網站託管對快取行為與標頭（Cache-Control）會影響你是否能「即時生效」。如果你發現更新後使用者仍看到舊版本，常見原因是瀏覽器或中間層快取沒更新。

實務建議：

• 對於更新頻繁的檔案（JS/CSS），建置時使用檔名雜湊（例如 main.abc123.js），讓引用檔案名改變自然打破快取。
• 對於 index.html，可避免極長快取，或在更新流程中確保標頭設定一致。
• 若你使用前置服務（CDN/Front Door），也要一併確認快取規則。

第十二章：常見問題的快速答案

Q1：Blob 靜態網站可以綁根網域嗎？

視你的 DNS 提供商與配置方式而定。許多情況根網域需要轉導到 www，或採用能處理根網域的方案。先確保 www 可用最關鍵。

Q2：綁了 CNAME 為什麼 https 還是失敗？

DNS 只解決「你指到哪個主機」。HTTPS 需要該終端能對你的網域提供有效憑證與 TLS 設定。若憑證沒有覆蓋你的網域，就會出現憑證錯誤或握手失敗。

Q3：為什麼我改了檔案但網站沒更新？

通常是快取。檢查瀏覽器快取或中間層（若有 CDN/前置）。對靜態資源採用雜湊檔名能顯著降低此問題。

結語：把網域與託管串成一套可重複流程

Azure Blob 的靜態網站託管，適合用來快速把前端內容變成可被世界存取的網站。真正讓它像「專案」而不是「一次性 demo」的，是你能否把自訂網域穩定綁上，並在更新時不讓使用者碰到舊快取或路徑錯誤。

當你照著本文的順序做（先驗證 Blob 端點、再做 DNS、最後再處理 HTTPS 與 SPA 路由），你會更容易定位問題，也能把流程複製到下一個網站。等你熟悉一次後，這套架構就會變成你部署靜態前端的固定工具。