AWS國際企業帳號 AWS CloudFront分發配置錯誤排查

前言：先看症狀，再談配置

CloudFront 是一層很強的分發網路，但它也是一層很「會影響結果」的中間件。你在瀏覽器看到的 403、404、502、TLS 錯誤、資源不更新、或是偶發錯誤，往往不是真正的應用問題，而是分發設定讓請求走錯了路、或回應被快取/策略影響。

排查 CloudFront 配置錯誤，最忌諱的是憑感覺逐項調參。更有效的做法是：先把問題具體化，再把線索收集齊全。下面我會用一個「可複用」的思路來帶你走完整個流程：從現象判斷錯誤歸因，到逐項核對設定，最後用對照測試確認修正是否有效。

第一章：建立錯誤地圖（先判斷是哪一類）

1. 用狀態碼和錯誤頁面快速分類

CloudFront 回來的錯誤通常有明顯特徵。你看到的狀態碼與錯誤類型，能直接縮小範圍：

• 403 Forbidden：常見於權限（Signed URL/Cookie、WAF/安全策略）、OAI/OAC 對 S3 權限、或源站回絕。
• 404 Not Found：可能是行為路徑匹配錯誤、源站實際沒有該資源、或重寫/自訂錯誤處理導致誤判。
• 502 Bad Gateway：多為源站連線或 TLS 失敗，或源站返回無效內容。
• 504 Gateway Timeout：源站延遲、連線不通、或源站容量不足。
• TLS/SSL 錯誤：多半與自訂域名、證書、或 Origin TLS 設定（SNI、驗證模式）有關。

你不需要一次就抓到根因，但至少要先把錯誤掛上「可能來源」。

2. 把「是否與路徑/方法有關」記下來

很多 CloudFront 設定問題都與 行為（Behavior） 有關。先問自己兩個問題：

• 錯誤只發生在某些 URL 路徑（例如只有 /api、/static、/media）嗎？
• 錯誤是否只發生在特定 HTTP 方法（GET/HEAD/POST/PUT）？

若是，幾乎可以肯定與「行為的路徑模式」或「允許的 HTTP 方法與快取策略」有直接關係。這會讓你後面的排查方向更準。

3. 確認是否是快取導致的「看似配置錯誤」

CloudFront 的強大之處也是它最常造成誤會的地方。你剛改完源站或策略，結果仍然看見舊內容或舊錯誤頁，這通常是快取沒清乾淨或 TTL 太長。

建議你在排查時分兩種情況處理：

• 需要立即驗證修正：在 CloudFront 做失效（Invalidation）或至少用帶不同查詢參數/禁用快取的方式做對照測試。
• AWS國際企業帳號 錯誤穩定存在：通常不是快取問題，而是行為/源站/權限/網路。

AWS國際企業帳號 第二章：源站（Origin）連線與 TLS 是最常見的坑

1. Origin 指向對了嗎？（域名、端口、協定）

很多人以為自己「已經指向正確的服務」，但實際上 CloudFront 的 Origin 設定包含細節：DNS 名稱、端口、以及協定（HTTP/HTTPS）。任何一個偏差都可能導致 502/504。

你可以用下面方式快速自檢：

• 如果你選的是 Custom Origin（自訂來源），確認協定是 HTTP 還是 HTTPS。
• 確認端口（例如 443 vs 80）是否與源站實際服務一致。
• 確認源站域名解析在 CloudFront 所在網路環境可用（例如私有網域如果沒有走正確的連線路徑，就會超時）。

尤其是源站從 HTTP 改到 HTTPS、或證書更新後，你會看到突然增加的 502。這時第一時間就該盯著 Origin TLS 設定。

2. S3（或其他）與 OAI/OAC：權限是另一個大雷區

如果你的 Origin 是 S3，CloudFront 不是自動擁有存取權。你需要正確的存取機制：

• 使用 Origin Access Identity（OAI） 或 Origin Access Control（OAC）。
• 確認 S3 bucket policy 允許 CloudFront 的 principal 讀取。

常見現象是：你在直連 S3 URL 可以看到內容，但透過 CloudFront 會回 403。這通常不是 CloudFront 行為壞掉，而是 S3 權限沒打通。

