欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Nginx靜態(tài)資源服務(wù)器的實現(xiàn)示例

 更新時間:2024年08月18日 09:51:06   作者:wtrees_松陽  
靜態(tài)資源即非服務(wù)器動態(tài)生成的文件,本文主要介紹了Nginx靜態(tài)資源服務(wù)器的實現(xiàn)示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

靜態(tài)資源

靜態(tài)資源即非服務(wù)器動態(tài)生成的文件。
常見靜態(tài)資源類型:

  • 瀏覽器端渲染:HTML、CSS、JS
  • 圖片:JPEG、GIF、PNG
  • 視頻:FLV、MPEG
  • 文件:TXT 等任意下載文件

基本配置

Web 服務(wù)器一個重要的功能是服務(wù)靜態(tài)文件(圖像或靜態(tài) HTML 頁面)。例如,Nginx 可以很方便的讓服務(wù)器從 /data/www 獲取 html 文件,從 /data/images 獲取圖片來返回給客戶端,這只需要在 http 塊指令中的 server 塊指令中設(shè)置兩個 location 塊指令。

首先,創(chuàng)建 /data/www 目錄,并放入 index.html,創(chuàng)建 /data/images 目錄并在其中放置一些圖片。

接下來,打開配置文件。 創(chuàng)建一個 server 塊:

http {
    server {
    }
}

通常,配置文件可以包括多個 server 塊,它們以 端口 和 服務(wù)器名稱 來區(qū)分。當(dāng) Nginx 決定某一個 server 處理請求后,它將請求頭中的 URI 和 server 塊中的 location 塊進行對比。

加入 location 塊指令到 server 中:

將以下 location 塊添加到 server 塊:

location / {
  root /data/www;
}

上面的 location 塊指定 / 前綴與請求中的 URI 對比。對于匹配的請求,URI 將被添加到 root 指令中指定的路徑,即 /data/www,以此形成本地文件系統(tǒng)的路徑,如訪問 http://localhost/bog/welcome.html,對應(yīng)服務(wù)器文件路徑為 /data/www/bog/welcome.html。 如果 URI 匹配多個 location 塊,Nginx 采用 最長前綴匹配原則(類似計算機網(wǎng)絡(luò)里面的 IP 匹配), 上面的 location 塊前綴長度為 1,因此只有當(dāng)所有其他 location 塊匹配時,才使用該塊。

接下來,添加第二個位置塊:

location /images/ {
  root /data;
}

它將匹配以 /images// 也匹配這樣的請求,但具有較短的前綴)開始的請求。

server 塊的最終配置如下:

server {
  location / {
    root /data/www;
  }

  location /images/ {
      root /data;
  }
}

到目前為止,這已經(jīng)是一個可以正常運行的服務(wù)器,它監(jiān)聽端口 80,并且可以在本地計算機上訪問 http://localhost/。 對于 /images/ 開頭的請求,服務(wù)器將從 /data/images 目錄發(fā)送文件。 如,對于 http://localhost/images/example.png 請求,nginx 將響應(yīng) /data/images/example.png 文件。 如果不存在,Nginx 將返回 404。URI 不以 /images/ 開頭的請求將映射到 /data/www 目錄。 例如,對于 http://localhost/some/example.html 請求,Nginx 將響應(yīng) /data/www/some/example.html 文件。

簡易配置

# 虛擬主機server塊
server {
    # 端口
    listen   8080;
    # 匹配請求中的host值
    server_name  localhost;

    # 監(jiān)聽請求路徑
    location / {
        # 查找目錄
        root /source;
        # 默認(rèn)查找
        index index.html index.htm;
    }
}

說明相關(guān)配置字段:

  • server:配置虛擬主機的相關(guān)參數(shù),可以有多個
  • server_name:通過請求中的 host 值,找到對應(yīng)的虛擬主機的配置
  • location:配置請求路由,處理相關(guān)頁面情況
  • root:查找資源的路徑

配置完成后執(zhí)行 nginx -t 看是否有錯誤,如果看到的是下面這種就是成功:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

然后執(zhí)行 nginx -s reload 更新 Nginx 配置文件

文件讀取配置

