Nginx靜態(tài)資源服務(wù)器的實現(xiàn)示例
靜態(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_level
:gzip
壓縮比,壓縮級別是 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-store
、max-age
、max-stale
、min-fresh
、only-if-cache
等 - 響應(yīng)消息中的指令:
public
、private
、no-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環(huán)境下配置ssl加密(單雙向認(rèn)證、部分https)
這篇文章主要介紹了nginx環(huán)境下配置ssl加密(單雙向認(rèn)證、部分https),具有一定的參考價值,感興趣的小伙伴們可以參考一下。2016-11-11nginx的限流和網(wǎng)關(guān)gatway限流詳解
這篇文章主要介紹了nginx的限流和網(wǎng)關(guān)gatway限流,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-08-08在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的教程,其中申請證書的步驟確實比較麻煩一些,不過出于安全考慮:p需要的朋友可以參考下2015-07-07解決Nginx location中配置proxy_pass轉(zhuǎn)發(fā)時斜線‘/‘導(dǎo)致404問題
這篇文章主要介紹了解決Nginx location中配置proxy_pass轉(zhuǎn)發(fā)時斜線‘/‘導(dǎo)致404問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-05-05