該模組能夠使得Nginx與uWSGI程式進行互動，並且會控制傳遞給uWSGI程式的引數。對於uwsgi協議和uWSGI伺服器，uWSGI伺服器就是uwsgi協議的一個實現。

該模組首次提供出現在nginx-0.8.40版本中，因此，如果要使用這個功能那麼必須要選擇這個版本及其以上。

5.1 示例配置

一個有快取的例子

    快取只對後臺Cache-Control、Expires等感興趣，而Vary處理不受影響。

指    令      省略

傳遞到uWSGI伺服器的引數

 

被傳遞到uWSGI伺服器的請求頭是以引數的形式實現的，從uWSGI伺服器執行應用程式或者指令碼，這些環境變數的引數格式通常很容易被取得。例如，"User-agent"頭將會通過HTTP_USER_AGENT引數來傳遞，除了HTTP請求頭之外，還有可能通過uwsgi_param指令來傳遞任意引數。

 

使用配置

 

    下面的一個例子來自於Nginx官方提供，在此瞭解以下，有關這個例子的實施參考例項部分。

 

它是一個由單個uWSGI後臺伺服器例項提供多個主機名稱或者是每個主機有多個應用的情況。因此，這個例項比較經典。

 

新增配置：

 

    我先看以下Nginx的配置檔案：

 

upstream uwsgi_host    {       server 127.0.0.1:1088;    }      include uwsgi_params;    uwsgi_param SCRIPT_NAME           $app;           uwsgi_param UWSGI_MODULE          $app;    uwsgi_param UWSGI_CALLABLE        "${app}_handler";    uwsgi_param UWSGI_PYHOME          $document_root;    uwsgi_param UWSGI_CHDIR           $document_root;    uwsgi_modifier1                   30; #properly sets PATH_INFO variable      server    {       server_name   foo;       root   /var/www/foo;         location /app1/       {          set   $app   app1;          uwsgi_pass   127.0.0.1:1088;       }         location /app2/       {          set   $app   app2;          uwsgi_pass   127.0.0.1:1088;       }    }      server    {       server_name   bar;       root   /var/www/bar;         location /app1/       {          set   $app   app1;          uwsgi_pass   uwsgi_host;       }         location /app3/       {          set   $app   app3;          uwsgi_pass   uwsgi_host;       }    }

 

    在這個配置檔案中，提供了兩個域名，即foo和bar，而每個域名下都有兩個應用，其中app1在兩個域名下都有，這是為了測試效果，實際的應用中可能不會這麼巧合，當然也不應定，比如index.py。

 

在這個配置中，使用了uwsgi協議的兩個引數：SCRIPT_NAME和SERVER_NAME，它們將會被自動處理，SERVER_NAME在uwsgi_params檔案中被對映，而SCRIPT_NAME被傳遞到明確地後臺伺服器，即uWSGI伺服器，這是因為uWSGI的vhost應用名冊上將鍵值設定為"host|script"格式，

 

具有相同的主機和相同的指令碼名稱，才會處理對相同應用程式處理所有的請求，例如，如果我們訪問http://bar/app1/、http://foo/app1/，即使app1完全一樣，但不會提供同樣的功能，除非這兩個網站完全一樣，包括所有的資料。

 

如果沒有提供指令碼名稱，那麼就會為空，另外，第一次訪問該指令碼時首先會被初始化，例如：

 

    這是第一次訪問：

 

WSGI application 2 (SCRIPT_NAME=bar|app3) ready on interpreter 0x8272860 pid: 21532 bar [pid: 21532|app: 2|req: 1/10] 192.168.3.248 () {50 vars in 770 bytes} [Thu Jul 21 19:12:03 2011] GET /app3/ => generated 4 bytes in 20 msecs (HTTP/1.1 200) 1 headers in 45 bytes (0 switches on core 0)

   

    這是第二次訪問：

 

bar [pid: 21527|app: 2|req: 2/11] 192.168.3.248 () {50 vars in 770 bytes} [Thu Jul 21 19:12:07 2011] GET /app3/ => generated 4 bytes in 0 msecs (HTTP/1.1 200) 1 headers in 45 bytes (0 switches on core 0)

   

    另外，注意UWSGI_MODULE 和 UWSGI_CALLABLE這兩個變數，第一個即UWSGI_MODULE的功能在於能夠為WSGI應用程式(應用程式是由UWSGI_PYHOME提供的，該引數用於新增Python的路徑)提供一個入口點；第二個變數，即UWSGI_CALLABLE，它所指的的是被例項化類的名稱。

 

建立Python模組

 

    以下是三個app，原文有誤，應該在每一個def行的結尾新增“：”。

 

app1.py

 

def app1_handler(environ, start_response):    start_response('200 OK', [('Content-Type', 'text/plain')])    return b'app1'

  

app2.py

 

def app2_handler(environ, start_response)：    start_response('200 OK', [('Content-Type', 'text/plain')])    return b'app2'

 

app3.py

 

def app3_handler(environ, start_response)：    start_response('200 OK', [('Content-Type', 'text/plain')])    return b'app3'

   

在這個設定中，uWSGI將會有兩個絕然不同的app1例項(一個基於/var/www/foo/app1.py內容的foo主機名，另一個是基於/var/www/bar/app1.py內容的bar主機名)，另外，還有主機名為foo的app2(基於/var/www/foo/app2.py內容)、主機名為foo的app3(基於/var/www/foo/app3.py內容)。