http {
  # 調(diào)用 sendfile 系統(tǒng)傳輸文件,開啟高效傳輸模式
  # sendfile 開啟的情況下,提高網(wǎng)絡(luò)包的傳輸效率(等待,一次傳輸)
  sendfile      on;

  # 減少網(wǎng)絡(luò)報文段的數(shù)量
  tcp_nopush    on;

  # 與 tcp_nopush 相反
  # tcp_nodelay off;
}

在 Keep-Alive 連接下,提高網(wǎng)絡(luò)包的傳輸實時性。

文件壓縮配置

開發(fā)過程中難免用到一些成熟的框架,或者插件,這些外部的依賴,有時候體積比較大,導(dǎo)致頁面響應(yīng)緩慢,我們可以用打包工具(Webpack、rollup),將代碼進行壓縮,以縮小代碼體積。 開啟 Nginx Gzip 壓縮功能。需要注意的是 Gzip 壓縮功能需要瀏覽器跟服務(wù)器都支持,即服務(wù)器壓縮,瀏覽器解析。

Nginx 配置 gzip

server {
    # 開啟 gzip 壓縮(默認(rèn) off)
    gzip on;

    # 設(shè)置壓縮文件的類型(text/html)
    gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/json application/xml;

    # 設(shè)置 gzip 所需的 HTTP 協(xié)議最低版本(HTTP/1.1, HTTP/1.0)
    gzip_http_version 1.1;

    # 設(shè)置壓縮級別,壓縮級別越高壓縮時間越長  (1-9)
    gzip_comp_level 4;

    # 設(shè)置壓縮的最小字節(jié)數(shù), 頁面 Content-Length 獲取
    gzip_min_length 1000;
}
  • gzip_types:要采用 gzip 壓縮的 MIME 文件類型,其中 text/html 被系統(tǒng)強制啟用;
  • gzip_static:默認(rèn) off,該模塊啟用后,Nginx 首先檢查是否存在請求靜態(tài)文件的 gz 結(jié)尾的文件,如果有則直接返回該 .gz 文件內(nèi)容;
  • gzip_proxied:默認(rèn) off,Nginx 做為反向代理時啟用,用于設(shè)置啟用或禁用從代理服務(wù)器上收到相應(yīng)內(nèi)容 gzip 壓縮;
  • gzip_vary:用于在響應(yīng)消息頭中添加 Vary:Accept-Encoding,使代理服務(wù)器根據(jù)請求頭中的 Accept-Encoding 識別是否啟用 gzip 壓縮;
  • gzip_comp_levelgzip 壓縮比,壓縮級別是 1-9,1 壓縮級別最低,9 最高,級別越高壓縮率越大,壓縮時間越長,建議 4-6;
  • gzip_buffers:獲取多少內(nèi)存用于緩存壓縮結(jié)果,16 8k 表示以 8k*16 為單位獲得;
  • gzip_min_length:允許壓縮的頁面最小字節(jié)數(shù),頁面字節(jié)數(shù)從 header 頭中的 Content-Length 中進行獲取。默認(rèn)值是 0,不管頁面多大都壓縮。建議設(shè)置成大于 1k 的字節(jié)數(shù),小于 1k 可能會越壓越大;
  • gzip_http_version:默認(rèn) 1.1,啟用 gzip 所需的 HTTP 最低版本;

查看配置是否生效,查看響應(yīng)頭中的 Content-Encoding 字段,值為 gzip

注意:一般 gzip 的配置建議加上 gzip_min_length 1k,否則會因為文件太小,壓縮后體積還比壓縮之前體積還大,所以最好設(shè)置 1kb 的文件就不要 gzip 壓縮了。

Webpack 的 gzip 配置

當(dāng)前端項目使用 Webpack 進行打包的時候,也可以開啟 gzip 壓縮:

// vue-cli3 的 vue.config.js 文件
const CompressionWebpackPlugin = require('compression-webpack-plugin')

module.exports = {
  // gzip 配置
  configureWebpack: config => {
    if (process.env.NODE_ENV === 'production') {
      // 生產(chǎn)環(huán)境
      return {
        plugins: [new CompressionWebpackPlugin({
          test: /\.js$|\.html$|\.css/,    // 匹配文件名
          threshold: 10240,               // 文件壓縮閾值,對超過10k的進行壓縮
          deleteOriginalAssets: false     // 是否刪除源文件
        })]
      }
    }
  },
  ...
}

