使用 Amazon CloudFront 部署錯誤響應頁面

前言

當人們在訪問任何網站時，是不是難免會偶然遇到「404 Not Found」的錯誤頁面呢？就好比 Google 的 Error Page，用戶在搜尋引擎輸入連結後，原本預期可以找到自己想看的網頁，卻得到「404」顯示錯誤的 HTTP Status Code，同時表示「找不到用戶意圖訪問的網頁」。這又是什麼原因造成的呢？而什麼又是 HTTP status code 呢？

圖片來源：Google Error Page

什麼是 HTTP Status Code？

HTTP Status Code 是當網路伺服器為了回應 Client 端對 Server 端發出的 request 時，表示 response 狀態的 3 位數字碼。分別有五種不同的狀態，而每個狀態碼也代表了不同的含義。例如：404 代表 Client 端請求的資源未在 Server 端找到；503 代表 Server 因為臨時的維護或是超載，無法立即處理請求；抑或是 200 代表請求成功，並將回覆 Client 需要的內容。除了上述舉例的 3 種狀態碼，若想了解更多與 HTTP Status Code 相關資訊，可參考：維基百科 – HTTP 狀態碼。

圖片來源至：HTTP 網站代碼 – 301, 302, 404 的差異及對 SEO 的影響

出現 status code: 404 的原因？

造成用戶獲得一個 404 錯誤頁面的可能原因很多，以下簡單整理幾種狀況：

用戶輸入了錯誤的網址：用戶可能在網址末端，額外輸入了一個錯誤的路徑，導致伺服器找不到相符的頁面。
網址改變或重組：網站管理者更改了網頁的路徑。例如：重命名目錄可能需要更改網址。如果網站內部的連結未相應修改，則可能導致用戶無法連結到正確路徑；如果從外部連結，也同樣容易發生 404 錯誤。
網頁已被移除：網頁內容已過期。例如：購物網站因節慶而推出的促銷活動，會在節慶結束過後，移除促銷活動的頁面，如果有用戶讀取先前的活動畫面，就會找不到指定的頁面。
網頁內容轉移到另一個新的網頁：網站更新版本。組織內部改變網站風格，需重新設計新版的網頁，同步改變網頁的網址。如果用戶使用舊版的網址，就會找不到頁面。

為什麼需要設置 404 錯誤頁面？

然而，作為網站的管理者，應盡量避免出現錯誤頁面，但 404 錯誤卻是難免會發生的情況，因此如果未創建 404 錯誤頁面，則容易產生兩個不好的結果：

不佳的使用者體驗：因為用戶並不知道為什麼網址無法使用，因此極有可能直接關閉瀏覽器，並考慮不再訪問該網站。
降低 SEO 的排名：由於 404 表示網站出錯，搜索引擎認為網站無法使用，因此就會給予網站懲罰，將網站的排名就會下降。如此一來，當下次用戶以關鍵字搜尋時，自己的網站就容易出現在後面的排序，降低曝光率。這使得創建 404 錯誤頁面變得更加重要。

與 SEO 相關資訊，可參考：SEO 是什麼？SEO 該怎麼做？一篇就懂 SEO 搜尋引擎優化教學！

使用場景

當網站發生 404 錯誤時，網站管理者可以選擇採取不同的動作，以下舉例三種處理機制：

修改網站伺服器的設定檔：自動將頁面轉址至首頁或是自定義的錯誤頁面。
修改網站程式碼：透過程式碼檢查，當偵測到錯誤發生時，強制將頁面轉址至首頁或是自定義的錯誤頁面。
切換 DNS Server 指向的路徑：如果是改變整體網站域名或是網址結構，也可直接調整 DNS Server 內的 record，讓網址可以導向更動後的路徑。

不論是哪一種做法，皆是希望在發生 404 錯誤時，能維持用戶瀏覽網站的意願，同時減少 SEO 排名下降的可能性。而良好的 404 錯誤頁面除了顯示 404 status code 以外，還可以增加更多互動，例如：加上返回首頁的按鈕、轉往其他用戶可能會感興趣的資訊…等等方法，可讓用戶不至於再看到錯誤代碼後，不知道下一步該怎麼做。

Amazon CloudFront – 自定義 404 錯誤頁面的機制