排查時不要只看 CloudFront 控制台。你也要看 S3 的 bucket policy 是否真的匹配 CloudFront 的 principal，是否因為更新導致條件失效。

3. 自訂域名與 Origin TLS（SNI、憑證驗證模式）

當你用 HTTPS 來源站，CloudFront 會建立 TLS 連線。此時幾個設定細節會直接影響成敗：

• Origin SSL/TLS 的版本與驗證方式：若你的源站使用特定配置，而 CloudFront 以不相容方式驗證，就會失敗。
• SNI（Server Name Indication）：源站如果是基於虛擬主機（多網域共用同一 IP），但 CloudFront 沒帶正確的 Host/SNI，TLS 憑證就可能對不上。
• AWS國際企業帳號 憑證鏈完整性：有些源站配置導致 CloudFront 無法驗證完整鏈，結果就變 502。

如果你看到的是 TLS 錯誤或 502，建議把「Origin 的實際憑證狀態」也一起檢查。很多問題不是你 CloudFront 的設定，而是源站的證書剛好在某次更新後不再被信任或鏈缺失。

第三章：行為（Behavior）決定路徑與快取邏輯

1. 路徑模式是否命中了你以為的行為？

CloudFront 會依序匹配 Behavior 的 Path pattern，找到符合的那一條。你以為某個請求會走 /static 行為，但實際上卻被另一條更前面的規則接走，結果就會發生：

• 權限行為設定不一致（例如 API 需要不同轉送策略）
• 快取鍵（Cache key）與轉送頭不一致
• 重寫/目錄路徑邏輯跟預期不同

排查方法很直接：在 CloudFront 里臨時用最寬或最明確的 path pattern 做對照，確認特定 URL 真的走到你要的 Behavior。不要只看設定列表，因為順序與匹配規則才是關鍵。

2. HTTP 方法與是否允許非 GET/HEAD

很多團隊把 CloudFront 當純靜態加速器，於是 Behavior 把「允許的方法」限制在 GET/HEAD。可一旦你的前端或服務端需要 POST（例如簽名上傳、表單提交、或特定 API 行為），就會出現 403/405 類型的問題。

你要確認：

• 該 Behavior 是否需要 Allow POST/PUT/PATCH/DELETE？
• 若需要，是否搭配了正確的轉送策略與來源站可接受的方法？
• 如果允許非快取方法，CloudFront 的快取設定是否避免把動態內容錯誤地緩存？

3. 快取策略（Cache policy / Origin request policy）是否一致？

快取問題常常不會用「錯誤狀態碼」呈現，而是用「內容不對」呈現。你可能看到：

• 更新後仍顯示舊版本（快取 TTL 太久或快取鍵不正確）
• 某些用戶看到別人的內容（快取鍵沒有包含必要的標頭或查詢字串）
• API 回應被錯誤快取（尤其是沒有針對動態請求做禁用/差異）

排查時你可以用一個核心原則：

動態內容要明確區分快取鍵；靜態內容要確保 Cache-Control 能正確影響快取。

同時檢查 Origin request policy 是否把必要的參數（例如 Authorization、Cookie、特定自訂 header）轉送到源站。否則源站會看不到上下文，回應就會變成「看起來像權限錯誤」。

第四章：壓縮、HTTP 版本與重定向（看似小，影響卻很大）

1. 壓縮與內容類型（Content-Type）

有些站點在啟用壓縮後出現怪異行為：瀏覽器無法解析、或某些資源大小變大。一般來說這不太會造成 403/502，但可能導致載入失敗。

排查思路是看：

• CloudFront 是否啟用了壓縮（Gzip/Brotli）
• 源站回的 Content-Type 是否正確
• 是否有自訂回應 header 與前端預期不一致

尤其是前端用戶端嚴格依賴 MIME type（例如某些 JS/JSON/wasm），只要 Content-Type 有誤，表面上你會以為是 CloudFront 壞了。

2. HTTP/2 與 HTTP/3：錯誤不是你想的那麼常見，但要會驗證

大部分情況下 HTTP/2/HTTP/3 的問題會反映在連線失敗或性能異常，而不是明確 4xx/5xx。可如果你在源站或安全設備有不相容設定，確實可能影響。