既然已經(jīng)有 Nginx 的 gzip 壓縮了,為什么還需要 Webpack 進行 gzip 壓縮?

因為如果全都是使用 Nginx 來壓縮文件,會耗費服務(wù)器的計算資源,如果服務(wù)器的 gzip_comp_level 配置的比較高,就更增加服務(wù)器的開銷,相應(yīng)增加客戶端的請求時間,得不償失。如果壓縮的動作在前端打包的時候就做了,把打包之后的高壓縮等級文件作為靜態(tài)資源放在服務(wù)器上,Nginx 會優(yōu)先查找這些壓縮之后的文件返回給客戶端,相當(dāng)于把壓縮文件的動作從 Nginx 提前給 Webpack 打包的時候完成,節(jié)約了服務(wù)器資源,所以一般推介在生產(chǎn)環(huán)境應(yīng)用 Webpack 配置 gzip 壓縮。

瀏覽器緩存

瀏覽器緩存是為了加速瀏覽,瀏覽器在用戶磁盤上,對最近請求過的文檔進行存儲。當(dāng)訪問者再次請求這個頁面時,瀏覽器就可以從本地磁盤顯示文檔,這樣,就可以加速頁面的閱覽,緩存的方式節(jié)約了網(wǎng)絡(luò)的資源,提高了網(wǎng)絡(luò)的效率。

瀏覽器緩存可以通過添加 expires 和 cache-control 頭來實現(xiàn)。

HTTP 協(xié)議的 Cache -Control 指定請求和響應(yīng)遵循的緩存機制。在請求消息或響應(yīng)消息中設(shè)置 Cache-Control 并不會影響另一個消息處理過程中的緩存處理過程。

  • 請求時的緩存指令:no-cache、no-storemax-age、max-stale、min-freshonly-if-cache 等
  • 響應(yīng)消息中的指令:public、privateno-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age

設(shè)置絕對過期時間

設(shè)置以分鐘為單位的絕對過期時間, 優(yōu)先級比 Cache-Control 低, 同時設(shè)置 Expires 和 Cache-Control 則后者生效。也就是說要注意一點: Cache-Control 的優(yōu)先級高于 Expires。

expires 起到控制頁面緩存的作用,合理配置 expires 可以減少很多服務(wù)器的請求,expires 的配置可以在 HTTP 段中或者 server 段中或者 location 段中。比如控制圖片等過期時間為 30 天, 可以配置如下:

# 對 html 文件緩存 24 小時
location ~ .*\.(htm|html)$ {
  expires 24h;

  root /var/www/html;
}

# 對常見格式的圖片在瀏覽器本地緩存 30 天
location ~ .*\.(gif|jpg|jpeg|png|bmp|ico)$ {
  expires 30d;

  root /var/www/img/
}

# 設(shè)置無限的緩存時間
location ~ \.(wma|wmv|asf|mp3|mmf|zip|rar|swf|flv)$ {
  expires max;

  root /var/www/upload/;
}

設(shè)置相對過期時間

Cache-Control 通用消息頭字段被用于在 HTTP 請求和響應(yīng)中通過指定指令來實現(xiàn)緩存機制。緩存指令是單向的, 這意味著在請求設(shè)置的指令,在響應(yīng)中不一定包含相同的指令。

