nginx至少存在兩種不同的配置來指定錯誤頁面：
使用try_files配置項。
使用error_page配置項。
先介紹使用try_files配置項的情況。
nginx提供的try_files配置允許在乙個location中指定多個潛在的可能的響應頁面，nginx將按照定義的次序依次嘗試訪問這些響應頁面，直到成功訪問該頁面。根據這個機制，可以在try_files配置的頁面列表的最後面加上乙個頁面作為預設的錯誤頁面。
配置內容：
location /abc {
root html;
try_files $uri /404.html;
執行結果：
當請求存在的頁面時，將正常訪問該頁面。當訪問到不存在的頁面時，將跳轉到/404.html頁面，此時瀏覽器位址列url沒變化，但是狀態碼不再是404，而是200。
再介紹使用error_page配置項指定錯誤頁面的情況。
error_page配置項存在以下多種重定向方式，nginx做了不同的處理，實際訪問到頁面也存在一定的差異，而瀏覽器的位址列的表現也存在不同。
下面分別討論在各種不同重定向方式下，訪問同乙個url，而這個url對應的原始頁面不存在的情況下，nginx的處理方式以及瀏覽器的表現。
試驗過程中，瀏覽器中輸入的原始url都是：
這個url對應的頁面並不存在，缺省會按照nginx內建處理方式，產生http 404狀態碼的響應。
在以下討論中，都使用了error_page配置項，但是各自的配置方式稍有不同，因而產生了不同的結果。
(1)重定向到內部頁面。
配置內容：
location /abc {
root html;
error_page 404 /404.html;
執行結果：
將內容為的內容，狀態碼為404，位址列url沒有變化。
(2)重定向到外部頁面
將跳轉到指定的外部伺服器的頁面。
配置內容：
location /abc {
root html;
error_page 404 ;
執行結果：
瀏覽器位址列的url已經變化為error_page指定的url,，http狀態碼為200。
從下圖可以看到變化後的url為：。
在僅僅將error_page指向的頁面從伺服器內部頁面變化為外部伺服器的頁面後，http狀態碼就變化了。
(3)修改http狀態碼。
配置內容：
location /abc {
root html;
error_page 404 = /404.html;
執行結果：
由於使用了error_page 404 = /404.html這種方式，在第(1)種情況的基礎上，加了等於號，處理結果也發生了變化。此時nginx根據/404.html頁面的訪問結果來決定http 狀態碼。由於這裡/404.html頁面是存在的，狀態碼是200。
(4)使用內部重定向。
在nginx的配置檔案中，使用@標記來表達內部跳轉指令,這種指令也可以用於error_page的配置中。
配置內容：
location /abc {
root html;
error_page 404 @notfound;
location @notfound {
proxy_pass
執行結果：
在這種情況下，瀏覽器的位址列url沒有變化，http狀態碼404也沒有變化，顯示的內容是的內容。
總結：(1)關於頁面重新整理與瀏覽器快取：
上述試驗過程中，狀態碼為200的情況時，每次使用瀏覽器傳送請求之前都沒有使用瀏覽器快取。如果使用瀏覽器快取，有些情況下狀態碼為304。chrome瀏覽器不使用瀏覽器快取的方法有兩種：
(a)使用瀏覽器清空歷史記錄的方式來清空快取
(b)使用ctrl+f5來重新整理頁面，而不是使用f5。
(2)nginx支援的另外一種指定錯誤頁面的方式，即使用try_files。
(3)在各種情況下，nginx處理方式稍有不同，瀏覽器上看到的頁面結果也有所不同。
輸入重定向，正確輸出重定向，錯誤輸出重定向
一 標準輸入 stdin a.輸入重定向 標準輸入 作用 將原先鍵盤輸入的內容改由檔案內容代替 root wenwen cat test.txt asdas asdas asdas 按crtl d 退出 將network內容匯入到test.txt中去 root wenwen cat test.txt...
頁面重定向erro miss
訪問頁面是時，出現如下錯誤 遇到這個問題，我先清除 cookies和快取，無效。然後 檢視 public void dofilter servletrequest servletrequest,servletresponse servletresponse,filterchain filtercha...
nginx重定向設定
不久前，公司業務平台上發現使用者訪問公司官方 時，攜帶兩個網域名稱的cookie到後端 分別時domain.com,www.domain.com 為了解決這個問題，首先分析公司對網域名稱的使用是否涉及到domain.com，發現沒有，那就有必要將訪問domain.com的使用者跳轉到www.doma...