A. nginx 反代里緩存怎麼清理
最簡單的反代+全緩存腳本：
#新建2個目錄，放置緩存文件：
mkdir -p /home/cache/path
mkdir /home/cache/temp
修改/usr/local/nginx/conf/nginx.conf的http層，添加以下代碼：
client_body_buffer_size 512k;
proxy_connect_timeout 5;
proxy_read_timeout 60;
proxy_send_timeout 5;
proxy_buffer_size 16k;
proxy_buffers 4 64k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 128k;
proxy_temp_path /home/cache/temp;
proxy_cache_path /home/cache/path levels=1:2 keys_zone=cache_one:10m inactive=7d max_size=30g;
#500m是內存佔用，7d是7天無訪問刪除，30g是緩存占具硬碟空間
#limit_zone crawler $binary_remote_addr 10m; #這段是用於限制單ip連接數的，如果頻繁出現後端負載過大可以嘗試去掉#。
(1)nginx忽略參數緩存擴展閱讀：
nginx僅僅處理靜態頁面，動態的頁面（php請求）統統都交付給後台的兩台apache來處理。也就是說，可以把網站的靜態頁面或者文件放置到nginx的目錄下；動態的頁面和資料庫訪問都保留到後台的apache伺服器上。
假設前端nginx（為127.0.0.1:8080）僅僅包含一個靜態頁面index.html；後 台的兩個apache伺服器（分別為localhost:80和158.37.70.143:80），一台根目錄放置phpMyAdmin文件夾和 test.php（裡面測試代碼為print "server1";），另一台根目錄僅僅放置一個test.php（裡面測試代碼為print "server2";）。
B. nginx緩存性能怎麼樣
Nginx緩存對於不少人來說都不是很明朗的一個知識。那麼好我們就借介紹有關優點和缺點的機會把大家帶進Nginx緩存的世界。希望大家在文中能找到自己相關的使用方法。
兩種Nginx緩存都有著基本一樣的優點和缺點：
缺點1：不支持帶參數的動態鏈接，比如read.php?id=1，因為Nginx緩存只保存文件名，所以這個鏈接只在文件系統下保存為read.php，這樣用戶訪問read.php?id=2時會返回不正確的結果。同時不支持http://www.sudone.com/這種形式的首頁和二級目錄http://www.sudone.com/download/，因為Nginx緩存非常老實，會將這樣的請求照鏈接寫入文件系統，而這個鏈接顯然是一個目錄，所以保存失敗。這些情況都需要寫rewrite才能正確保存。
缺點2：Nginx緩存內部沒有緩存過期和清理的任何機制，這些緩存的文件會永久性地保存在機器上，如果要緩存的東西非常多，那就會撐暴整個硬碟空間。為此可以使用一個shell腳本定期清理，同時可以撰寫php等動態程序來做實時更新。
缺點3：只能緩存200狀態碼，因此後端返回301/302/404等狀態碼都不會緩存，假如恰好有一個訪問量很大的偽靜態鏈接被刪除，那就會不停穿透導致後端承載不小壓力。
缺點4：Nginx不會自動選擇內存或硬碟作為存儲介質，一切由配置決定，當然在當前的操作系統里都會有操作系統級的文件緩存機制，所以存在硬碟上也不需要過分擔心大並發讀取造成的io性能問題。
Nginx傳統緩存的缺點也是它和squid等緩存軟體的不同之特色，所以也可看作其優點。在生產應用中它常常用作和squid的搭檔，squid對於帶?的鏈接往往無法阻擋，而Nginx能將其訪問攔住，例如：http://sudone.com/?和http://sudone.com/在squid上會被當做兩個鏈接，所以會造成兩次穿透；而Nginx只會保存一次，無論鏈接變成http://sudone.com/?1還是http://sudone.com/?123，均不能透過Nginx緩存，從而有效地保護了後端主機。
Nginx緩存會非常老實地將鏈接形式保存到文件系統中，這樣對於一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態和內容，也可以很方便地和別的文件管理器如rsync等配合使用，它完完全全就是一個文件系統結構。
這兩種傳統緩存都可以在linux下將文件保存到/dev/shm里，一般我也是這么做的，這樣可以利用系統內存來做緩存，利用內存的話，清理過期內容速度就會快得多。使用/dev/shm/時除了要把tmp目錄也指向到/dev/shm這個分區外，如果有大量小文件和目錄，還要修改一下這個內存分區的inode數量和最大容量：
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm
上面的命令在一台有3G內存的機器上使用，因為/dev/shm默認最大內存是系統內存的一半就是1500M，這條命令將其調大成2500M，同時shm系統inode數量默認情況下可能是不夠用的，但有趣的是它可以隨意調節，這里調節為480000保守了點，但也基本夠用了。
C. Nginx如何定向禁止緩存
今天在使用nginx限制外網訪問內部系統,遇到一個很郁悶的事情,怎麼配置都不對,折騰大... 3. deny all;結尾 表示除了上
D. 何時部署要啟動lua nginx
Lua是一個可以嵌入到Nginx配置文件中的動態腳本語言，從而可以在Nginx請求處理的任何階段執行各種Lua代碼。剛開始我們只是用Lua 把請求路由到後端伺服器，但是它對我們架構的作用超出了我們的預期。下面就講講我們所做的工作。
強制搜索引擎只索引mixlr.com
Google把子域名當作完全獨立的網站，我們不希望爬蟲抓取子域名的頁面，降低我們的Page rank
location /robots.txt {
rewrite_by_lua '
if ngx.var.http_host ~= "mixlr.com" then
return ngx.exec("/robots_disallow.txt");
end
';
}
如果對robots.txt的請求不是mixlr.com域名的話，則內部重寫到robots_diallow.txt，雖然標準的重寫指令也可以實現這個需求，但是 Lua的實現更容易理解和維護。
根據程序邏輯設置響應頭
Lua提供了比Nginx默認配置規則更加靈活的設置方式。 在下面的例子中，我們要保證正確設置響應頭，這樣瀏覽器如果發送了指定請求頭後，就可以 無限期緩存靜態文件，是的用戶只需下載一次即可。
這個重寫規則使得任何靜態文件，如果請求參數中包含時間戳值，那麼就設置相應的Expires和Cache-Control響應頭。
location / {
header_filter_by_lua '
if ngx.var.query_string and ngx.re.match( ngx.var.query_string, "^([0-9]{10})$" ) then
ngx.header["Expires"] = ngx.http_time( ngx.time() + 31536000 );
ngx.header["Cache-Control"] = "max-age=31536000";
end
';
try_files $uri @dynamic;}
刪除jQuery JSONP請求的時間戳參數
很多外部客戶端請求JSONP介面時，都會包含一個時間戳類似的參數，從而導致Nginx proxy緩存無法命中（因為無法忽略指定的HTTP參數）。下面的 規則刪除了時間戳參數，使得Nginx可以緩存upstream server的響應內容，減輕後端伺服器的負載。
location / {
rewrite_by_lua '
if ngx.var.args ~= nil then
-- /some_request?_=1346491660 becomes /some_request
local fixed_args, count = ngx.re.sub( ngx.var.args, "&?_=[0-9]+", "" );
if count > 0 then
return ngx.exec(ngx.var.uri, fixed_args);
end
end
';}
把後端的慢請求日誌記錄到Nginx的錯誤日誌
如果後端請求響應很慢，可以把它記錄到Nginx的錯誤日誌，以備後續追查。
location / {
log_by_lua '
if tonumber(ngx.var.upstream_response_time) >= 1 then
ngx.log(ngx.WARN, "[SLOW] Ngx upstream response time: " .. ngx.var.upstream_response_time .. "s from " .. ngx.var.upstream_addr);
end
';}
基於Redis的實時IP封禁
某些情況下，需要阻止流氓爬蟲的抓取，這可以通過專門的封禁設備去做，但是通過Lua，也可以實現簡單版本的封禁。
lua_shared_dict banned_ips 1m;
location / {
access_by_lua '
local banned_ips = ngx.shared.banned_ips;
local updated_at = banned_ips:get("updated_at");
-- only update banned_ips from Redis once every ten seconds:
if updated_at == nil or updated_at < ( ngx.now() - 10 ) then
local redis = require "resty.redis";
local red = redis:new();
red:set_timeout(200);
local ok, err = red:connect("your-redis-hostname", 6379);
if not ok then
ngx.log(ngx.WARN, "Redis connection error retrieving banned_ips: " .. err);
else
local updated_banned_ips, err = red:smembers("banned_ips");
if err then
ngx.log(ngx.WARN, "Redis read error retrieving banned_ips: " .. err);
else
-- replace the locally stored banned_ips with the updated values:
banned_ips:flush_all();
for index, banned_ip in ipairs(updated_banned_ips) do
banned_ips:set(banned_ip, true);
end
banned_ips:set("updated_at", ngx.now());
end
end
end
if banned_ips:get(ngx.var.remote_addr) then
ngx.log(ngx.WARN, "Banned IP detected and refused access: " .. ngx.var.remote_addr);
return ngx.exit(ngx.HTTP_FORBIDDEN);
end
';}
現在就可以阻止特定IP的訪問：
1
ruby> $redis.sadd("banned_ips", "200.1.35.4")
Nginx進程每隔10秒從Redis獲取一次最新的禁止IP名單。需要注意的是，如果架構中使用了Haproxy這樣類似的負載均衡伺服器時， 需要把$remote_addr設置為正確的遠端IP地址。
這個方法還可以用於HTTP User-Agent欄位的檢查，要求滿足指定條件。
使用Nginx輸出CSRF(form_authenticity_token)
Mixlr大量使用頁面緩存，由此引入的一個問題是如何給每個頁面輸出會話級別的CSRF token。我們通過Nginx的子請求，從upstream web server 獲取token，然後利用Nginx的SSI(server-side include)功能輸出到頁面中。這樣既解決了CSRF攻擊問題，也保證了cache能被正常利用。
location /csrf_token_endpoint {
internal;
include /opt/nginx/conf/proxy.conf;
proxy_pass "http://upstream";}
location @dynamic {
ssi on;
set $csrf_token '';
rewrite_by_lua '
-- Using a subrequest, we our upstream servers for the CSRF token for this session:
local csrf_capture = ngx.location.capture("/csrf_token_endpoint");
if csrf_capture.status == 200 then
ngx.var.csrf_token = csrf_capture.body;
-- if this is a new session, ensure it sticks by passing through the new session_id
-- to both the subsequent upstream request, and the response:
if not ngx.var.cookie_session then
local match = ngx.re.match(csrf_capture.header["Set-Cookie"], "session=([a-zA-Z0-9_+=/+]+);");
if match then
ngx.req.set_header("Cookie", "session=" .. match[1]);
ngx.header["Set-Cookie"] = csrf_capture.header["Set-Cookie"];
end
end
else
ngx.log(ngx.WARN, "No CSRF token returned from upstream, ignoring.");
end
';
try_files /maintenance.html /rails_cache$uri @thin;}
CSRF token生成 app/metal/csrf_token_endpoint.rb:
class CsrfTokenEndpoint
def self.call(env)
if env["PATH_INFO"] =~ /^\/csrf_token_endpoint/
session = env["rack.session"] || {}
token = session[:_csrf_token]
if token.nil?
token = SecureRandom.base64(32)
session[:_csrf_token] = token
end
[ 200, { "Content-Type" => "text/plain" }, [ token ] ]
else
[404, {"Content-Type" => "text/html"}, ["Not Found"]]
end
endend
我們的模版文件示例:
<meta name="csrf-param" value="authenticity_token"/>
<meta name="csrf-token" value="<!--# echo var="csrf_token" default="" encoding="none" -->"/>
Again you could make use of lua_shared_dict to store in memory the CSRF token for a particular session. This minimises the number of trips made to /csrf_token_endpoint.
E. nginx如何設置不使用緩存
在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。
apache：
首先確定配置文件httpd.conf中確已經載入mod_headers模塊。
LoadMole headers_mole moles/mod_headers.so
我們可以根據文件類型來讓瀏覽器每次都從伺服器讀取，這里測試用css、js、swf、php、html、htm這幾種文件。
<FilesMatch 「\.(css|js|swf|php|htm|html)$」>
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>
nginx:
location ~ .*\.(css|js|swf|php|htm|html )$ {
add_header Cache-Control no-store;
}
對於站點中不經常修改的靜態內容（如圖片，JS，CSS），可以在伺服器中設置expires過期時間，控制瀏覽器緩存，達到有效減小帶寬流量，降低伺服器壓力的目的。
以Nginx伺服器為例：
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
#過期時間為30天，
#圖片文件不怎麼更新，過期可以設大一點，
#如果頻繁更新，則可以設置得小一點。
expires 30d;
}
location ~ .*\.(js|css)$ {
expires 10d;
}
F. nginx緩存清理
你找nginx配置中的expire參數，這個是設定緩存時間的，如果你不需要緩存，可以去掉該參數，或者是設置成-1，如下圖所示：
G. Nginx怎樣設置瀏覽器緩存
瀏覽器緩存（BrowserCaching）
為了加速瀏覽器，瀏覽器在用戶磁碟上，對最近請求過的文檔進行存儲。
當訪問者再次請求這個頁面時，瀏覽器就可以從本地磁碟顯示文檔，這樣，就可以加速頁面的閱覽，緩存的方式節約了網路的資源，提高了網路的效率。
瀏覽器緩存可以通過expires指令輸出Header頭來實現，expires指令的語法如下
語法：expires[time| epoch | max |off]
默認值：expiresoff
作用域：http、server、location
用途：使用本指令可以控制http應答中的expires和Cache-Control的Header頭信息，起到控制頁面緩存的作用。
參數說明
Time，可以使用正數或負數，Expires頭標的值，將通過當前系統時間加上設定的time值來獲得。
epoch，指定expires的值為1January，1970，00:00:01 GMT。
Max，指定expires的值為31December 2037 23:59:59 GMT，Cache-Control的值為10年。
Off，表示不修改Expires和Cache-Control的值。
一個HTML頁面，會引用一些JavaScript文件、圖片文件、而這些格式的文件很少會被修改，則可以通過expires設置瀏覽器緩存。
比如，對常見格式的圖片、Flash文件在瀏覽器本地緩存30天，對JS、CSS文件在瀏覽器本地緩存1小時，代碼如下
H. nginx 伺服器緩存怎麼清理
你找nginx配置中的expire參數，這個是設定緩存時間的，如果你不需要緩存，可以去掉該參數，或者是設置成-1，如下圖所示：
I. 如何利用Nginx的緩沖，緩存優化提升性能
反向代理的一個問題是代理大量用戶時會增加伺服器進程的性能沖擊影響。在大多數情況下，可以很大程度上能通過利用Nginx的緩沖和緩存功能減輕。
當代理到另一台伺服器，兩個不同的連接速度會影響客戶的體驗：
從客戶機到Nginx代理的連接。
從Nginx代理到後端伺服器的連接。
Nginx具有優化這些連接調整其行為的能力。
如果沒有緩沖，數據從代理的伺服器發送並立即開始被發送到客戶。如果假定客戶端很快，緩沖可以關閉而盡快使數據到客戶端，有了緩沖，Nginx 代理將暫時存儲後端的響應，然後按需供給數據給客戶端。如果客戶端是緩慢的，允許Nginx伺服器關閉到後端的連接。然後，它可以處理數據分配到客戶端， 以任何可能的速度。
Nginx默認有緩沖設計，因為客戶端往往有很大的不同的連接速度。我們可以用以下指令調節緩沖行為。可以在HTTP，server或 location位置來設置。重要的是要記住，大小size指令是針對每個請求配置的，所以增加超出你需求會影響你的性能，如果這時有許多客戶端請求：
proxy_buffering：該指令控制緩沖是否啟用。默認情況下，它的值是「on」。
proxy_buffers：該指令控制代理響應緩沖區的數量（第一個參數）和大小（第二個參數）。默認配置是8個緩沖區大小等於一個內存頁（4K或者8K）。增加緩沖區的數目可以讓你緩沖更多信息。
proxy_buffer_size：從後端伺服器的響應頭緩沖區大小，它包含headers，和其他部分響應是分開的。該指令設置響應部分的緩沖區大小。默認情況下，它和proxy_buffers是相同的尺寸，但因為這是用於頭信息，這通常可以設置為一個較低的值。
proxy_busy_buffers_size：此指令設置標注「client-ready」緩沖區的最大尺寸。而客戶端可以一次讀取來自一個緩沖區的數據，緩沖被放置在隊列中，批量發送到客戶端。此指令控制允許是在這種狀態下的緩沖空間的大小。
proxy_max_temp_file_size：這是每個請求能用磁碟上臨時文件最大大小。這些當上游響應太大不能裝配到緩沖區時被創建。
proxy_temp_file_write_size：這是當被代理伺服器的響應過大時Nginx一次性寫入臨時文件的數據量。
proxy_temp_path：當上游伺服器的響應過大不能存儲到配置的緩沖區域時，Nginx存儲臨時文件硬碟路徑。
正如你所看到的，Nginx提供了相當多的不同的指令來調整緩沖行為。大多數時候，你不必擔心太多，但它對於調整一些值可能是有用的。可能最有用的調整是proxy_buffers和proxy_buffer_size指令。
J. 怎麼關閉Nginx 的緩存
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$ {
#禁止緩存，每次都從伺服器請求
add_header Cache-Control no-store;
}