指令不區(qū)分大小寫,并且具有可選參數(shù),可以用令牌或者帶引號的字符串語法。多個指令以逗號分隔。

  • 可緩存性
    • public: 表明響應(yīng)可以被任何對象(包括:發(fā)送請求的客戶端,代理服務(wù)器,等等)緩存。表示相應(yīng)會被緩存,并且在多用戶間共享。默認(rèn)是 public
    • private:表明響應(yīng)只能被單個用戶緩存,不能作為共享緩存(即代理服務(wù)器不能緩存它),可以緩存響應(yīng)內(nèi)容。響應(yīng)只作為私有的緩存,不能在用戶間共享。如果要求 HTTP 認(rèn)證,響應(yīng)會自動設(shè)置為 private
    • no-cache: 在釋放緩存副本之前,強制高速緩存將請求提交給原始服務(wù)器進行驗證。指定不緩存響應(yīng),表明資源不進行緩存。但是設(shè)置了 no-cache 之后并不代表瀏覽器不緩存,而是在緩存前要向服務(wù)器確認(rèn)資源是否被更改。因此有的時候只設(shè)置 no-cache 防止緩存還是不夠保險,還可以加上 private 指令,將過期時間設(shè)為過去的時間
    • only-if-cached:表明客戶端只接受已緩存的響應(yīng),并且不要向原始服務(wù)器檢查是否有更新的拷貝
  • 到期
    • max-age=<seconds>:設(shè)置緩存存儲的最大周期,超過這個時間緩存被認(rèn)為過期(單位秒)。與 Expires 相反,時間是相對于請求的時間。max-age 會覆蓋掉 Expires
    • s-maxage=<seconds>:覆蓋 max-age 或者 Expires 頭,但是僅適用于共享緩存(比如各個代理),并且私有緩存中它被忽略。也就是說 s-maxage 只用于共享緩存,比如 CDN 緩存(s -> share)。與 max-age 的區(qū)別是:max-age 用于普通緩存,而 s-maxage 用于代理緩存。如果存在 s-maxage,則會覆蓋 max-age 和 Expires
    • max-stale[=<seconds>]:表明客戶端愿意接收一個已經(jīng)過期的資源。 可選的設(shè)置一個時間(單位秒),表示響應(yīng)不能超過的過時時間
    • min-fresh=<seconds>: 表示客戶端希望在指定的時間內(nèi)獲取最新的響應(yīng)
    • stale-while-revalidate=<seconds>:表明客戶端愿意接受陳舊的響應(yīng),同時在后臺異步檢查新的響應(yīng)。秒值指示客戶愿意接受陳舊響應(yīng)的時間長度
    • stale-if-error=<seconds>:表示如果新的檢查失敗,則客戶愿意接受陳舊的響應(yīng)。秒數(shù)值表示客戶在初始到期后愿意接受陳舊響應(yīng)的時間
  • 重新驗證和重新加載
    • must-revalidate:緩存必須在使用之前驗證舊資源的狀態(tài),并且不可使用過期資源。表示如果頁面過期,則去服務(wù)器進行獲取
    • proxy-revalidate:與 must-revalidate 作用相同,但它僅適用于共享緩存(例如代理),并被私有緩存忽略
    • immutable:表示響應(yīng)正文不會隨時間而改變。資源(如果未過期)在服務(wù)器上不發(fā)生改變,因此客戶端不應(yīng)發(fā)送重新驗證請求頭(例如 If-None-Match 或 If-Modified-Since)來檢查更新,即使用戶顯式地刷新頁面
  • 其他
    • no-store:緩存不應(yīng)存儲有關(guān)客戶端請求或服務(wù)器響應(yīng)的任何內(nèi)容。表示絕對禁止緩存!
    • no-transform: 不得對資源進行轉(zhuǎn)換或轉(zhuǎn)變。Content-Encoding、Content-Range 和 Content-Type 等 HTTP 頭不能由代理修改。例如,非透明代理可以對圖像格式進行轉(zhuǎn)換,以便節(jié)省緩存空間或者減少緩慢鏈路上的流量。 no-transform 指令不允許這樣做。

設(shè)置相對過期時間, max-age 指明以秒為單位的緩存時間. 若對靜態(tài)資源只緩存一次, 可以設(shè)置 max-age 的值為 315360000000(一萬年)。比如對于提交的訂單,為了防止瀏覽器回退重新提交,可以使用 Cache-Control 之 no-store 絕對禁止緩存,即便瀏覽器回退依然請求的是服務(wù)器,進而判斷訂單的狀態(tài)給出相應(yīng)的提示信息!

# 匹配 URI 時返回的靜態(tài)資源緩存 3600 毫秒
if ($request_uri ~* "^/$|^/search/.+/|^/company/.+/") {
   add_header    Cache-Control  max-age=3600;
}

# 應(yīng)用中不會改變的文件,通??梢栽侔l(fā)送響應(yīng)頭前添加積極緩存
location ~* \.(js|css|png|jpg|gif)$ {
    add_header  Cache-Control public,max-age=31536000;
}

# 緩存前要向服務(wù)器確認(rèn)資源是否被更改
location ~* \.(js|css|png|jpg|gif)$ {
    add_header  Cache-Control no-cache;
}

# 禁止緩存
location ~* \.(js|css|png|jpg|gif)$ {
    add_header  Cache-Control no-store,no-cache,must-revalidate;
}

