Nginx 教程：配置静态内容服务器

可以在索引指令名称中存储多个文件以显示。 NGINX 按指定顺序搜索文件并返回找到的第一个文件。

location / {
    index index.$geo.html index.html index.html;
}

这里使用的变量$geo是通过geo命令设置的自定义变量。该变量的值取决于客户端的 IP 地址。
为了返回索引文件，NGINX 检查它是否存在，然后通过将索引文件的名称附加到基本 URI 来内部转发获得的 URI。内部重定向会导致对一个位置 (location) 进行新搜索，并可能最终到达另一位置 (location)，如下例所示：

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 分配到第二个位置 (location)。因此该请求是代理请求。

2。尝试几个选项

try_files 指令可用于检查指定的文件或目录是否存在并在内部重定向，如果指定的文件或目录不存在则返回特定的状态代码。例如，要检查是否存在与请求 URI 匹配的文件，请使用指令 try_files 和变量 $uri，如下所示：

server {
    root /www/data;

    location /images/ {
        try_files $uri /images/default.gif;
    }
}

文件以表单中指定的 URI 开头，并使用在当前位置或虚拟服务器的上下文中设置的指令 root 或 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;
}

3。优化 NGINX 提供内容的速度

加载速度是提供内容时的关键因素。对 NGINX 配置进行小的优化可以提高工作效率并帮助实现最佳性能。

启用文件发送

默认情况下，NGINX 会自动处理文件传输，并在发送文件之前将文件复制到缓冲区。启用 sendfile 指令消除了将数据复制到缓冲区的步骤，并允许将数据直接从一个文件描述符复制到另一个文件描述符。或者，为了防止一个高速连接完全消耗工作流程，您可以通过定义 sendfile_max_chunk 语句来限制单个 sendfile() 调用中传输的数据量：

location /mp3 {
    sendfile           on;
    sendfile_max_chunk 1m;
    ...
}

启用tcp_nopush

将 tcp_nopush 选项与 sendfile 一起使用。此选项允许 NGINX 在通过 sendfile

location /mp3 {
    sendfile   on;
    tcp_nopush on;
    ...
}

检索数据片段后在数据包中发送 HTTP 响应标头 启用 tcp_nodelay

tcp_nodelay 选项可以替换 Nagle 的覆盖算法，被设计解决慢速网络中小数据包的问题。该算法将大量小数据包合并为较大数据包，并以200 ms的延迟传输数据包。
如今，在服务大型静态文件时，无论数据包大小如何，都可以立即发送数据。延迟还会影响在线应用程序（SSH、在线游戏、在线交易）。默认情况下，指令tcp_nodelay设置为on，表示禁用Nagle算法。此选项仅适用于 Keepalive 连接：

location /mp3  {
    tcp_nodelay       on;
    keepalive_timeout 65;
    ...
}

优化积压队列

重要因素之一是 NGINX 处理传入连接的速度。一般的规则是，当一个连接建立时，它被放入监听连接的“监听”队列中。在正常负载下，很少或没有排队。但在高负载下，队列可能会急剧增长，从而导致性能不均匀、连接丢失和延迟。

测量监听队列

让我们看看当前的监听队列。运行命令：

netstat -Lan

命令输出可能如下所示：

Current listen queue sizes (qlen/incqlen/maxqlen)
Listen         Local Address         
0/0/128        *.12345            
10/0/128        *.80       
0/0/128        *.8080

命令输出显示端口 80 的侦听队列中有 10 未接受的连接，并且连接限制为128连接，这种情况属于正常现象。
但是，命令输出可能如下所示：

Current listen queue sizes (qlen/incqlen/maxqlen)
Listen         Local Address         
0/0/128        *.12345            
192/0/128        *.80       
0/0/128        *.8080

命令输出显示 192 个不可接受的连接，超出了 128 个连接限制。如果网站流量很大，通常会发生这种情况。为了获得最佳性能，请在操作系统和 NGINX 配置中增加 NGINX 队列可以接收的最大连接数。

调整操作系统
将键 net.core.somaxconn 的值从默认值 (128) 增加到足以处理高突发流量的值：

对于 FreeBSD，运行命令：

sudo sysctl kern.ipc.somaxconn=4096

对于 FreeBSD，运行命令：

sudo sysctl -w net.core.somaxconn=4096

打开文件：/etc/sysctl.conf，将以下行添加到文件并保存 文档：

net.core.somaxconn = 4096

NGINX

调 如果somaxconn 设置为大于512 的值，请更改 NGINX 监听的参数backlog对应的语句：