⑴ 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速度上有提升。