特別區(qū)分:

  • no-cache:瀏覽器和緩存服務(wù)器都不應(yīng)該緩存頁面信息
  • no-store: 請求和響應(yīng)的信息都不應(yīng)該被存儲在對方的磁盤系統(tǒng)中

資源最后修改時間

該資源的最后修改時間,在瀏覽器下一次請求資源時,瀏覽器將先發(fā)送一個請求到服務(wù)器上, 并附上 If-Unmodified-Since 頭來說明瀏覽器所緩存資源的最后修改時間, 如果服務(wù)器發(fā)現(xiàn)沒有修改, 則直接返回 304(Not Modified)回應(yīng)信息給瀏覽器(內(nèi)容很少),如果服務(wù)器對比時間發(fā)現(xiàn)修改了,則照常返回所請求的資源。

需要注意:

  • Last-Modified 屬性通常和 Expires 或 Cache-Control 屬性配合使用, 因為即使瀏覽器設(shè)置緩存, 當(dāng)用戶點擊 刷新 按鈕時, 瀏覽器會忽略緩存繼續(xù)向服務(wù)器發(fā)送請求, 這時 Last-Modified 將能夠很好的減小回應(yīng)開銷
  • ETag 將返回給瀏覽器一個資源 ID, 如果有了新版本則正常發(fā)送并附上新 ID,否則返回 304,但是在服務(wù)器集群情況下,每個服務(wù)器將返回不同的 ID,因此不建議使用 ETag

資源緩存策略

瀏覽器緩存 Header:expires、cache-control、last-modified、etag。

  • 200 狀態(tài):當(dāng)瀏覽器本地沒有緩存或者下一層失效時,或者用戶強制刷新時,瀏覽器直接去服務(wù)器獲取最新資源
  • 304 狀態(tài):由 Last-Modified / Etag 控制。當(dāng)下一層失效時活用戶刷新時,瀏覽器就會發(fā)送請求給服務(wù)器,如果服務(wù)端沒有變更,則返回 304 給瀏覽器
  • 200 狀態(tài)(from cache):由 Expires / Cache-Control 控制,Expires 是絕對時間,Cache-Control 是相對時間,兩者都存在時,Cache-Control 覆蓋 Expires 只要沒有失效,瀏覽器只訪問自己的緩存

通用策略:

  • 對于 HTML 文件,cache-control 設(shè)置為 no-cache
  • 對于 JS、圖片、CSS、字體等,設(shè)置 max-age=2592000,也就是 30 天
location ~ .* \.(js)$ {
  add_header Cache-Control public;

  expires 24h;
}

location ~ .* \.(css)$ {
  add_header Cache-Control public;

  expires 86400;

  etag on;
}

location ~ .*\(gif|jpg|jpeg|png)$ {
  add_header Cache-Control must-revalidate;

  etag on;
}

集群分布式部署建議關(guān)閉 Etag,因為每臺機器生成的 Hash 是不同的。

配置 CORS 跨域訪問

假設(shè)有兩個域名 mrsingsing.com 和 api.mrsingsing.com,如果 mrsingsing.com 域名想請求 api.mrsingsing.com 域名下的資源會因為 host 不一致存在跨域的問題。

反向代理解決跨域

為了繞開瀏覽器的跨域安全限制,需要將請求的域名由 api.mrsingsing.com 改為 mrsingsing.com。同時約定 URL 規(guī)則來表明代理請求的身份,然后 Nginx 通過匹配該規(guī)則,將請求代理回原來的域。

server {
    listen 9001;
    server_name mrsingsing.com;

    location / {
        proxy_pass api.mrsingsing.com;
    }
}

這里對靜態(tài)文件的請求和后端服務(wù)的請求都以 mrsingsing.com 開始,不易區(qū)分,所以通常為了實現(xiàn)對后端服務(wù)請求的統(tǒng)一轉(zhuǎn)發(fā),通常我們會約定對后端服務(wù)的請求加上 /api/ 的前綴或者其他的 path 來和靜態(tài)資源的請求加以區(qū)分:

# 請求跨域,約定代理后端服務(wù)請求 path 以 /api/ 開頭
location ^~/api/ {
    # 這里重寫了請求,講正則匹配中的一個分組的 path 拼接到真正的請求后面,并用 break 停止后續(xù)匹配
    rewrite ^/api/(.*)$ /$1 break;
    poxy_pass api.mrsingsing.com;

    # 兩個域名之間 Cookie 的傳遞與回寫
    proxy_cookie_domain api.mrsingsing.com mrsingsing.com;
}