如果使用者將網站架設在 AWS 平台上，可能使用 Amazon EC2、Amazon S3 作為網站伺服器，同時利用 Amazon CloudFront 替靜態的內容做 Cache，便可以利用 CloudFront Error Pages 的功能來建置 404 錯誤頁面的回應方式。

Amazon CloudFront 提供 Cache 服務的機制：當用戶請求的內容，在 Edge Location 找不到，CloudFront 會遞送請求至 Origin，Origin 會回覆用戶指定的內容給 CloudFront，CloudFront 會再回覆給用戶。

圖片來源至：Amazon CloudFront Documentation – How CloudFront delivers content

CloudFront 可針對不同的 HTTP Status Code 來制定應該要回覆給用戶的頁面，同時也可以改變用戶收到的 HTTP Status Code。例如：當 Origin 回覆 404 錯誤給 CloudFront 時，使用者可以透過 CloudFront Error Pages 的功能，制定 CloudFront 回覆給用戶的內容，像是回覆使用者另一個路徑底下的頁面 (ex: /error/error.html)，或是預先放在另一個 S3 Bucket 裡的 error page。

同理，當 Origin 回覆其他 HTTP Status Code 給 CloudFront 時，也可以回覆其他頁面給用戶。例如：CloudFront 收到 status code: 503，呈現一個「維護中」的靜態頁面給用戶。

實作方式

在本次實作中，我們把網站的首頁以及 404 錯誤頁面放置在兩個不同的 S3 Bucket。正常情況之下，CloudFront 會回覆 Client 端 bucket 1 裡的首頁 (index.html)，但是當 Client 輸入了錯誤的網址，導致發生 404 錯誤時，CloudFront 則會回覆 bucket 2 裡的錯誤頁面 (error.html)，藉此模擬實際 Client 訪問網站的情況。

在創建 CloudFront Distribution 時，會優先指定 bucket 1 為 Origin 位置，而這也就是本次實作中的首頁，使用者可針對個人需求設定 CloudFront 的其他設定。例如：首頁的路徑、是否允許 Client 使用 HTTPS/HTTP 通訊協定、是否允許直接存取 Origin、CloudFront 更新在 Edge Location 物件的頻率 (TTL)…等，那本次實作就選取預設的設定為範例。

創建完成後，直接透過 CloudFront 自動產出的 Domain Name 就可以連結到在 bucket 1 的首頁 (index.html)。那因為在 bucket 1 僅放置了首頁 /index.html 檔案，如果 Client 改變網址 (ex: /index22.html)，就無法在 bucket 1 找到符合的項目，而 bucket 1 便會回覆 CloudFront 404 錯誤。
透過設定 CloudFront – Error Pages 的功能，讓 CloudFront 針對 404 status code，將 Client 導向 /error.html 路徑，也就是 xxxxxxxxx.cloudfront.net/error.html，同時回覆 404 status code。如果在 bucket 1 裡，有 error.html 這份檔案，那麼 CloudFront 就會回覆 bucket 1 裡的錯誤頁面，但這並不是這是實作的目標。

本次實作把 404 錯誤頁面放置在 bucket 2，因此需要在 CloudFront 新增另一個 Origin 為 bucket 2，CloudFront 才知道 bucket 2 在哪，也才能夠抓取到 bucket 2 的 error.html 檔案。

設置好 Origin 後，還需要透過 Behaviors 來作銜接，針對 Client 意圖訪問的路徑，回覆不同 Origin 的內容。預設是將所有的路徑皆導向 bucket 1，也就是初始設定的 Origin，使用者可依據自己存放檔案的方式來客製化。

最後來看一下實作完成的成果吧~

結論

簡單的設置 Amazon CloudFront – Error Pages 的功能，可快速的幫助使用者客製化錯誤響應的動作，不僅有助於提升使用者體驗，在因為透過 Edge Location，也可以在大量請求下，維持低延遲的回覆速度。另外，這項功能除了可以應用在 404 錯誤響應之外，也可以應用在「伺服器例行性維護」的場景之下。當伺服器正在進行維修，使用者可以將任何訪問的請求導向客製化的維護頁面 (ex: maintenance.html)，告知 Client 端「目前系統還不能使用，請於維修後再行訪問」，同時附上維修完成的時間，相信有助於優化使用者體驗。

使用 Amazon CloudFront 部署錯誤響應頁面