history路由模式下的nginx配置

路由模式

衆所周知，瀏覽器下的單頁面應用的路由模式有下面兩種： hash 模式和 history 模式。hash 模式通用性好，並且不依賴服務器的配置，省心省力，可是缺點是不夠優雅。相比於 hash 模式來講，history 模式則更加美觀。

可是，history 模式一樣會有一個問題，就是當頁面刷新時，若是沒有合適的配置，會出現頁面 404 的錯誤。所以須要額外的服務器配置，對於找不到的 url，將首頁 html 返回。

接下來，我們以 nginx 爲例，來講說 history 模式時須要進行的配置。

location

location 位於 http->server 塊中，語法格式以下：

Syntax: location [= | ~ | ~* | ^~] uri { ... } location @name { ... } Default: — Context: server, location

[= | ~ | ~* | ^~]，是修飾符，能夠控制 nginx 匹配的順序。優先級關於四個修飾符的含義，能夠參考 這篇文章。這裏不過多敘述，總之當一個 server 下面有多個 location 時，nginx 會根據 uri 的精確度和修飾符進行匹配。查找的順序及優先級以下：

查找順序和優先級 1：帶有「=「的精確匹配優先 2：沒有修飾符的, 誰更精確誰優先，如 / 和 /post , 則 post 優先 3：正則表達式按照他們在配置文件中定義的順序 4：帶有 「^~」 修飾符的，開頭匹配 5：帶有「~」 或「~*」 修飾符的，若是正則表達式與 URI 匹配 6：沒有修飾符的，若是指定字符串與 URI 開頭匹配

try_files

try_files 解決的是：當 nginx 找不到客戶端須要的資源時該怎麼辦的問題。以 history 路由爲例：假如你的頁面 url 是 http://www.example.com/post，你的 nginx 配置以下：

location  / {
     root local/web/dist
}

當你在 post 路由下刷新頁面時，nginx 會返回 404。這是什麼緣由呢？由於咱們沒有告訴nginx找不到某個文件時該怎麼作。root 指定了 / 對應的單頁靜態資源目錄，從而使url映射到dist目錄下。

這個配置可讓你項目的 css，js 被順利加載，可是碰到上面的 URL，nginx 就不知所措了。由於咱們的 dist 文件夾下面並無 post 這個文件或者文件夾，因此 nginx 會給你個 404 頁面。try_files 就是爲了解決這個問題的，try_files 語法以下：

location / {
    try_files $uri $uri/ /index.html;
}

以上面的 http://www.example.com/post 爲例，$uri 會匹配到 post，nginx 發現 dist 目錄下下面沒有 post 這個文件，也沒有 post 這個文件夾，因此最後會返回 dist 目錄下的 index.html。這樣，index.html 被瀏覽器加載以後，前端路由就會工做，將用戶須要的資源加載出來。而咱們 build 出來的 css，js 文件，因爲能夠被 nginx 正確找到，則不會受到影響。

alias

當URL的子路徑和文件夾路徑不一致時，可使用alias，參考nginx alias

參考連接

• nginx 配置結構
• server_names
• try_files
• location