這樣其實是通過 Nginx,用類似于 Hack 的方式規(guī)避了瀏覽器的跨域限制,實現(xiàn)了跨域訪問。

這樣,靜態(tài)資源我們使用 mrsingsing.com/index.html,動態(tài)資源我們使用 mrsingsing.com/api/getOrderList,瀏覽器頁面看起來仍然訪問的前端服務(wù)器,繞過了瀏覽器的通源策略,畢竟我們看起來并沒有跨域。

配置 header 解決跨域

在 Nginx 配置中配置對應(yīng)二級域名 api.mrsingsing.com

# /etc/nginx/conf.d/api.mrsingsing.com.conf

server {
    listen       80;
    server_name  api.mrsingsing.com;

    add_header 'Access-Control-Allow-Origin' $http_origin;                              # 全局變量獲得當(dāng)前請求 origin,帶 Cookie 的請求不支持 *(通配符)
    add_header 'Access-Control-Allow-Credentials' 'true';                               # 為 true 可帶上 cookie
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';                     # 允許請求方法
    add_header 'Access-Control-Allow-Headers' $http_access_control_request_headers;     # 允許請求的 header,可以為 *(通配符)
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Max-Age' 1728000;                                    # OPTIONS 請求的有效期,在有效期內(nèi)不用發(fā)出另一條預(yù)檢請求
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;

        return 204;  # 200 也可以
    }

    location / {
        root  /usr/share/nginx/html/be;
        index index.html;
    }
}

防盜鏈

防盜鏈機制的目的是防止服務(wù)器上的資源(例如圖片、文件等)被其它用戶采用其它的技術(shù)手段來訪問或下載。

實現(xiàn)方式:區(qū)別哪些請求是非正常的用戶請求

基于 http_refer 防盜鏈配置模塊:

location ~* \.(gif|jpg|png|jpeg)$ {
    # 只允許 192.168.0.1 請求資源
    # none 表示沒帶 refer
    # blocked 表示不是標(biāo)準(zhǔn) HTTP 請求
    valid_referers none blocked 192.168.0.1;

    if ($invalid_referer) {
        rewrite ^/ http://$host/logo.png;
    }
}
  • 設(shè)置防盜鏈文件類型,自行修改,每個后綴用 | 符號分隔
  • 允許文件鏈出的域名白名單,自行修改成己方域名,域名與域名之間使用空格隔開

圖片處理

在前端開發(fā)中,經(jīng)常需要不同尺寸的圖片?,F(xiàn)在的云儲存基本對圖片都提供有處理服務(wù)(一般是通過在圖片鏈接上加參數(shù))。其實用 Nginx,可以通過幾十行配置,搭建出一個屬于自己的本地圖片處理服務(wù),完全能夠滿足日常對圖片的裁剪/縮放/旋轉(zhuǎn)/圖片品質(zhì)等處理需求。要用到 ngx_http_image_filter_module 模塊。這個模塊是非基本模塊,需要安裝。

下面是圖片縮放功能部分的 Nginx 配置:

# 圖片縮放處理
# 這里約定的圖片處理 url 格式:以 example.com/img/ 路徑訪問
location ~* /img/(.+)$ {
    # 圖片服務(wù)端儲存地址
    alias /Users/cc/Desktop/server/static/image/$1;
    # 圖片寬度默認(rèn)值
    set $width -;
    # 圖片高度默認(rèn)值
    set $height -;
    if ($arg_width != "") {
        set $width $arg_width;
    }
    if ($arg_height != "") {
        set $height $arg_height;
    }
    #設(shè)置圖片寬高
    image_filter resize $width $height;
    #設(shè)置Nginx讀取圖片的最大buffer
    image_filter_buffer 10M;
    # 是否開啟圖片圖像隔行掃描
    image_filter_interlace on;
    # 圖片處理錯誤提示圖,例如縮放參數(shù)不是數(shù)字
    error_page 415 = 415.png;
}

到此這篇關(guān)于Nginx靜態(tài)資源服務(wù)器的實現(xiàn)示例的文章就介紹到這了,更多相關(guān)Nginx靜態(tài)資源服務(wù)器內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家! 