排查建議是做對照測試：同一個 URL，從不同客戶端或用不同網路環境測試，並觀察錯誤是否與特定協定有關。

3. 重定向（Redirect HTTP to HTTPS）與自訂錯誤頁

AWS國際企業帳號 重定向設定最容易造成「看似 CloudFront 錯誤」但實際上是狀態處理流程不同。例如你期望 HTTPS，但瀏覽器先被導到某個 URL，結果來源站或憑證導向不正確。

另外，如果你配置了自訂錯誤回應（例如把 404/403 轉成 index.html），你看到的錯誤頁未必代表真正的狀態碼根因。排查時請同時查看：

• 瀏覽器 Network 的實際狀態碼
• CloudFront 回應的錯誤類型（而不是你看到的前端頁面）

第五章：用日誌與指標把「猜測」變成「定位」

1. 啟用 CloudFront 標準日誌與必要的欄位

AWS國際企業帳號 很多排查在早期就卡住，是因為你沒有可證明的線索。CloudFront 的日誌（標準日誌）可以讓你確認：

• 哪個請求在何時命中了哪個 edge 與哪條 Behavior
• 源站返回的狀態碼（或雲端側錯誤）
• 延遲（TTFB）與錯誤比例

當你看見 502 或 504 的 spikes，日誌能直接告訴你是「源站回應慢」還是「源站根本連不上」。

2. 把錯誤與變更時間對齊（Change correlation）

如果你最近改過：

• 源站證書或域名
• bucket policy 或安全策略
• CloudFront 行為/快取策略
• WAF 規則

你應該立刻把錯誤時間點與變更時間點對齊。排查最怕無限追逐所有可能性。對齊後，通常會出現一個高度可疑的變更。

3. 觀察 TTFB 與快取命中率（錯誤也會受快取影響）

如果錯誤主要出現在某些請求上（例如只對某些 query string 發生），你要檢查快取命中率是否下降，以及 Cache key 是否導致每次都回源站。

你可以把疑點拆成兩句話：

• 如果命中率高但仍錯，通常是回應本身就不對（權限/路徑/策略）。
• 如果命中率低且錯誤集中，通常是回源問題（TLS/連線/源站狀態）。

第六章：常見錯誤案例與對應排查路徑

案例一：所有靜態檔都 403，直接訪問源站正常

AWS國際企業帳號 這類情況最常見在 S3 + OAI/OAC 沒設對，或 bucket policy 沒匹配 CloudFront principal。

排查順序：

1. 在瀏覽器看 CloudFront 回來的狀態碼與錯誤頁面提示（通常能看到是 Access Denied 類型）。
2. 檢查 CloudFront 的 Origin 設定是否使用對的 OAI/OAC。
3. AWS國際企業帳號 回到 S3 bucket policy，確認是否允許 CloudFront 的 principal 進行 s3:GetObject，且條件（如 SourceArn）正確。
4. 做一次失效後再測試，避免仍讀到舊快取錯誤頁。

AWS國際企業帳號 修正要點：權限修正一定要以 S3 bucket policy 為核心，CloudFront 只是一個請求者；沒有權限就會失敗。

案例二：特定路徑（例如 /api）偶發 502 或 504

偶發通常指向「源站壓力」或「連線策略」問題，也可能是特定行為把請求轉送到不正確的源站或端口。

排查順序：

1. 用日誌找出錯誤發生時的 URL 路徑與請求是否一致。
2. 確認這些 URL 是否確實命中同一條 Behavior。
3. 檢查 Origin 端是否允許對應的 Host header、是否需要特定的 Header。
4. 檢查 Origin request policy 是否導致源站缺少必要的 Authorization 或自訂 header。

修正要點：API 類請求的 header/方法轉送設定要非常具體；否則偶發回源超時只是結果，不是原因。

案例三：更新後內容仍顯示舊版本（像沒改）

這是 CloudFront 最常見、也最讓人煩的問題：明明部署了新檔案，卻仍然顯示舊內容。

排查順序：

1. 確認更新的資源是否是同一個 URL（沒有改檔名/沒有 cache-busting）。
2. 檢查 Cache policy 與 TTL 設定，是否過長。
3. 確認源站回應的 Cache-Control、ETag 或其他相關 header 是否符合預期。
4. 執行 Invalidations（針對你更新的路徑）並再測試。

