Azure帳號認證辦理 Azure Blob 跨域資源共享 CORS 報錯解決辦法
先搞清楚：為什麼 Azure Blob 會出現 CORS 報錯
很多人第一次遇到 Azure Blob 的 CORS 報錯，直覺會以為是前端程式寫錯了。其實不一定。跨域資源共享本來就是瀏覽器的安全機制，當前端網頁、API、儲存體服務三者的網域、協議或埠號不一致時，瀏覽器會先發出預檢請求，確認對方是否允許這個來源存取資源。如果 Azure Blob Storage 沒有正確回應允許規則，就會直接被瀏覽器擋下來。
這類錯誤常見的表現有幾種：網頁顯示 Access-Control-Allow-Origin 相關訊息、預檢請求失敗、某些請求在 Postman 或後端測試時正常，到了瀏覽器卻不行。這也說明了一件事，CORS 問題多半不是 Azure Blob 本身壞掉，而是設定、請求方式與瀏覽器規則之間沒有對上。
要解決它，不能只看錯誤訊息表面，而是要從請求來源、容許方法、標頭、憑證和 Blob 服務的 CORS 規則一起檢查。只要順序對了，大多數問題都能很快定位。
先確認是哪一種跨域情境
Azure Blob 的 CORS 問題，通常不是單一原因，而是情境不同，解法也不同。先分清楚自己遇到的是哪一種，後面才不會亂改一通。
前端直接讀取 Blob 檔案
這是最常見的情況。前端網頁想直接用瀏覽器讀取 Blob 裡的圖片、JSON、影片、PDF，甚至是上傳檔案到 Blob。只要前端所在網域和 Blob 的網域不同，瀏覽器就會要求 Blob 服務提供正確的 CORS 設定。
例如你的網站跑在 https://app.example.com，但 Azure Blob 的網址是 https://storageaccount.blob.core.windows.net，這就已經是跨域了。即使你只是用 fetch 下載一個公開檔案，仍然可能被 CORS 擋住。
前端上傳檔案到 Blob
上傳時更容易出問題，因為上傳通常會觸發 OPTIONS 預檢請求，且請求方法可能是 PUT、POST 或 PATCH。如果 Blob 的 CORS 規則沒有允許這些方法，或者缺少必要標頭，前端就會在真正上傳前失敗。
有些人看到錯誤發生在上傳流程，會先懷疑 SAS Token 不對，但其實很多時候只是 CORS 沒有把 PUT、OPTIONS、Content-Type 等項目放行。
使用 SAS Token 或後端簽發網址
Azure帳號認證辦理 即使你有用 SAS Token，也不代表可以跳過 CORS。SAS 負責的是授權，CORS 負責的是瀏覽器能不能放行。兩者是不同層次的問題。很多人把權限問題解掉後，還是卡在 CORS，就是因為把授權與跨域混為一談。
Azure Blob CORS 設定的核心概念
Azure Blob 的 CORS 規則本質上是在回答瀏覽器三個問題：誰可以來、可以做什麼、可以帶哪些資訊。只要理解這三件事，設定就不會亂。
Allowed origins：允許哪些來源
這裡要填前端網站的來源，不是隨便填完整網址，而是來源的協議、網域與埠號組合。例如 https://app.example.com、http://localhost:3000。如果前端有開發環境、測試環境、正式環境，最好都逐一列出。
一個常見錯誤是只填網域，卻漏掉協議或埠號。瀏覽器看的是完整 origin，不是單純的 domain。也就是說 http://localhost:3000 和 http://localhost:5173 是兩個不同來源，必須分開處理。
Allowed methods：允許哪些請求方法
如果前端只是讀取檔案，通常只需要 GET，但只要有上傳、更新、刪除，就可能需要 PUT、POST、DELETE。另外，瀏覽器預檢時還會用到 OPTIONS，這一項常常被忽略。
如果你只允許了 GET，那麼前端雖然看起來只是想上傳一張圖，實際上在預檢階段就會被擋。這也是為什麼很多 CORS 錯誤看似發生在實際請求之前。
Allowed headers：允許哪些標頭
實際開發中，前端常會帶上 Content-Type、Authorization、x-ms-blob-type、x-ms-version 等標頭。如果 Azure Blob 的 CORS 規則沒有允許這些標頭，預檢請求就可能失敗。
最保險的作法，是先從實際需求出發，把會用到的標頭列清楚，再逐步縮小範圍。不要一開始就憑印象設定，否則很容易少一個關鍵欄位。
Exposed headers：前端可以讀到哪些回應標頭
這一項常被忽略，但在某些情況下很重要。前端如果要讀取回應中的特定標頭，例如檔案大小、ETag 或版本資訊，就必須把這些標頭放進可暴露清單。否則伺服器雖然有回傳，瀏覽器仍然不讓 JavaScript 直接讀取。
Max age：預檢結果快取多久
預檢請求每次都打到伺服器，會增加延遲。設定 Max age 可以讓瀏覽器暫時快取通過結果，減少重複預檢。不過在除錯階段，這個值不宜過大，否則你改了設定，瀏覽器還會沿用舊結果，讓你誤以為設定沒生效。
最常見的 Azure Blob CORS 報錯原因
實務上，大部分錯誤都能歸到幾個固定原因。先把這些坑排掉，通常就成功一半。
Azure帳號認證辦理 來源寫錯，尤其是 localhost 與正式網域
很多人測試時在本機環境設定了 https://localhost:3000，實際前端卻是 http://localhost:3000。少了協議一致性，CORS 就不會過。還有人把 127.0.0.1 和 localhost 混用，這兩者在瀏覽器看來也是不同 origin。
如果是多環境開發，建議把所有會出現的來源整理成清單，逐一比對，避免漏掉某個測試網址。
Azure帳號認證辦理 只允許 GET，卻忘了 OPTIONS
這是非常典型的錯誤。很多人以為自己只是送出 GET 請求，CORS 規則只要允許 GET 就夠了。事實上，瀏覽器可能先送出 OPTIONS 預檢。如果 OPTIONS 不在允許方法內，真正的請求根本不會發出。
Azure帳號認證辦理 尤其是帶自訂標頭、使用非簡單請求方法、或 Content-Type 不是常見表單類型時，預檢更容易出現。這也是為什麼有些 API 在同一個前端頁面中，一部分正常，一部分失敗。
標頭不完整
如果你在上傳時使用 x-ms-blob-type，卻沒有把它加入允許標頭，Azure 就算授權沒問題，瀏覽器也會擋。Authorization 也是常見項目，尤其是用 SAS Token、Bearer Token 或其他自訂驗證流程時。
要注意的是，某些前端框架或 SDK 會自動補一些標頭，你不一定在程式碼裡明寫，但它還是會出現在實際請求中。除錯時要看瀏覽器 Network 面板中的實際請求內容，不要只看原始程式碼。
使用了通配符，但搭配憑證時失效
如果請求需要攜帶憑證，例如 cookie 或某些認證資訊，瀏覽器對 Access-Control-Allow-Origin 的要求會更嚴格，不能隨便用萬用字元。很多人以為填 * 最省事，但在帶憑證的跨域場景下，這常常直接失效。
所以不要把 * 當成萬能解法。開發測試時可以暫時放寬，但正式環境最好明確列出來源，兼顧安全與可維護性。
正確的排查順序
處理 CORS，最怕一邊改前端、一邊改 Azure，最後根本不知道是哪個環節修好的。比較有效率的方法，是照順序排查。
第一步：先看瀏覽器 Network
打開瀏覽器開發者工具，找到失敗的請求。先確認是 OPTIONS 失敗，還是正式請求失敗。如果 OPTIONS 就已經被擋，問題大多在 CORS 規則。如果 OPTIONS 通過，但正式請求失敗，則要進一步看授權、網址、SAS Token 或回應內容。
同時檢查請求中的 Origin、Request Method、Request Headers，以及回應裡有沒有出現 Access-Control-Allow-Origin 等標頭。這些資訊比錯誤彈窗更有用。
第二步：確認 Azure Blob 的 CORS 規則是否生效
在 Azure Portal 的 Blob Service CORS 設定中，檢查規則是否已經保存，是否對應到正確的儲存體帳戶。很多人其實改的是另一個環境的 storage account，尤其在測試、正式帳號名稱相近時很容易搞混。
如果使用 Azure CLI 或部署腳本，也要確認更新是否真的成功，沒有被後續腳本覆蓋。
第三步：逐項比對來源、方法、標頭
把前端實際送出的 Origin、Method、Headers 與 Azure CORS 設定逐一對照。這一步最笨，但最有效。很多問題其實就是某個字母、某個協議、某個埠號寫錯。
如果前端是在本機開發，建議把常見的幾個本機來源都加上，例如 http://localhost:3000、http://localhost:5173、http://127.0.0.1:3000，避免切換專案時反覆踩雷。
一個實用的設定範例思路
不同專案需求不一樣，沒有放諸四海皆準的唯一規則，但可以用一個務實的思路來設定：先滿足開發與正式環境的必要來源，再縮小方法與標頭範圍。
例如前端網站有正式網域與本機開發環境，使用情境包含圖片讀取與檔案上傳，那麼你至少要考慮以下幾件事：
- 允許正式前端來源與本機開發來源。
- 讀取檔案時允許
GET。 - 上傳檔案時允許
PUT或POST，並保留OPTIONS。 - 允許實際會用到的標頭，例如
Content-Type、Authorization、x-ms-blob-type。 - 若前端需要讀取回應中的特定資訊，將必要回應標頭加入 exposed headers。
這樣的設定不是為了貪多，而是避免一開始就因為規則過窄而無法運作。等功能穩定後，再依實際需求收斂權限。
別把 CORS 和權限問題混在一起
這是除錯時最容易走偏的地方。CORS 報錯看起來像是不能存取資源，但實際上可能有兩層問題：一層是瀏覽器不允許跨域，另一層是 Azure 本身拒絕授權。兩者訊息很像，處理方式完全不同。
如果是 CORS 問題，通常瀏覽器控制台會直接提示跨域被阻擋，Network 也會看到預檢請求失敗。如果是授權問題，可能會收到 403、AuthenticationFailed、AuthorizationPermissionMismatch 之類的回應。不要只看最終畫面，要看實際 HTTP 狀態與回應內容。
實務上，最穩的做法是先讓 CORS 通過，再檢查 SAS Token、存取權限、容器公開層級與帳號策略。照這個順序，除錯效率會高很多。
常見誤區與修正方式
Azure Blob 的 CORS 設定不難，難的是容易被幾個小誤區拖住。下面這些情況很常見，值得特別注意。
誤以為設定完立刻生效
雖然多數情況下 Azure 設定更新很快，但前端瀏覽器也可能快取預檢結果。如果你剛改完規則卻還是錯，先清除快取、開無痕模式或重新整理後再測，避免被舊結果誤導。
誤以為公開容器就不需要 CORS
容器公開只代表資源是否能被匿名讀取，並不代表瀏覽器就會放行跨域。公開與跨域是兩回事。即使 Blob 檔案已經是公開的，前端 JavaScript 從另一個網域讀取時，仍然可能因為 CORS 被擋。
誤以為所有前端都只需要一條規則
如果你有多個前端應用、不同環境、不同子網域，通常不會只靠一條規則就能解決。尤其是公司內部系統、測試站、正式站並存時，應該把來源拆開列清楚，避免日後新增頁面又出現新問題。
實戰檢查清單
如果你現在正卡在 Azure Blob CORS 報錯，可以直接照下面順序檢查：
- 確認前端實際 origin 是什麼，包括協議、網域與埠號。
- 到 Azure Blob 的 CORS 設定中，確認該 origin 是否存在。
- 確認允許的方法包含
OPTIONS與實際請求方法。 - Azure帳號認證辦理 確認允許標頭包含實際送出的
Content-Type、Authorization、x-ms-blob-type等欄位。 - 確認是否需要 exposed headers。
- 確認是否因預檢快取而看見舊設定。
- 確認這不是 SAS Token、權限或容器層級的授權錯誤。
這份清單看起來簡單，但實際上非常管用。很多看似複雜的報錯，最後都只是其中一個欄位漏填。
結語：把 CORS 當成規則比對問題，不要當成玄學
Azure Blob 的 CORS 報錯，本質上不是難題，而是細節題。它不需要猜，也不該靠運氣。只要先弄清楚前端實際發出的 origin、方法與標頭，再回到 Blob 的 CORS 規則逐項比對，大多數問題都能快速定位。
真正有效的除錯方式，不是盲目改設定，而是先分清楚是跨域問題、授權問題，還是快取造成的假象。當你能把這三層分開看，Azure Blob 的 CORS 就不再是阻礙，而只是部署流程中的一個固定步驟。
如果你之後還要把 Blob 用在上傳、下載、縮圖預覽、前端直連儲存體等場景，建議一開始就把 CORS 規則整理好。前期多花十分鐘，後面就能少掉很多來回排查的時間。
