实现：
Nginx配置的web服务器中，使用LUA下载文件，并发送给客户端。
需要用到curl.so动态库，例如：
package.cpath = '/usr/local/lib/lua/5.1/?.so;'
require("curl")
function build_w_cb(f)
return function(s,len)
ngx.print(s)
ngx.flush(true)
--local wlen = f:write(s)
--if (wlen ~= len) then
-- return len,"writeError"
-- else
return len,nil
-- end
end
end
file = io.open("/usr/local/openresty/nginx/html/me.ts", "w")
if (file == nil) then
ngx.say ("Create File error")
return
end
ngx.header["Transfer-Encoding"] = 'chunked';
--Transfer-Encoding: chunked
--download XML File
xmlURL = "http://192.168.1.102/pxx/f1.ts"
c = curl.easy_init()
c:setopt(curl.OPT_URL, xmlURL)
c:setopt(curl.OPT_WRITEFUNCTION, build_w_cb(file))
c:setopt(curl.OPT_FOLLOWLOCATION, 1)
c:setopt(curl.OPT_USERAGENT, "ContentPreload-agent/1.0")
c:setopt(curl.OPT_COOKIEFILE, "./curlpost.cookie")
c:setopt(curl.OPT_CONNECTTIMEOUT, 5)
c:setopt(curl.OPT_TIMEOUT, 3000)
c:setopt(curl.OPT_NOSIGNAL, 1)
ret,strerr = c:perform()
file:close()
此例可以运行，不过有如下的缺点：
文件下载过程中虽然调用 ngx.print和ngx.flush，但nginx会把内容全部堆积到内存，文件完毕后才会真正发送给客户端。
原因分析：
可能是由于下载和发送为同一个线程，只有curl的 perform函数执行完毕后，才会真正发送出去，在perform函数执行的过程中，虽然调用了print函数，但是该函数只是把内容放到了内存，无法真正执行 send 函数，所以数据会堆积到内存。
有了解更多真相的朋友，欢迎分享下您的LUA使用经验。
在我的一台服务器中，运行Nginx，当服务器端要执行长时间的PHP脚本时，客户端容易出现504 Gateway Time-out。
php-fpm中主要修改参数：
<value name="max_requests">1024</value> //每个max_children进程若超过这个数目，就自动杀死，以后用到会自动重建。一般设置1000左右。
<value name="request_terminate_timeout">0s</value> //如果服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。做不到这点的话，PHP-CGI可能出现某个BUG，或带宽不够充足，或其他原因导致PHP-CGI能够假死。
建议给”request_terminate_timeout”赋一个值，这个值可以根据你服务器的性能进行设定。
一般来说性能越好，可以设置越高，20分钟-30分钟都可以。
由于PHP脚本需要长时间运行，有的可能会超过10分钟，因此设置了900秒，这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。
nginx中主要修改参数
fastcgi_send_timeout 1800;
fastcgi_read_timeout 1800;
fastcgi_buffer_size 1024k;
fastcgi_buffers 32 1024k;
fastcgi_busy_buffers_size 2048k;
fastcgi_temp_file_write_size 2048k;
注：两个1024k值必须相等，否则报错。
以下是默认参数：
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
一、错误提示说明：
Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行，但是由于某种原因（一般是读取资源的问题）没有执行完毕而导致PHP-CGI进程终止。
Nginx 504 Gateway Time-out的含义是所请求的网关没有请求到，简单来说就是没有请求到可以执行的PHP-CGI。
二、错误提示原因分析：
解决这两个问题其实是需要综合思考的，一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关，而Nginx 504 Gateway Time-out则是与nginx.conf的设置有关。
php-fpm.conf有两个至关重要的参数，一个是”max_children”,另一个是”request_terminate_timeout” ，引值需要自己计算出来。
三、临时解决办法：
综上所述，Nginx提示502和504错误的临时解决办法是：
1、调整php-fpm.conf的相关设置：
<value name=”request_terminate_timeout”>900s</value>
2、调整nginx.conf的相关设置：
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_buffer_size 256k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 512k;
fastcgi_temp_file_write_size 512k;
四、终级解决方案：
如果网站的访问量确实非常非常大，而Nginx+FastCGI只能对处理瞬间或短时间内的高并发有很好的效果。
终极的解决方案就是：定时平滑重启php-cgi。
具体配置：
1、创建 shell 脚本：
#vi /home/www/scripts/php-fpm.sh
代码：
# This script run at */1
/usr/local/php/sbin/php-fpm reload
2、添加至计划任务：
#crontab -e
内容：
*/1 * * * * /home/www/scripts/php-fpm.sh
一，nginx基于名字的虚拟主机
Nginx首先选定由哪一个虚拟主机来处理请求。
从一个简单的配置（其中全部3个虚拟主机都在端口*：80上监听）开始：
server {
listen 80;
server_name xxx.org www.xxx.org;
...
}
server {
listen 80;
server_name xxx.net www.xxx.net;
...
}
server {
listen 80;
server_name www.;
...
}
在这个配置中，nginx仅仅检查请求的“Host”头以决定该请求应由哪个虚拟主机来处理。如果Host头没有匹配任意一个虚拟主机，或者请求中根本没有包含Host头，那nginx会将请求分发到定义在此端口上的默认虚拟主机。在以上配置中，第一个被列出的虚拟主机即nginx的默认虚拟主机——这是nginx的默认行为。而且，可以显式地设置某个主机为默认虚拟主机，即在"listen"指令中设置"default_server"参数：
listen 80 default_server;
server_name xxx.net www.xxx.net;
...
}
"default_server"参数从0.8.21版开始可用。在之前的版本中，应该使用"default"参数代替。
请注意"default_server"是监听端口的属性，而不是主机名的属性。后面会对此有更多介绍。
如何防止处理未定义主机名的请求
如果不允许请求中缺少“Host”头，可以定义如下主机，丢弃这些请求：
listen 80;
server_name "";
return 444;
}
在这里，设置主机名为空字符串以匹配未定义“Host”头的请求，而且返回了一个nginx特有的，非http标准的返回码444，它可以用来关闭连接。
从0.8.48版本开始，这已成为主机名的默认设置，所以可以省略server_name ""。而之前的版本使用机器的hostname作为主机名的默认值。
基于域名和IP混合的虚拟主机
一个复杂点的配置，在这个配置里，有几个虚拟主机在不同的地址上监听：
server {
listen 192.168.1.1:80;
server_name xxx.org www.xxx.org;
...
}
server {
listen 192.168.1.1:80;
server_name xxx.net www.xxx.net;
...
}
server {
listen 192.168.1.2:80;
server_name www.;
...
}
这个配置中，nginx首先测试请求的IP地址和端口是否匹配某个server配置块中的listen指令配置。接着nginx继续测试请求的Host头是否匹配这个server块中的某个server_name的值。如果主机名没有找到，nginx将把这个请求交给默认虚拟主机处理。例如，一个从192.168.1.1:80端口收到的访问www.的请求将被监听192.168.1.1:80端口的默认虚拟主机处理，本例中就是第一个服务器，因为这个端口上没有定义名为www.的虚拟主机。
默认服务器是监听端口的属性，所以不同的监听端口可以设置不同的默认服务器：
listen 192.168.1.1:80;
server_name xxx.org www.xxx.org;
...
}
server {
listen 192.168.1.1:80 default_server;
server_name xxx.net www.xxx.net;
...
}
server {
listen 192.168.1.2:80 default_server;
server_name www.;
...
}
二，一个简单PHP站点配置
一个典型的，简单的PHP站点中，nginx怎样为一个请求选择location来处理：
server {
listen 80;
server_name xxx.org www.xxx.org;
root /data/www;
location / {
index index.html index.php;
}
location ~* \.(gif|jpg|png)$ {
expires 30d;
}
location ~ \.php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
}
首先，nginx使用前缀匹配找出最准确的location，这一步nginx会忽略location在配置文件出现的顺序。
上面的配置中，唯一的前缀匹配location是"/"，而且因为它可以匹配任意的请求，所以被作为最后一个选择。
接着，nginx继续按照配置中的顺序依次匹配正则表达式的location，匹配到第一个正则表达式后停止搜索。
匹配到的location将被使用。如果没有匹配到正则表达式的location，则使用刚刚找到的最准确的前缀匹配的location。
请注意所有location匹配测试只使用请求的URI部分，而不使用参数部分。这是因为写参数的方法很多，比如：
/index.php?user=john&page=1
/index.php?page=1&user=john
除此以外，任何人在请求串中都可以随意添加字符串：
/index.php?page=1&something+else&user=john
来看下使用上面的配置，请求是怎样被处理的：
请求"/logo.gif"首先匹配上location "/"，然后匹配上正则表达式"\.(gif|jpg|png)$"。因此，它将被后者处理。根据"root /data/www"指令，nginx将请求映射到文件/data/www/logo.gif"，并发送这个文件到客户端。
请求"/index.php"首先也匹配上location "/"，然后匹配上正则表达式"\.(php)$"。 因此，它将被后者处理，进而被发送到监听在localhost:9000的FastCGI服务器。fastcgi_param指令将FastCGI的参数SCRIPT_FILENAME的值设置为"/data/www/index.php"，接着FastCGI服务器执行这个文件。变量$document_root等于root指令设置的值，变量$fastcgi_script_name的值是请求的uri，"/index.php"。
请求"/about.html"仅能匹配上location "/"，因此，它将使用此location进行处理。根据"root /data/www"指令，nginx将请求映射到文件"/data/www/about.html"，并发送这个文件到客户端。
请求"/"的处理更为复杂。它仅能匹配上location "/"，因此，它将使用此location进行处理。
然后，index指令使用它的参数和"root /data/www"指令所组成的文件路径来检测对应的文件是否存在。
如果文件/data/www/index.html不存在，而/data/www/index.php存在，此指令将执行一次内部重定向到"/index.php"，接着nginx将重新寻找匹配"/index.php"的location，就好像这次请求是从客户端发过来一样。
正如之前看到的那样，这个重定向的请求最终交给FastCGI服务器来处理。