nginx 處理請求的過程一共劃分為 11 個階段，按照執行順序依次是
rewrite、access 和 content 這三個最為常見的 nginx 請求處理階段
ngx.lua的執行階段
ngx_realip 模組究竟有什麼實際用途呢？為什麼我們需要去改寫請求的**位址呢？答案是：當 nginx 處理的請求經過了某個 http **伺服器的**時，這個模組就變得特別有用。當原始的使用者請求經過**之後，nginx 接收到的請求的**位址無一例外地變成了該**伺服器的 ip 位址，於是 nginx 以及 nginx 背後的應用就無法知道原始請求的真實**。所以，一般我們會在 nginx 之前的**伺服器中把請求的原始**位址編碼進某個特殊的 http 請求頭中（例如上例中的 x-my-ip 請求頭），然後再在 nginx 一側把這個請求頭中編碼的位址恢復出來。這樣 nginx 中的後續處理階段（包括 nginx 背後的各種後端應用）就會認為這些請求直接來自那些原始的位址，**伺服器就彷彿不存在一樣。正是因為這個需求，所以 ngx_realip 模組才需要在第乙個處理階段，即 post-read 階段，註冊處理程式，以便盡可能早地改寫請求的**。
}server-rewrite
find-config
rewrite
post-rewrite
location /bar
location /baz
}如果在 server 配置塊中直接使用 rewrite 配置指令對請求 uri 進行改寫，則不會涉及「內部跳轉」，因為此時 uri 改寫發生在 server-rewrite 階段，早於執行 location 配對的 find-config 階段。
}preaccess
access
post-access
try-file
set 指令來自 ngx_rewrite 模組，執行於 rewrite 階段；
rewrite_by_lua 指令來自 ngx_lua 模組，執行於 rewrite 階段的末尾；
deny 指令來自 ngx_access 模組，執行於 access 階段；
access_by_lua 指令同樣來自 ngx_lua 模組，執行於 access 階段的末尾；
echo 指令則來自 ngx_echo 模組，執行在 content 階段。
content_by_lua 指令來自 ngx_lua 模組，執行於 content 階段；不要將它和其它的內容處理指令在同乙個location內使用如proxy_pass。
header_filter_by_lua 執行於 content 階段output-header-filter 一般用來設定cookie和headers，在該階段不能使用如下幾個api：
$arg_*** url引數變數組
$cookie_*** cookie變數組
$http_*** 請求頭變數組
$send_http_*** 響應頭變數組
以上都是唯讀變數 如果修改可能造成意外錯誤
$args 可修改
11 執行階段
乙個普通的c程式經過預處理器 編譯器 彙編器和鏈結器後生成乙個可執行的目標檔案，它由最初的一段ascii文字檔案轉化成為乙個二進位制檔案，且這個二進位制檔案包含引導程式到記憶體並執行它所需的所有資訊。程序在執行時為c程式提供了乙個通用的執行時儲存器映像。linux將這個執行時儲存器映像組織成若干段的...
nginx lua開發例子
參考文章 conf檔案與原來文章的配置有點不同，這個要參考官方文件 vim usr chapter6 nginx chapter6.conf upstream backend server location ad d lua檔案 local redis require resty.redis loc...
nginx lua環境搭建
lua 是乙個小巧的指令碼語言。該語言的設計目的是為了嵌入應用程式中，從而為應用程式提供靈活的擴充套件和定製功能。lua指令碼可以很容易的被c c 呼叫，也可以反過來呼叫c c 的函式，這使得lua在應用程式中可以被廣泛應用。不僅僅作為擴充套件指令碼，也可以作為普通的配置檔案，代替xml,ini等檔...