⑴ php和nginx之間是如何工作的
Nginx+php-fpm實現原理 Nginx本身不會對PHP進行解析，終端對PHP頁面的請求將會被Nginx交給FastCGI進程監聽的IP地址及埠，由php-fpm作為動態解析伺服器處理，最後將處理結果再返回給nginx。其實，Nginx就是一個反向代理伺服器。Nginx通過反向代理功能將動態請求轉向後端php-fpm，從而實現對PHP的解析支持，這就是Nginx實現PHP動態解析的原理。 Nginx不支持對外部程序的直接調用或者解析，所有的外部程序（包括PHP）必須通過FastCGI介面來調用。FastCGI介面在Linux下是socket（這個socket可以是文件socket，也可以是ip socket）。為了調用CGI程序，還需要一個FastCGI的wrapper（wrapper可以理解為用於啟動另一個程序的程序），這個wrapper綁定在某個固定socket上，如埠或者文件socket。當Nginx將CGI請求發送給這個socket的時候，通過FastCGI介面，wrapper接收到請求，然後派生出一個新的線程，這個線程調用解釋器或者外部程序處理腳本並讀取返回數據；接著，wrapper再將返回的數據通過FastCGI介面，沿著固定的socket傳遞給Nginx；最後，Nginx將返回的數據發送給客戶端。
當nginx接收到一個http請求時，通過配置文件找到對應的server。然後匹配server中的所有location，找到最匹配的。而在location中的命令會啟動不同的模塊去完成工作，比如rewrite模塊、index模塊。因此在nginx中模塊可以看作真正的勞動工作者。nginx的模塊是被編譯到nginx中的，屬於靜態方式。啟動nginx時，模塊被自動載入。
⑵ 請教ThinkPHP 3.1 Nginx配置問題 functions.php 112無法載入模塊
解決方法是，不區分大小寫把這功能開啟，在配置文件下config.php中加入
'URL_CASE_INSENSITIVE' => true, //不區分大小寫 問題解決！
⑶ nginx支持php需要安裝什麼模塊
此模塊不應該安裝它，路徑到文件中，這個模塊？應該有一個集擴展，DIR的。當你去了phpinfo（）函數，看看它是否在裝起來
⑷ nginx在我本機windows主機上配置載入不了php模塊
就算能執行，php-cgi跑一會就掛了，缺少php-fpm。你可以試試集成包phpfind或phpstudy，自動配好php+nginx，帶中文控制面板。你可以研究一下。
⑸ NGINX+PHP好，還是NGINX+APACHE+PHP好
NGINX+APACHE+PHP會更好，因為可以充分利用NGINX的「反向代理」技術。將靜態文件由NGINX處理，動態文件（PHP）由APACHE處理，這是最高效的處理方式。
但是，一般網站都不需要這么做，因為沒有高並發的情況下，這樣做並不能體現非常大的優勢。
如果是商城，比較注重速度的，就使用NGINX+PHP；如果是政府網站等，比較注重穩定性的，就使用APACHE+PHP。
當然，如果不嫌麻煩，完全可以搭建NGINX+APACHE+PHP的環境。
⑹ nginx php安裝擴展模塊之後要重啟嗎
需要的。更改了配置都需要重啟才生效
⑺ 如何正確配置Nginx + PHP
對很多人而言，配置Nginx+PHP無外乎就是搜索一篇教程，然後拷貝粘貼。聽上去似乎也沒什麼問題，可惜實際上網路上很多資料本身年久失修，漏洞百出，如果大家不求甚解，一味的拷貝粘貼，早晚有一天會為此付出代價。
假設我們用PHP實現了一個前端控制器，或者直白點說就是統一入口：把PHP請求都發送到同一個文件上，然後在此文件里通過解析「REQUEST_URI」實現路由。
此時很多教程會教大家這樣配置Nginx+PHP：
server {
listen 80;
server_name foo.com;
root /path;
location / {
index index.html index.htm index.php;
if (!-e $request_filename) {
rewrite . /index.php last;
}
}
location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
這裡面有很多錯誤，或者說至少是壞味道的地方，大家看看能發現幾個。
…
我們有必要先了解一下Nginx配置文件里指令的繼承關系：Nginx配置文件分為好多塊，常見的從外到內依次是「http」、「server」、「location」等等，預設的繼承關系是從外到內，也就是說內層塊會自動獲取外層塊的值作為預設值(有例外，詳見參考)。
參考：UNDERSTANDING THE NGINX CONFIGURATION INHERITANCE MODEL
…
讓我們先從「index」指令入手吧，在問題配置中它是在「location」中定義的：
location / {
index index.html index.htm index.php;
}
一旦未來需要加入新的「location」，必然會出現重復定義的「index」指令，這是因為多個「location」是平級的關系，不存在繼承，此時應該在「server」里定義「index」，藉助繼承關系，「index」指令在所有的「location」中都能生效。
參考：Nginx Pitfalls
…
接下來看看「if」指令，說它是大家誤解最深的Nginx指令毫不為過：
if (!-e $request_filename) {
rewrite . /index.php last;
}
很多人喜歡用「if」指令做一系列的檢查，不過這實際上是「try_files」指令的職責：
try_files $uri $uri/ /index.php;
除此以外，初學者往往會認為「if」指令是內核級的指令，但是實際上它是rewrite模塊的一部分，加上Nginx配置實際上是聲明式的，而非過程式的，所以當其和非rewrite模塊的指令混用時，結果可能會非你所願。
參考：IfIsEvil and How nginx 「location if」 works
…
下面看看「fastcgi_params」配置文件：
include fastcgi_params;
Nginx有兩份fastcgi配置文件，分別是「fastcgi_params」和「fastcgi.conf」，它們沒有太大的差異，唯一的區別是後者比前者多了一行「SCRIPT_FILENAME」的定義：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
注意：$document_root 和 $fastcgi_script_name 之間沒有 /。
原本Nginx只有「fastcgi_params」，後來發現很多人在定義「SCRIPT_FILENAME」時使用了硬編碼的方式，於是為了規范用法便引入了「fastcgi.conf」。
不過這樣的話就產生一個疑問：為什麼一定要引入一個新的配置文件，而不是修改舊的配置文件?這是因為「fastcgi_param」指令是數組型的，和普通指令相同的是：內層替換外層;和普通指令不同的是：當在同級多次使用的時候，是新增而不是替換。換句話說，如果在同級定義兩次「SCRIPT_FILENAME」，那麼它們都會被發送到後端，這可能會導致一些潛在的問題，為了避免此類情況，便引入了一個新的配置文件。
參考：FASTCGI_PARAMS VERSUS FASTCGI.CONF – NGINX CONFIG HISTORY
此外，我們還需要考慮一個安全問題：在PHP開啟「cgi.fix_pathinfo」的情況下，PHP可能會把錯誤的文件類型當作PHP文件來解析。如果Nginx和PHP安裝在同一台伺服器上的話，那麼最簡單的解決方法是用「try_files」指令做一次過濾：
try_files $uri =404;
參考：Nginx文件類型錯誤解析漏洞
…
依照前面的分析，給出一份改良後的版本，是不是比開始的版本清爽了很多：
server {
listen 80
server_name foo.com;
root /path;
index index.html index.htm index.php;
location / {
try_files $uri $uri/ /index.php;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
}
}
實際上還有一些瑕疵，主要是「try_files」和「fastcgi_split_path_info」不夠兼容，雖然能夠解決，但方案比較醜陋，具體就不多說了，有興趣的可以參考問題描述。
補充：因為「location」已經做了限定，所以「fastcgi_index」其實也沒有必要.
⑻ 請問磚家，nginx怎麼和php交互
nginx和php交互是通過fastcgi模塊來實現的。fastcgi在nginx中是作為一個upstream實現的。可以使用如下的配置實現nginx和php的交互，從而把nginx接收到的請求轉發給php。
fastcgi_passunix:/home/wangwei/php/var/php-cgi.sock;
⑼ php使用nginx如何獲取請求頭
Nginx的http模塊在處理HTTP請求時對環境變數的封裝與Apache有所不同。除了支持一些與HTTP協議相關的通用的變數之外，還支持一系列Nginx自有的變數，如Nginx配置目錄下fastcgi_params.default文件里的$server_protocol、$nginx_version等。正如這個文件中的示例的用途，這些變數可以在配置fastcgi時傳遞給cgi程序，使其可以作為cgi程序的環境變數來使用。然而，即便是Nginx有了這些自有的變數也無法完全滿足所有的需求。
了解Jquery的朋友會發現，Jquery在實現Ajax時會通過setRequestHeader(『X-Requested-With』, 『xmlhttprequest』)方法自動添加一個值為「xmlhttprequest」自定義的請求頭」X-Requested-With」來標識這是一個Ajax請求，以期處理這個請求的後端能夠通過判斷這個標識來識別請求類型。那麼這個時候PHP是如何來獲取這個自定義參數的值的呢？
熟悉Apache和PHP的人一定會第一時間想到$_SERVER["HTTP_X_REQUESTED_WITH"]，不錯，這對黃金搭配早就把這個問題給完美解決了，但Nginx卻不然，這是由Nginx對其自身工作的定位決定的——Nginx只負責HTTP。在Nginx眼裡，PHP只是它的一個後端，形象點來說，它只管分發請求，而不管發給誰。這就意味著，我們無法期待Nginx像Apache一樣給我們自動完成一些自定義參數到PHP的傳遞，只有自力更生。簡單點說就是，想要直接像$_SERVER["HTTP_X_REQUESTED_WITH"]這樣來調用自定義請求頭參數的值的話，你就必須手工將其添加到fastcgi_params的配置中，明確告知cgi程序接收，否則Nginx會將其遺棄。
配置環境變數的方法可參照fastcgi_params.default這個文件，在前面的博客「Nginx下虛擬主機環境變數的配置方法」中也提到過。針對上述例子，只需在fastcgi_params文件中增加一行即可：
?12 # for Ajax fastcgi_param HTTP_X_REQUESTED_WITH $http_x_requested_with;
這樣，重載Nginx配置後就可以之間在PHP中調用$_SERVER["HTTP_X_REQUESTED_WITH"]來判斷請求類型了。其中需要注意以下兩點：
一、自定義請求頭部的名稱不應該包括空白、冒號、換行和下劃線。
Nginx在處理客戶端請求header頭時，會將名稱中的中橫線」-」替換為下劃線」_」，並將所有字母小寫再加上」$http_」來作為該名稱對應的變數名。例如上述Jquery的例子中setRequestHeader(『X-Requested-With』, 『xmlhttprequest』)，在HTTP請求頭中為一行字元串：」X-Requested-With: xmlhttprequest」，經Nginx處理後將自動生成一個名為$http_x_requested_with的變數，其值為」xmlhttprequest」。尤其注意中橫線」-」替換為下劃線」_」這個規則，這意味著請求參數名稱中如果含有下劃線，Nginx將無法正確識別。
二、$_SERVER["HTTP_X_REQUESTED_WITH"]中的索引，也即「fastcgi_param HTTP_X_REQUESTED_WITH $http_x_requested_with;」中加紅部分，是可以自由命名的，當前這種命名格式是為了保持和Apache保持一致。
..
⑽ nginx和php通過什麼模塊
當nginx接收到一個http請求時，通過配置文件找到對應的server。然後匹配server中的所有location，找到最匹配的。
而在location中的命令會啟動不同的模塊去完成工作，比如rewrite模塊、index模塊。
因此在nginx中模塊可以看作真正的勞動工作者。
nginx的模塊是被編譯到nginx中的，屬於靜態方式。啟動nginx時，模塊被自動載入。不像apache，把模塊單獨編譯成so文件，在配置文件中指定是否載入。所以，單比模塊載入方面，nginx也比apache速度上有提升。