修正要點：靜態資源若採用版本化檔名（如 app.abc123.js），快取策略通常會更穩；動態頁面則避免被長時間快取。

案例四：只有 HTTPS 自訂域名訪問失敗，顯示憑證/連線錯誤

這類問題多半不是 CloudFront 的快取，而是證書與 TLS 相關設定。

排查順序：

1. 檢查 CloudFront 分配的 Alternate domain names（CNAME）是否包含你的網域。
2. 確認使用的 ACM 證書是否處在可用狀態，且涵蓋該網域。
3. 若錯誤發生在回源（Origin）端，檢查 Origin SSL 的 SNI/Host header 設定。
4. 檢查源站證書鏈是否完整，是否在更新後變成不受信任。

修正要點：自訂網域的錯誤要分清楚是「使用者端到 CloudFront」還是「CloudFront 到源站」。兩段 TLS 的設定完全不同。

第七章：一份可落地的排查清單（照做通常就能收斂）

Step 1：先確認錯誤屬性（狀態碼、路徑、方法、是否與快取有關）

• 記下狀態碼（403/404/502/504）
• 記下 URL 路徑與是否固定命中某些行為
• AWS國際企業帳號 確認是 GET 還是也包含 POST/其他方法
• 判斷是否剛做過更新，並考慮快取影響

Step 2：檢查 Origin（網路與 TLS）

• Origin 網域、端口、協議是否正確
• 源站證書是否可用、鏈是否完整
• 若是基於多虛擬主機，SNI/Host header 是否一致
• 若是 S3，bucket policy 與 OAI/OAC 是否正確

Step 3：檢查 Behavior（路徑匹配、方法允許、轉送策略、快取鍵）

• Path pattern 是否命中預期的行為（注意順序與範圍）
• 允許的 HTTP 方法是否覆蓋需求
• Origin request policy 是否轉送了必要 header/cookie/query
• Cache policy 的快取鍵是否包含了動態區分維度

Step 4：用日誌做交叉驗證（避免盲調）

• 看錯誤發生時的來源（回源還是邊緣側）
• 對齊最近變更時間點
• 觀察命中率與 TTFB 是否異常

Step 5：修正後再測試的方式要正確

• 需要時做 Invalidations
• AWS國際企業帳號 用無快取對照（例如不同 query string）觀察差異
• 確認錯誤是否只在特定路徑或特定行為消失

第八章：防呆與最佳化：讓下一次排查更快

1. 把設定拆成「可驗證」的部分

建議你在團隊內建立一個習慣：每次修改 CloudFront，都附帶一個你將用來驗證的指標與測試樣本。例如：

• 某個路徑：/static/app.js
• 某個 API：/api/health（或你實際的測試端點）
• 某些 header/cookie：是否存在 Authorization 或特定 cookie

當問題真的出現時，你只要回到這些樣本，就能很快判斷是哪段設定變更造成。

2. 為動態與靜態內容分開 Behavior

很多事故來自「用同一套 Behavior 服務所有東西」。動態內容（尤其含授權）需要更謹慎的快取鍵和轉送策略；靜態內容則適合較積極的快取策略。

把它們拆開，你不只降低錯誤機率，也讓排查更直觀。

3. 避免把需要授權的資源長時間快取

若你的 API 或頁面依賴 Authorization 或 cookie，就算狀態碼看似正常，也可能造成「用戶串內容」的風險。快取鍵若未包含必要維度，就等於把不同用戶的請求混在一起。

這不是單純的性能問題，而是安全與正確性問題。

結語：排查不是找誰背鍋，而是找到可證明的根因

CloudFront 的配置錯誤看似雜亂，但它們其實有規律：Origin 決定「你能不能連到與取到」，Behavior 決定「你會不會被導到正確的策略」，快取策略決定「你看到的是新還是舊」。再加上日誌與對照測試，你就能把問題從「猜測」變成「定位」。

下一次遇到 403、502、或更新後內容不變時，不要先大改一通。先把錯誤分類、確認行為命中，再檢查 Origin 的 TLS/權限，最後用日誌驗證。只要順序對，排查會快很多，也更不容易踩同樣的坑。