配置 NGINX
以提供静态内容,具有特定于类型的根目录、文件存在检查和性能优化。
root
指令指定将用于搜索文件的根目录。为了获取请求文件的路径,NGINX
将请求 URI
附加到 root
指令指定的路径中。该指令可以放置在 http {}
、 server {}
或 location {}
上下文中的任何级别上。在下面的示例中,该 root
指令是为虚拟服务器定义的。它适用于所有 location {}
未包含指令 root
以显式重新定义根的块:
server {
root /www/data;
location / {
}
location /images/ {
}
location ~ \.(mp3|mp4) {
root /www/media;
}
}
在这里,NGINX
在文件系统的 /www/data/images/
目录中搜索以 开头的 /images/ URI
。但是,如果 URI
以 .mp3 or .mp4
扩展名结尾,则 NGINX
会改为在 /www/media/
目录中搜索文件,因为它是在匹配 location
块中定义的。
如果请求以斜杠结尾,NGINX
会将其视为对目录的请求,并尝试在目录中查找索引文件。index
指令定义索引文件的名称(默认值为 index.html
)。要继续该示例,如果请求 URI
为 /images/some/path/
,则 NGINX
会传递文件 /www/data/images/some/path/index.html
(如果存在)。如果没有,NGINX
默认返回 HTTP
代码 404 (Not Found
) 。要将 NGINX
配置为返回自动生成的目录列表,请将 on
参数包含在 autoindex
指令中:
location /images/ {
autoindex on;
}
可以在 index
指令中列出多个文件名。NGINX
按指定顺序搜索文件并返回找到的第一个文件。
location / {
index index.$geo.html index.htm index.html;
}
此处使用的变量是通过 geo
指令设置的自定义 $geo
变量。变量的值取决于客户端的 IP
地址。
为了返回索引文件,NGINX
会检查它是否存在,然后对通过将索引文件的名称附加到基本 URI
来获取的 URI
进行内部重定向。内部重定向会导致对某个位置进行新的搜索,并可能最终进入另一个位置,如以下示例所示:
location / {
root /data;
index index.html index.php;
}
location ~ \.php {
fastcgi_pass localhost:8000;
#...
}
在这里,如果请求中的 URI
是 /path/
,并且 /data/path/index.html
不存在但/data/path/index.php
存在,则内部重定向 /path/index.php
将映射到第二个位置。因此,请求被代理。
案例1:获取指定图片
在data/image目录下有张图片:
配置nginx
尝试获取图片
以上配置了两种方式:
方式1:通过root
指令配置的根目录进行访问:
http://localhost:8083/image/nginx.jpg
nginx
会自动将请求URL
和root
指令指定的目录进行拼接查询.(/data/image/nginx.jpg
)
方式2:通过root指令配置根目录和index指令配置索引文件进行访问:
http://localhost:8083/image/
nginx
自动将请求URL
和root
指令指定的目录进行拼接.(/data/image/
),再根据index
指令指定文件进行查找。
案例2:列出指定目录列表
配置如下:使用 autoindex
指令
访问http://localhost:8084/image
效果如下:
try_files
指令可用于检查指定的文件或目录是否存在;NGINX
会进行内部重定向,否则会返回指定的状态代码。例如,要检查是否存在与请求 URI
对应的文件,请使用 try_files
指令和 $uri
变量,如下所示:
server {
root /www/data;
location /images/ {
try_files $uri /images/default.gif;
}
}
该文件以 URI
的形式指定,该 URI
使用在当前位置或虚拟服务器的上下文中设置的 root or alias
指令进行处理。在这种情况下,如果与原始 URI
对应的文件不存在,NGINX
会进行内部重定向到最后一个参数指定的 URI
,并返回 /www/data/images/default.gif
.
最后一个参数也可以是状态代码(紧跟等号)或位置名称。在以下示例中,如果 try_files
指令的任何参数均未解析为现有文件或目录,则返回 404 错误。
location / {
try_files $uri $uri/ $uri.html =404;
}
在下一个示例中,如果原始 URI
和带有附加尾部斜杠的 URI
都未解析到现有文件或目录,则请求将重定向到命名位置,该位置将其传递到代理服务器。
location / {
try_files $uri $uri/ @backend;
}
location @backend {
proxy_pass http://backend.example.com;
}
参考:
1.参考1
加载速度是提供任何内容的关键因素。对 NGINX
配置进行细微优化可能会提高工作效率并有助于达到最佳性能.
sendfile
NGINX
自行处理文件传输,并在发送文件之前将文件复制到缓冲区中。启用 sendfile
指令可消除将数据复制到缓冲区的步骤,并允许将数据从一个文件描述符直接复制到另一个文件描述符。或者,为了防止一个快速连接完全占用工作进程,可以使用 sendfile_max_chunk
指令来限制单个 sendfile()
调用中传输的数据量(在此示例中为 1 MB
):location /mp3 {
sendfile on;
sendfile_max_chunk 1m;
#...
}
tcp_nopush
tcp_nopush
指令与 sendfile on
; 指令一起使用。这使 NGINX
能够在 获取数据块后立即在一个数据包中发送 HTTP
响应标头 sendfile()
。location /mp3 {
sendfile on;
tcp_nopush on;
#...
}
tcp_nodelay
tcp_nodelay
指令允许覆盖 Nagle
的算法,该算法最初设计用于解决慢速网络中的小数据包问题。该算法将多个小数据包合并为一个较大的数据包,并以 200 毫秒的延迟发送数据包。如今,在提供大型静态文件时,无论数据包大小如何,都可以立即发送数据。延迟还会影响在线应用程序(ssh
、在线游戏、在线交易等)。默认情况下,tcp_nodelay
指令设置为 on
这意味着 Nagle
的算法处于禁用状态。仅将此指令用于 keepalive
连接:location /mp3 {
tcp_nodelay on;
keepalive_timeout 65;
#...
}
其中一个重要因素是 NGINX
处理传入连接的速度。一般规则是,当建立连接时,将其放入侦听套接字的“侦听”队列中。在正常负载下,要么队列很小,要么根本没有队列。但在高负载下,队列可能会急剧增长,从而导致性能不均衡、连接断开和延迟增加。
netstat -Lan
输出可能如下所示,这表明在端口 80 上的侦听队列中,存在针对配置的最大排队连接数 128 的 10 未接受连接。这种情况是正常的。
Current listen queue sizes (qlen/incqlen/maxqlen)
Listen Local Address
0/0/128 *.12345
10/0/128 *.80
0/0/128 *.8080
相反,在以下命令中,未接受的连接数 ( 192 ) 超过了 的限制 128 。当网站流量很大时,这种情况很常见。为了实现最佳性能,您需要增加在操作系统和 NGINX
配置中可以排队等待 NGINX
接受的最大连接数。
net.core.somaxconn
内核参数的值从其默认值 ( 128 ) 增加到足够高的值,以应对大量流量突发。在此示例中,它增加到 4096 .
sudo sysctl kern.ipc.somaxconn=4096
sudo sysctl -w net.core.somaxconn=4096
net.core.somaxconn = 4096
如果将 somaxconn
内核参数设置为大于 512 的值,请将 backlog
参数更改为 NGINX listen
指令以匹配:
server {
listen 80 backlog=4096;
# ...
}