相關(guān)文章

  • 一文快速了解Nginx超時設(shè)置

    一文快速了解Nginx超時設(shè)置

    這篇文章主要給大家介紹了關(guān)于如何通過一文快速了解Nginx超時設(shè)置的相關(guān)資料,:后端正常的業(yè)務(wù)處理時間超過了nginx的超時時間,導(dǎo)致nginx主動返回504,為解決這個問題,我們網(wǎng)上搜索發(fā)現(xiàn)可以通過調(diào)整這幾個參數(shù)來調(diào)大nginx的超時時間,需要的朋友可以參考下
    2023-11-11
  • Nginx用戶認(rèn)證配置方法詳解(域名/目錄)

    Nginx用戶認(rèn)證配置方法詳解(域名/目錄)

    Nginx超級強大它可以單獨為一個域名設(shè)置用戶認(rèn)證,方法也很簡單我們只要生成用戶認(rèn)證的用戶名和密碼,然后再Nginx添加auth認(rèn)證配置即可
    2013-08-08
  • nginx環(huán)境下配置ssl加密(單雙向認(rèn)證、部分https)

    nginx環(huán)境下配置ssl加密(單雙向認(rèn)證、部分https)

    這篇文章主要介紹了nginx環(huán)境下配置ssl加密(單雙向認(rèn)證、部分https),具有一定的參考價值,感興趣的小伙伴們可以參考一下。
    2016-11-11
  • 利用SSL配置Nginx反向代理的簡單步驟

    利用SSL配置Nginx反向代理的簡單步驟

    這篇文章主要給大家介紹了關(guān)于利用SSL配置Nginx反向代理的簡單步驟,文中通過示例代碼介紹的非常詳細(xì),對大家學(xué)習(xí)或者使用Nginx具有一定的參考學(xué)習(xí)價值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-05-05
  • nginx啟動、配置及測試圖文詳解(全網(wǎng)最全)

    nginx啟動、配置及測試圖文詳解(全網(wǎng)最全)

    nginx是一個輕量級的網(wǎng)頁服務(wù)器、方向代理服務(wù)器和電子郵件代理服務(wù)器,具有配置靈活、靜態(tài)資源高并發(fā)、系統(tǒng)資源占用少、擁有緩存服務(wù)等優(yōu)點,這篇文章主要給大家介紹了關(guān)于nginx啟動、配置及測試的相關(guān)資料,需要的朋友可以參考下
    2024-02-02
  • nginx+redis實現(xiàn)session共享

    nginx+redis實現(xiàn)session共享

    這篇文章主要為大家詳細(xì)介紹了nginx+redis實現(xiàn)session的共享,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2018-03-03
  • nginx的限流和網(wǎng)關(guān)gatway限流詳解

    nginx的限流和網(wǎng)關(guān)gatway限流詳解

    這篇文章主要介紹了nginx的限流和網(wǎng)關(guān)gatway限流,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-08-08
  • 在Debian11上安裝Openresty服務(wù)(Nginx+Lua)的詳細(xì)教程

    在Debian11上安裝Openresty服務(wù)(Nginx+Lua)的詳細(xì)教程

    OpenResty 是一個基于 Nginx 與 Lua 的高性能 Web 平臺,其內(nèi)部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項,這篇文章主要介紹了在Debian11上安裝Openresty服務(wù)(Nginx+Lua)?,需要的朋友可以參考下
    2022-10-10
  • 在Nginx服務(wù)器下配置StartSSL和SSL的教程

    在Nginx服務(wù)器下配置StartSSL和SSL的教程

    這篇文章主要介紹了在Nginx服務(wù)器下配置StartSSL和SSL的教程,其中申請證書的步驟確實比較麻煩一些,不過出于安全考慮:p需要的朋友可以參考下
    2015-07-07
  • 解決Nginx location中配置proxy_pass轉(zhuǎn)發(fā)時斜線‘/‘導(dǎo)致404問題

    解決Nginx location中配置proxy_pass轉(zhuǎn)發(fā)時斜線‘/‘導(dǎo)致404問題

    這篇文章主要介紹了解決Nginx location中配置proxy_pass轉(zhuǎn)發(fā)時斜線‘/‘導(dǎo)致404問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-05-05

最新評論