nginx ngx_http_module(1) 指令详解
相关链接
一、目录
1.1 模块简介
- ngx_http_core_module：这是 Nginx 中非常重要的一个核心模块，它包含了对 HTTP 协议处理的基本配置项和指令。该模块定义了 Nginx 如何处理客户端的 HTTP 请求以及如何响应这些请求。具体来说，它涉及到了诸如服务器名称、监听端口、虚拟主机设置、URI 的解析规则、文件路径的匹配方式等基本配置。此外，它还负责管理请求的转发、错误页面的定制、客户端请求体的大小限制等功能。
1.2 指令目录
1.2.1 ngx_http_core_module
- absolute_redirect
- aio
- aio_write
- alias
- auth_delay
- chunked_transfer_encoding
- client_body_buffer_size
- client_body_in_file_only
- client_body_in_single_buffer
- client_body_temp_path
- client_body_timeout
- client_header_buffer_size
- client_header_timeout
- client_max_body_size
- connection_pool_size
- default_type
- directio
- directio_alignment
- disable_symlinks
- error_page
- etag
- http
- if_modified_since
- ignore_invalid_headers
- internal
- keepalive_disable
- keepalive_min_timeout
- keepalive_requests
- keepalive_time
- keepalive_timeout
- large_client_header_buffers
- limit_except
- limit_rate
- limit_rate_after
- lingering_close
- lingering_time
- lingering_timeout
- listen
- location
- log_not_found
- log_subrequest
- max_ranges
- merge_slashes
- msie_padding
- msie_refresh
- open_file_cache
- open_file_cache_errors
- open_file_cache_min_uses
- open_file_cache_valid
- output_buffers
- port_in_redirect
- postpone_output
- read_ahead
- recursive_error_pages
- request_pool_size
- reset_timedout_connection
- resolver
- resolver_timeout
- root
- satisfy
- send_lowat
- send_timeout
- sendfile
- sendfile_max_chunk
- server
- server_name
- server_name_in_redirect
- server_names_hash_bucket_size
- server_names_hash_max_size
- server_tokens
- subrequest_output_buffer_size
- tcp_nodelay
- tcp_nopush
- try_files
- types
- types_hash_bucket_size
- types_hash_max_size
- underscores_in_headers
- variables_hash_bucket_size
- variables_hash_max_size
二、解释
2.1 ngx_http_core_module
ngx_http_core_module 是 Nginx 中的核心模块，负责处理 HTTP 请求的基本功能和配置。它定义了如何处理客户端请求的基础规则，并提供了许多指令来配置服务器的行为。这个模块是构建高性能、高可靠性的 Web 服务器的基础。
主要功能
- 基本配置：通过该模块可以设置基本的服务器参数，如监听端口、服务域名等。
- 资源定位：使用
location指令可以根据 URL 路径匹配规则来指定如何处理不同类型的请求。 - 文件路径解析：通过
root和alias指令，可以定义请求的文件系统路径，帮助 Ngin jadx 找到请求的资源位置。 - 默认文档：利用
index指令设定当访问目录时，默认加载的文档名（如index.html）。 - 性能调优：提供多种指令用于调整缓冲区大小、超时时间等，以优化服务器性能。
- 错误页面：允许自定义错误页面，改善用户体验。
常用指令
以下是一些常用的配置指令及其简要说明：
-
listen: 指定 Nginx 监听的 IP 地址和端口。例如，
listen 80;表示监听所有网络接口上的 80 端口。 -
server_name: 设置虚拟主机的域名或 IP 地址。这使得 Nginx 可以根据不同的域名或 IP 地址提供不同的网站内容。
-
location: 定义如何处理与特定 URL 匹配的请求。可以使用正则表达式进行更精确的控制。
-
root: 指定用于查找请求文件的根目录。
root指令会在其后追加请求的 URI 来确定文件的实际路径。 -
alias: 类似于
root，但它是直接替换掉请求的 URI 部分，而不是在其后追加。 -
index: 设置默认的主页文件名，比如
index.html。 -
client_max_body_size: 设置允许客户端请求的最大主体大小，防止上传过大的文件导致服务器崩溃。
-
keepalive_timeout: 设置保持连接的超时时间，减少频繁建立连接的开销。
-
error_page: 设置自定义的错误页面，改善用户体验并提高专业性。
使用示例
下面是一个完整的示例配置，展示如何设置一个基本的 Web 服务器：
server {
# 监听所有网络接口上的 80 端口
listen 80;
# 设置虚拟主机的域名
server_name example.com www.example.com;
# 设置网站的根目录
root /var/www/html;
# 设置默认首页文件
index index.html index.htm;
# 处理对 /images/ 的请求
location /images/ {
# 设置别名路径
alias /var/www/images/;
}
# 自定义 404 页面
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
# 设置最大请求体大小为 10MB
client_max_body_size 10m;
# 设置保持连接的超时时间为 65 秒
keepalive_timeout 65;
}
注意事项
- 安全性：确保正确配置 SSL/TLS 加密和其他安全相关的设置，避免中间人攻击。
- 性能优化：根据实际情况调整缓冲区大小、超时时间等参数，以优化性能。
- 日志记录：合理配置日志级别和格式，以便于监控和故障排查。
- 测试验证：在部署前进行全面测试，确保所有配置都能按预期工作。
2.1.1 指令列表
absolute_redirect
absolute_redirect 指令用于控制 Nginx 是否将 HTTP 重定向响应转换为绝对 URL 形式。默认情况下，Nginx 会返回绝对 URL 的重定向响应，这对于确保客户端能够正确地定位资源位置特别有用，尤其是在反向代理场景中。
Syntax: absolute_redirect on | off;
Default: absolute_redirect on;
Context: http, server, location
This directive appeared in version 1.11.8.
on | off：决定是否启用绝对 URL 重定向。on（默认值）：启用绝对 URL 重定向。当 Nginx 返回一个重定向响应时，它将以完整的绝对 URL 形式返回（例如，http://example.com/new_location）。off：禁用绝对 URL 重定向。此时，Nginx 将返回相对路径的重定向响应（例如，/new_location）。
案例
基本用法
最简单的 absolute_redirect 用法是指定是否启用该功能：
server {
listen 80;
server_name example.com;
# 启用绝对 URL 重定向
absolute_redirect on;
location /old-location {
return 301 /new-location;
}
}
在这个例子中：
- 当用户访问
/old-location时，Nginx 将返回一个带有完整 URL 的 301 重定向响应（例如，http://example.com/new-location）。
禁用绝对 URL 重定向
如果你希望禁用绝对 URL 重定向，可以将 absolute_redirect 设置为 off：
server {
listen 80;
server_name example.com;
# 禁用绝对 URL 重定向
absolute_redirect off;
location /old-location {
return 301 /new-location;
}
}
在这个例子中：
- 当用户访问
/old-location时，Nginx 将返回一个相对路径的 301 重定向响应（例如，/new-location）。
在特定的
location块中设置
你可以根据需要为每个 location 块设置不同的 absolute_redirect 配置：
server {
listen 80;
server_name example.com;
location /relative {
# 禁用绝对 URL 重定向
absolute_redirect off;
return 301 /new-relative-location;
}
location /absolute {
# 启用绝对 URL 重定向（默认行为）
absolute_redirect on;
return 301 /new-absolute-location;
}
}
在这个例子中：
- 访问
/relative时，Nginx 将返回相对路径的重定向响应（例如，/new-relative-location）。 - 访问
/absolute时，Nginx 将返回绝对 URL 的重定向响应（例如，http://example.com/new-absolute-location）。
注意事项
-
兼容性：某些旧版浏览器或客户端可能对相对路径的重定向支持不佳，因此在生产环境中建议谨慎使用
absolute_redirect off。 -
反向代理场景：在反向代理配置中，如果后端服务器返回了相对路径的重定向响应，而你希望前端客户端直接接收到绝对 URL 的重定向响应，确保启用了
absolute_redirect on。
aio
aio 指令在Nginx中用于控制是否启用异步I/O以及如何管理这些I/O操作。这有助于优化文件读取性能，特别是在高负载情况下。
Syntax: aio on | off | threads[=pool];
Default: aio off;
Context: http, server, location
This directive appeared in version 0.8.11.
on：启用Linux的epoll机制下的异步I/O。off：禁用异步I/O（默认行为）。threads[=pool]：使用线程池来处理I/O操作。可选参数pool指定要使用的线程池名称。
案例
基本案例
最简单的aio用法是指定是否启用异步I/O：
server {
listen 80;
server_name example.com;
location /large-files {
aio on; # 启用异步I/O
sendfile on; # 配合sendfile使用以优化大文件传输
}
}
在这个例子中，当用户访问/large-files路径下的资源时，Nginx将启用异步I/O来提高大文件的读取效率。
线程池处理I/O
使用线程池来处理I/O操作的例子如下：
http {
aio threads=default; # 使用默认线程池处理I/O操作
server {
listen 80;
server_name example.com;
location /large-files {
aio threads=default; # 在location块中也指定使用线程池
sendfile on; # 配合sendfile使用以优化大文件传输
}
}
}
在这个例子中，Nginx将使用名为default的线程池来处理所有I/O操作，从而进一步优化性能。
在特定的
location块中设置
根据需要为不同的location块设置不同的aio配置：
server {
listen 80;
server_name example.com;
location /large-files {
aio on; # 启用异步I/O
sendfile on; # 配合sendfile使用以优化大文件传输
}
location /small-files {
aio off; # 禁用异步I/O
}
}
在这个例子中：
- 第一个
location块启用了异步I/O，适用于处理大文件。 - 第二个
location块禁用了异步I/O，适用于处理小文件或不需要异步I/O优化的场景。
注意事项
-
性能考虑：虽然异步I/O和线程池可以显著提高性能，但它们也会增加系统的复杂性和资源消耗。确保在实际环境中进行充分测试，以确定最佳配置。
-
兼容性：
aio指令依赖于操作系统支持。确保您的操作系统版本支持所需的异步I/O功能，并且内核配置正确。 -
线程池配置：如果使用线程池（
threads），请确保正确配置线程池大小和其他相关参数，以避免资源争用或不足的问题。
通过灵活运用aio指令，可以根据具体需求调整Nginx的行为，从而更好地满足应用的性能要求。
aio_write
aio_write 指令用于控制Nginx是否启用异步写操作（Asynchronous Write）。启用异步写操作可以使Nginx在处理大文件上传或其他需要大量写操作的场景时提高性能。此指令自Nginx版本1.9.13起可用。
Syntax: aio_write on | off;
Default: aio_write off;
Context: http, server, location
on：启用异步写操作。这需要操作系统支持，并且通常与直接使用磁盘I/O结合使用。off：禁用异步写操作。这是默认行为。
案例
基本用法
最简单的 aio_write 用法是指定一个或多个配置项：
server {
listen 80;
server_name example.com;
location /upload/ {
# 启用异步写操作
aio_write on;
# 确保sendfile也启用以充分利用异步I/O的优势
sendfile on;
}
}
在这个例子中：
- 启用了
aio_write on，当上传文件到/upload/目录时，Nginx会使用异步写操作来提高大文件上传性能。
结合其他配置项
为了更好地管理写操作性能，你可以结合其他配置项使用 aio_write：
server {
listen 80;
server_name example.com;
location /upload/ {
aio_write on; # 启用异步写操作
sendfile on; # 确保sendfile也启用
directio 512k; # 对大于512KB的文件使用直接I/O
# 设置输出缓冲区大小
output_buffers 1 256k;
}
location /static/ {
aio_write off; # 禁用异步写操作
sendfile on; # 仅使用sendfile
}
}
在这个例子中：
- 第一个
location块启用了aio_write和directio，并设置了输出缓冲区大小，适用于大文件上传。 - 第二个
location块禁用了aio_write，仅使用sendfile，适用于静态文件传输。
注意事项
- 操作系统支持：确保你的操作系统支持异步写操作功能。Linux系统通常需要内核版本较高才能完全支持。
- 性能测试：在生产环境中使用之前，务必进行充分的性能测试，以验证异步写操作是否确实提高了性能。
- 适用场景：异步写操作更适合于处理大文件上传或其他需要大量写操作的场景，对于小文件上传或静态文件传输可能不会带来显著的性能提升，甚至可能增加开销。
- 与其他指令结合使用：异步写操作通常与
directio和output_buffers等指令结合使用，以进一步优化性能。
alias
alias 指令用于指定一个目录路径，Nginx会将请求映射到这个目录下。与root指令不同，alias会在匹配的location块中替换掉URI的部分，而不是简单地追加到URI后面。
Syntax: alias path;
Default: —
Context: location
path：指定请求应映射到的实际文件系统路径。
案例
基本用法
最简单的alias用法是指定一个替代路径来处理请求：
server {
listen 80;
server_name example.com;
location /static/ {
alias /var/www/static_files/; # 当请求/static/下的资源时，实际查找/var/www/static_files/
}
}
在这个例子中，如果用户访问http://example.com/static/image.jpg，Nginx会从服务器上的/var/www/static_files/image.jpg路径提供该文件。
处理复杂路径
使用alias处理复杂路径的例子如下：
server {
listen 80;
server_name example.com;
location /downloads/app/ {
alias /opt/data/apps/; # 当请求/downloads/app/下的资源时，实际查找/opt/data/apps/
}
location /uploads/user_content/ {
alias /srv/user_uploads/; # 当请求/uploads/user_content/下的资源时，实际查找/srv/user_uploads/
}
}
在这个例子中：
- 第一个
location块将/downloads/app/下的请求映射到/opt/data/apps/目录。 - 第二个
location块将/uploads/user_content/下的请求映射到/srv/user_uploads/目录。
在特定的
location块中设置
根据需要为不同的location块设置不同的alias配置：
server {
listen 80;
server_name example.com;
location /images/ {
alias /var/www/images/; # 映射到/var/www/images/
}
location /videos/ {
alias /var/www/videos/; # 映射到/var/www/videos/
}
}
在这个例子中：
/images/路径下的请求会被映射到/var/www/images/目录。/videos/路径下的请求会被映射到/var/www/videos/目录。
注意事项
-
路径末尾斜杠：确保
alias路径和location路径是否以斜杠结尾保持一致。例如，如果location以斜杠结尾（如/static/），则alias也应以斜杠结尾（如/var/www/static_files/）。否则，可能会导致路径不匹配的问题。 -
与
root的区别：alias会替换掉location中的部分路径，而root则是直接将请求路径附加在其后。例如，对于location /static/ { root /var/www; }，请求/static/file.txt会被映射到/var/www/static/file.txt；而对于location /static/ { alias /var/www/static_files/; }，同样的请求会被映射到/var/www/static_files/file.txt。 -
安全性：确保别名路径的安全性，避免将敏感目录暴露给外部访问。可以通过适当的权限设置和访问控制策略来保护这些目录。
auth_delay
auth_delay 指令在Nginx中用于设置认证延迟时间，即在用户认证失败后，服务器在返回错误响应之前等待的时间。此功能主要用于防御暴力破解攻击，通过增加每次尝试之间的延迟来降低攻击效率。默认情况下，该指令被设置为 0s，意味着没有额外的延迟。
Syntax: auth_delay time;
Default: auth_delay 0s;
Context: http, server, location
This directive appeared in version 1.17.10.
time：指定延迟的时间长度，格式可以是秒（如5s）或毫秒（如500ms）。如果设置为0s，则表示不启用延迟。
案例
基本用法
最简单的 auth_delay 使用方法是指定一个延迟时间，以增加每次认证失败后的等待时间：
server {
listen 80;
server_name example.com;
location /secure {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/htpasswd;
auth_delay 2s; # 设置认证失败后的延迟时间为2秒
}
}
在这个例子中，如果用户认证失败，Nginx会在返回错误响应之前等待2秒钟。这可以有效减慢暴力破解尝试的速度。
禁用延迟
如果您不希望在认证失败后引入任何延迟，可以将 auth_delay 设置为 0s 或直接省略该指令（因为它已经是默认值）：
server {
listen 80;
server_name example.com;
location /public {
auth_basic "Public Area";
auth_basic_user_file /etc/nginx/htpasswd;
auth_delay 0s; # 禁用认证失败后的延迟
}
}
在这个例子中，认证失败后不会有任何延迟，系统会立即返回错误响应。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他配置项使用 auth_delay：
server {
listen 80;
server_name example.com;
location /admin {
auth_basic "Admin Area";
auth_basic_user_file /etc/nginx/htpasswd;
auth_delay 3s; # 设置认证失败后的延迟时间为3秒
limit_except GET POST {
deny all;
}
}
location /api {
auth_basic "API Area";
auth_basic_user_file /etc/nginx/htpasswd;
auth_delay 1s; # 设置认证失败后的延迟时间为1秒
proxy_pass http://backend-api;
}
}
在这个例子中：
/admin路径下的请求，在认证失败后会有3秒的延迟。/api路径下的请求，在认证失败后会有1秒的延迟，并且所有请求都会被代理到后台API服务器。
注意事项
- 安全性：虽然增加认证失败后的延迟可以帮助抵御暴力破解攻击，但过长的延迟可能会影响用户体验。请根据实际情况调整延迟时间。
- 性能影响：虽然小量的延迟对大多数应用来说是可以接受的，但在高并发场景下，过多的延迟可能会累积并影响整体性能。因此，请谨慎选择延迟时间。
- 兼容性：确保客户端和下游服务器能够适应这种延迟机制，特别是在涉及复杂的交互逻辑时。
chunked_transfer_encoding
chunked_transfer_encoding 指令用于控制 Nginx 是否在响应中使用分块传输编码（Chunked Transfer Encoding）。分块传输编码允许服务器将数据分割成多个部分（块）发送给客户端，而不需要事先知道整个响应的大小。这对于动态生成的内容尤其有用。
Syntax: chunked_transfer_encoding on | off;
Default: chunked_transfer_encoding on;
Context: http, server, location
on | off：决定是否启用分块传输编码。on（默认值）：启用分块传输编码。Nginx 将使用分块传输编码方式发送响应。off：禁用分块传输编码。此时，Nginx 将不会使用分块传输编码方式发送响应。
案例
基本用法
最简单的 chunked_transfer_encoding 用法是指定是否启用该功能：
server {
listen 80;
server_name example.com;
# 启用分块传输编码
chunked_transfer_encoding on;
location /dynamic-content {
proxy_pass http://backend_server;
}
}
在这个例子中：
- 当用户访问
/dynamic-content时，Nginx 将使用分块传输编码方式将后端服务器返回的动态内容发送给客户端。
禁用分块传输编码
如果你希望禁用分块传输编码，可以将 chunked_transfer_encoding 设置为 off：
server {
listen 80;
server_name example.com;
# 禁用分块传输编码
chunked_transfer_encoding off;
location /static-content {
root /var/www/html;
}
}
在这个例子中：
- 当用户访问
/static-content时，Nginx 将不会使用分块传输编码方式发送静态文件内容。
在特定的
location块中设置
你可以根据需要为每个 location 块设置不同的 chunked_transfer_encoding 配置：
server {
listen 80;
server_name example.com;
location /dynamic {
# 启用分块传输编码
chunked_transfer_encoding on;
proxy_pass http://backend_server;
}
location /static {
# 禁用分块传输编码
chunked_transfer_encoding off;
root /var/www/html;
}
}
在这个例子中：
- 访问
/dynamic时，Nginx 将使用分块传输编码方式发送后端服务器返回的动态内容。 - 访问
/static时，Nginx 将不会使用分块传输编码方式发送静态文件内容。
注意事项
-
兼容性：某些旧版 HTTP 客户端可能不支持分块传输编码。如果您的应用需要支持这些客户端，建议在相应的
location块中禁用分块传输编码。 -
性能考虑：对于动态生成的大文件或流式数据，启用分块传输编码可以提高性能和减少内存占用，因为它允许逐步发送数据而不是等待整个响应生成完毕。
client_body_buffer_size
client_body_buffer_size 指令在 Nginx 中用于设置客户端请求体（body）的缓冲区大小。这个指令影响着 Nginx 处理 POST 请求等包含实体主体的数据时所使用的内存缓冲区大小。如果请求体超过了指定的缓冲区大小，Nginx 会将数据写入临时文件而不是保持在内存中。
Syntax: client_body_buffer_size size;
Default: client_body_buffer_size 8k|16k;
Context: http, server, location
size：指定每个连接的客户端请求体的缓冲区大小。默认情况下，对于 32 位系统是 8KB (8k)，对于 64 位系统是 16KB (16k)。
案例
基本用法
最简单的 client_body_buffer_size 用法是指定一个适合你应用需求的缓冲区大小：
server {
listen 80;
server_name example.com;
client_body_buffer_size 32k; # 设置客户端请求体缓冲区大小为32KB
location /upload {
proxy_pass http://backend;
}
}
在这个例子中：
- 所有到达
/upload的 POST 请求都将使用 32KB 的缓冲区来存储请求体。如果请求体超过 32KB，Nginx 将把超出部分写入临时文件。
根据上下文调整缓冲区大小
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 client_body_buffer_size 的值：
http {
client_body_buffer_size 16k; # 全局设置为16KB
server {
listen 80;
server_name example.com;
location /small-uploads {
client_body_buffer_size 8k; # 特定位置设置为8KB
proxy_pass http://backend;
}
location /large-uploads {
client_body_buffer_size 64k; # 特定位置设置为64KB
proxy_pass http://backend;
}
}
}
在这个例子中：
- 对于全局配置，默认缓冲区大小被设置为 16KB。
/small-uploads位置块中的请求使用较小的 8KB 缓冲区。/large-uploads位置块中的请求则使用较大的 64KB 缓冲区，适用于处理更大的上传文件。
结合其他配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 client_body_buffer_size：
server {
listen 80;
server_name example.com;
client_body_buffer_size 32k; # 设置客户端请求体缓冲区大小为32KB
client_max_body_size 50m; # 设置允许的最大请求体大小为50MB
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
location /upload {
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
}
}
在这个例子中：
- 设置了客户端请求体缓冲区大小为 32KB。
- 允许的最大请求体大小为 50MB，以防止过大的上传导致服务器负担过重。
- 设置了读取请求体和代理连接、读取响应的超时时间，确保长时间没有活动的连接能及时关闭，释放资源。
注意事项
- 内存使用与性能：较大的缓冲区可以减少磁盘 I/O，提高处理速度，但也会增加内存占用。应根据实际应用场景和服务器资源合理设置。
- 临时文件：当请求体超过缓冲区大小时，Nginx 会将数据写入临时文件。这可能会导致额外的磁盘 I/O 开销，尤其是在高并发场景下需要注意。
- 安全性：合理设置
client_max_body_size和client_body_buffer_size可以有效防止恶意用户通过大文件上传攻击服务器。同时，确保临时文件目录权限正确，避免敏感信息泄露。
client_body_in_file_only
client_body_in_file_only 指令用于控制客户端请求体是否总是存储在文件中。此指令可以帮助调试和处理大请求体，但需要注意其对系统资源的影响。默认情况下，该指令是关闭的。
Syntax: client_body_in_file_only on | clean | off;
Default: client_body_in_file_only off;
Context: http, server, location
on：始终将客户端请求体存储在一个临时文件中，并且不会删除该文件。这有助于调试，但会占用磁盘空间。clean：始终将客户端请求体存储在一个临时文件中，但在请求处理完成后删除该文件。适合需要临时存储请求体但不希望长期占用磁盘空间的场景。off：仅当请求体大小超过配置的缓冲区时，才将请求体存储在临时文件中。这是默认行为。
案例
基本用法
最简单的 client_body_in_file_only 用法是指定一个或多个配置项：
server {
listen 80;
server_name example.com;
location /upload/ {
# 启用并保留请求体文件
client_body_in_file_only on;
# 设置客户端请求体的最大大小
client_max_body_size 100M;
}
}
在这个例子中：
- 启用了
client_body_in_file_only on，所有上传到/upload/目录的请求体都会被存储在一个临时文件中，并且这些文件不会被自动删除。
使用
clean选项
你可以根据需要使用 clean 选项来临时存储请求体并在请求处理完成后删除文件：
server {
listen 80;
server_name example.com;
location /upload/ {
# 启用并临时存储请求体文件
client_body_in_file_only clean;
# 设置客户端请求体的最大大小
client_max_body_size 100M;
}
}
在这个例子中：
- 启用了
client_body_in_file_only clean，所有上传到/upload/目录的请求体都会被存储在一个临时文件中，并且这些文件会在请求处理完成后被删除。
默认行为
如果你不需要特殊处理请求体，可以保持默认设置：
server {
listen 80;
server_name example.com;
location /static/ {
# 禁用特殊处理，仅在必要时存储请求体
client_body_in_file_only off;
# 设置客户端请求体的最大大小
client_max_body_size 1M;
}
}
在这个例子中：
- 保持默认设置
client_body_in_file_only off，只有在请求体大小超过配置的缓冲区时，才会将请求体存储在临时文件中。
注意事项
- 磁盘空间管理：启用
on选项会导致大量临时文件保留在磁盘上，可能很快耗尽磁盘空间，特别是在高负载环境中。确保定期清理这些文件或使用clean选项。 - 性能影响：将请求体存储在文件中可能会增加I/O操作，影响性能。对于大多数应用场景，默认设置（
off）通常是最佳选择。 - 调试用途：
on选项非常适合用于调试目的，可以帮助你检查客户端发送的完整请求体内容。 - 结合其他指令：通常与
client_max_body_size等指令结合使用，以确保正确处理大请求体。
client_body_in_single_buffer
client_body_in_single_buffer 指令用于控制Nginx是否将客户端请求的主体（body）一次性读取到一个单独的缓冲区中。这对于处理大文件上传或需要高效处理请求体的应用场景非常有用。
Syntax: client_body_in_single_buffer on | off;
Default: client_body_in_single_buffer off;
Context: http, server, location
on：启用单缓冲区模式。Nginx会尝试将整个请求主体读取到一个单独的缓冲区中。off：禁用单缓冲区模式（默认行为）。Nginx会将请求主体分块读取到多个缓冲区中。
案例
基本用法
最简单的client_body_in_single_buffer用法是指定是否启用单缓冲区模式：
server {
listen 80;
server_name example.com;
location /upload {
client_body_in_single_buffer on; # 启用单缓冲区模式
client_max_body_size 10M; # 设置最大请求主体大小为10MB
}
}
在这个例子中，当用户向/upload路径上传文件时，Nginx会尝试将整个请求主体读取到一个单独的缓冲区中，从而减少内存碎片并提高效率。
禁用单缓冲区
禁用单缓冲区模式的例子如下：
server {
listen 80;
server_name example.com;
location /upload {
client_body_in_single_buffer off; # 禁用单缓冲区模式（默认行为）
client_max_body_size 10M; # 设置最大请求主体大小为10MB
}
}
在这个例子中，Nginx将按照默认行为，将请求主体分块读取到多个缓冲区中。
在特定的
location块中设置
根据需要为不同的location块设置不同的client_body_in_single_buffer配置：
server {
listen 80;
server_name example.com;
location /small-upload {
client_body_in_single_buffer on; # 启用单缓冲区模式
client_max_body_size 1M; # 设置最大请求主体大小为1MB
}
location /large-upload {
client_body_in_single_buffer off; # 禁用单缓冲区模式
client_max_body_size 50M; # 设置最大请求主体大小为50MB
}
}
在这个例子中：
/small-upload路径下的请求会启用单缓冲区模式，适用于较小的文件上传。/large-upload路径下的请求会禁用单缓冲区模式，适用于较大的文件上传。
注意事项
-
内存使用：启用单缓冲区模式可能会导致更大的内存占用，特别是在处理大文件上传时。确保服务器有足够的内存来支持这种配置，以避免内存耗尽问题。
-
性能考虑：虽然单缓冲区模式可以减少内存碎片并提高某些场景下的性能，但它并不总是最佳选择。对于特别大的文件上传，分散到多个缓冲区可能更有效率，因为这样可以更好地利用系统的I/O和内存资源。
-
与其他指令结合使用：通常与
client_max_body_size等其他相关指令一起使用，以确保请求主体大小限制和其他相关配置的一致性。
client_body_temp_path
client_body_temp_path 指令在Nginx中用于指定存储客户端请求体的临时文件路径及其目录层次结构。当请求体的大小超过配置的缓冲区大小时，Nginx会将请求体写入到临时文件中，而不是全部保存在内存中。这有助于管理服务器资源并提高处理大文件上传等场景下的性能。
Syntax: client_body_temp_path path [level1 [level2 [level3]]];
Default: client_body_temp_path client_body_temp;
Context: http, server, location
path：指定临时文件存放的根目录。level1,level2,level3（可选）：指定目录层次结构的深度和命名规则。每个级别可以是1位或2位数字，用于创建子目录以分散文件存储，避免单个目录下文件过多导致性能下降。
案例
基本用法
最简单的 client_body_temp_path 使用方法是指定一个根目录：
server {
listen 80;
server_name example.com;
client_body_temp_path /tmp/nginx_client_body; # 设置临时文件的根目录
}
在这个例子中，所有客户端请求体的临时文件都会被存储在 /tmp/nginx_client_body 目录下。
使用多层次目录结构
为了优化文件系统性能，可以通过指定多个层级来分散文件存储：
server {
listen 80;
server_name example.com;
client_body_temp_path /tmp/nginx_client_body 1 2; # 设置临时文件的根目录，并指定两个级别的子目录
}
在这个例子中：
- 第一级子目录名称由1位数字组成。
- 第二级子目录名称由2位数字组成。
例如，一个临时文件可能存储在 /tmp/nginx_client_body/7/45/filename 这样的路径下。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他配置项使用 client_body_temp_path：
server {
listen 80;
server_name example.com;
client_body_temp_path /var/lib/nginx/body 1 2; # 设置临时文件的根目录，并指定两个级别的子目录
client_max_body_size 10m; # 设置客户端请求的最大主体大小为10MB
client_body_buffer_size 128k; # 设置用于读取客户端请求体的缓冲区大小为128KB
location /upload {
proxy_pass http://backend-server;
}
}
在这个例子中：
/var/lib/nginx/body是临时文件的根目录。- 第一级子目录名称由1位数字组成。
- 第二级子目录名称由2位数字组成。
- 客户端请求的最大主体大小被限制为10MB。
- 用于读取客户端请求体的缓冲区大小被设置为128KB。
注意事项
- 磁盘空间管理：确保指定的临时文件目录有足够的磁盘空间，特别是在处理大文件上传时。
- 性能优化：通过合理设置多级子目录，可以有效分散文件存储，避免单个目录下文件过多导致性能瓶颈。
- 权限设置：确保Nginx进程对指定的临时文件目录有读写权限，以避免运行时错误。
- 清理机制：定期检查并清理不再需要的临时文件，以释放磁盘空间。可以考虑使用定时任务或其他自动化工具来实现这一目的。
client_body_timeout
client_body_timeout 指令用于设置读取客户端请求体的超时时间。如果客户端在指定的时间内没有发送完请求体，Nginx 将返回一个 408 (Request Time-out) 错误。这个指令对于防止慢速客户端占用服务器资源非常有用。
Syntax: client_body_timeout time;
Default: client_body_timeout 60s;
Context: http, server, location
time：指定等待客户端发送请求体的超时时间。可以使用秒（例如30s）或毫秒（例如500ms）作为单位。
案例
基本用法
最简单的 client_body_timeout 用法是指定超时时间：
server {
listen 80;
server_name example.com;
# 设置客户端请求体超时时间为 30 秒
client_body_timeout 30s;
location /upload {
proxy_pass http://backend_server;
}
}
在这个例子中：
- 当用户访问
/upload并上传文件时，Nginx 将等待最多 30 秒来接收请求体。如果超过 30 秒还未完成，将返回 408 错误。
缩短超时时间
如果你希望缩短超时时间以更快地释放资源，可以将 client_body_timeout 设置为较短的时间：
server {
listen 80;
server_name example.com;
# 设置客户端请求体超时时间为 10 秒
client_body_timeout 10s;
location /quick-upload {
proxy_pass http://backend_server;
}
}
在这个例子中：
- 当用户访问
/quick-upload并上传文件时，Nginx 将等待最多 10 秒来接收请求体。如果超过 10 秒还未完成，将返回 408 错误。
在特定的
location块中设置不同的超时时间
你可以根据需要为每个 location 块设置不同的 client_body_timeout 配置：
server {
listen 80;
server_name example.com;
location /large-upload {
# 设置较长的客户端请求体超时时间
client_body_timeout 120s;
proxy_pass http://backend_server;
}
location /small-upload {
# 设置较短的客户端请求体超时时间
client_body_timeout 20s;
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/large-upload时，Nginx 将等待最多 120 秒来接收请求体。 - 访问
/small-upload时，Nginx 将等待最多 20 秒来接收请求体。
注意事项
-
性能与安全性：较短的超时时间可以帮助快速释放服务器资源，减少被慢速客户端攻击的风险。但是，过短的超时时间可能会导致合法但速度较慢的客户端请求被中断。因此，建议根据实际应用场景合理设置超时时间。
-
用户体验：确保超时时间足够长，以便用户能够顺利完成大文件上传等操作。否则，用户可能会遇到频繁的超时错误，影响体验。
client_header_buffer_size
client_header_buffer_size 指令在 Nginx 中用于设置读取客户端请求头的缓冲区大小。这个指令决定了 Nginx 为每个连接分配的初始缓冲区大小，用于存储来自客户端的 HTTP 请求头信息。如果请求头超过指定的缓冲区大小，Nginx 会自动分配更大的缓冲区。
Syntax: client_header_buffer_size size;
Default: client_header_buffer_size 1k;
Context: http, server
size：指定每个连接的客户端请求头的缓冲区大小。默认值是 1KB (1k)。对于大多数普通请求来说，默认值通常足够使用，但在处理包含大量或非常长的头部字段的请求时，可能需要增加此值。
案例
基本用法
最简单的 client_header_buffer_size 用法是指定一个适合你应用需求的缓冲区大小：
server {
listen 80;
server_name example.com;
client_header_buffer_size 2k; # 设置客户端请求头缓冲区大小为2KB
location / {
proxy_pass http://backend;
}
}
在这个例子中：
- 所有到达服务器的请求将使用 2KB 的缓冲区来存储请求头。如果请求头超过 2KB，Nginx 将自动分配更大的缓冲区。
根据上下文调整缓冲区大小
你可以根据不同的上下文（如 http, server）灵活地调整 client_header_buffer_size 的值：
http {
client_header_buffer_size 4k; # 全局设置为4KB
server {
listen 80;
server_name example.com;
client_header_buffer_size 2k; # 特定服务器块设置为2KB
location / {
proxy_pass http://backend;
}
}
server {
listen 80;
server_name another-example.com;
client_header_buffer_size 8k; # 另一特定服务器块设置为8KB
location / {
proxy_pass http://another-backend;
}
}
}
在这个例子中：
- 全局配置下，所有服务器块的默认缓冲区大小被设置为 4KB。
- 对于
example.com，请求头缓冲区大小被设置为 2KB。 - 对于
another-example.com，请求头缓冲区大小被设置为 8KB，适用于处理更大或更多的请求头数据。
结合其他配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 client_header_buffer_size：
server {
listen 80;
server_name example.com;
client_header_buffer_size 2k; # 设置客户端请求头缓冲区大小为2KB
large_client_header_buffers 4 4k; # 设置当请求头超出client_header_buffer_size时使用的缓冲区数量和大小
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
client_header_timeout 60s; # 设置读取请求头超时时间为60秒
location / {
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
}
}
在这个例子中：
- 设置了客户端请求头缓冲区大小为 2KB。
- 当请求头超出 2KB 时，使用
large_client_header_buffers来定义额外的缓冲区，这里设置为最多 4 个 4KB 的缓冲区。 - 设置了读取请求体和请求头的超时时间，确保长时间没有活动的连接能及时关闭，释放资源。
注意事项
- 内存使用与性能：较大的缓冲区可以减少因频繁分配大缓冲区带来的性能开销，但也会增加内存占用。应根据实际应用场景和服务器资源合理设置。
- 临时缓冲区：当请求头超过
client_header_buffer_size定义的大小时，Nginx 会使用large_client_header_buffers配置的缓冲区。如果没有正确配置，可能会导致请求失败或不必要的资源消耗。 - 安全性：合理设置
client_header_buffer_size和large_client_header_buffers可以有效防止恶意用户通过发送过大的请求头攻击服务器。同时，确保超时时间配置合理，避免长时间占用服务器资源。
client_header_timeout
client_header_timeout 指令用于设置读取客户端请求头的超时时间。如果客户端在指定时间内没有发送完整的请求头，Nginx将返回一个408错误（请求超时）。默认超时时间为60秒。
Syntax: client_header_timeout time;
Default: client_header_timeout 60s;
Context: http, server
time：指定等待客户端请求头的超时时间。可以使用秒（例如10s）或毫秒（例如500ms）作为单位。
案例
基本用法
最简单的 client_header_timeout 用法是指定一个超时时间：
server {
listen 80;
server_name example.com;
# 设置读取客户端请求头的超时时间为30秒
client_header_timeout 30s;
}
在这个例子中：
- 将
client_header_timeout设置为30s，这意味着Nginx将在30秒内等待客户端发送完整的请求头。如果超过这个时间，Nginx将返回408错误。
使用毫秒单位
你可以根据需要使用毫秒作为超时时间单位：
server {
listen 80;
server_name example.com;
# 设置读取客户端请求头的超时时间为500毫秒
client_header_timeout 500ms;
}
在这个例子中：
- 将
client_header_timeout设置为500ms，这意味着Nginx将在500毫秒内等待客户端发送完整的请求头。如果超过这个时间，Nginx将返回408错误。
在多个上下文中设置不同的超时时间
你可以在不同的上下文中设置不同的超时时间，以满足不同的需求：
http {
# 全局设置读取客户端请求头的超时时间为20秒
client_header_timeout 20s;
server {
listen 80;
server_name example.com;
# 特定服务器块设置读取客户端请求头的超时时间为10秒
client_header_timeout 10s;
}
server {
listen 80;
server_name another-example.com;
# 另一个特定服务器块设置读取客户端请求头的超时时间为60秒
client_header_timeout 60s;
}
}
在这个例子中：
- 在全局
http块中设置了client_header_timeout 20s。 - 对于
example.com，将超时时间设置为10s。 - 对于
another-example.com，保持默认的60s超时时间。
注意事项
- 性能与安全性：较短的超时时间可以更快地释放资源并提高服务器的响应速度，但也可能导致合法但较慢的连接被中断。较长的超时时间则相反，可能会占用更多资源，特别是在高负载环境中。
- 调试和监控：如果你遇到频繁的408错误，可能需要调整此超时时间，并结合日志进行进一步分析。
- 结合其他指令：通常与
client_body_timeout、keepalive_timeout等指令结合使用，以确保整个请求处理流程的流畅性和高效性。 - 客户端行为：确保你的客户端能够适应设定的超时时间，避免因超时导致不必要的重试或失败。
client_max_body_size
client_max_body_size 指令用于设置客户端请求的最大主体（body）大小。这对于限制上传文件的大小或防止恶意用户发送过大的请求非常有用。
Syntax: client_max_body_size size;
Default: client_max_body_size 1m;
Context: http, server, location
size：指定最大请求主体大小，可以使用字节、KB（K）、MB（M）、GB（G）等单位。例如，1m表示1 MB。
案例
基本用法
最简单的client_max_body_size用法是指定允许的最大请求主体大小：
server {
listen 80;
server_name example.com;
location /upload {
client_max_body_size 10m; # 设置最大请求主体大小为10MB
}
}
在这个例子中，当用户向/upload路径上传文件时，Nginx将允许的最大文件大小为10 MB。如果上传的文件超过这个大小，Nginx将返回一个413（Request Entity Too Large）错误。
在特定的
location块中设置
根据需要为不同的location块设置不同的client_max_body_size配置：
server {
listen 80;
server_name example.com;
location /small-upload {
client_max_body_size 1m; # 设置最大请求主体大小为1MB
}
location /large-upload {
client_max_body_size 50m; # 设置最大请求主体大小为50MB
}
location /default {
client_max_body_size 2m; # 设置默认的最大请求主体大小为2MB
}
}
在这个例子中：
/small-upload路径下的请求允许的最大文件大小为1 MB。/large-upload路径下的请求允许的最大文件大小为50 MB。- 其他未明确指定的路径（如
/default）允许的最大文件大小为2 MB。
注意事项
-
内存和磁盘使用：设置较大的
client_max_body_size值可能会导致服务器消耗更多的内存和磁盘空间，特别是在处理大量并发大文件上传时。确保服务器有足够的资源来支持这种配置。 -
客户端体验：如果客户端尝试上传超过
client_max_body_size限制的文件，Nginx会返回413错误。为了提升用户体验，可以在应用层面对此情况进行提示，告知用户文件大小限制。 -
与代理结合使用：如果你使用Nginx作为反向代理服务器，确保后端服务器也配置了相应的最大请求主体大小限制，以避免不一致的问题。
-
日志记录：启用适当的日志记录可以帮助你监控和调试文件上传问题。你可以通过Nginx的日志配置记录413错误的发生情况。
connection_pool_size
connection_pool_size 指令在Nginx中用于设置连接池的大小，即每个工作进程为每个上游服务器保留的空闲保持连接（keep-alive connections）的最大数量。这有助于提高处理大量并发请求时的性能，通过减少频繁建立和关闭连接的开销。
Syntax: connection_pool_size size;
Default: connection_pool_size 256|512;
Context: http, server
size：指定每个工作进程为每个上游服务器保留的空闲保持连接的最大数量。默认值根据不同的Nginx版本可能是256或512。
案例
基本用法
最简单的 connection_pool_size 使用方法是指定一个适合您应用场景的大小值：
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_server;
connection_pool_size 512; # 设置每个工作进程为每个上游服务器保留的空闲保持连接的最大数量为512
}
}
在这个例子中，Nginx会为每个工作进程与上游服务器之间保持最多512个空闲连接。
根据负载调整连接池大小
根据您的应用负载情况，您可以调整 connection_pool_size 的值来优化性能：
http {
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location /high_load {
proxy_pass http://backend_servers;
connection_pool_size 1024; # 高负载场景下增加连接池大小
}
location /low_load {
proxy_pass http://backend_servers;
connection_pool_size 256; # 低负载场景下减少连接池大小
}
}
}
在这个例子中：
/high_load路径下，每个工作进程为每个上游服务器保留最多1024个空闲连接。/low_load路径下，每个工作进程为每个上游服务器保留最多256个空闲连接。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他配置项使用 connection_pool_size：
http {
upstream backend_servers {
server backend1.example.com max_fails=3 fail_timeout=30s;
server backend2.example.com max_fails=3 fail_timeout=30s;
}
server {
listen 80;
server_name example.com;
client_max_body_size 10m; # 设置客户端请求的最大主体大小为10MB
keepalive_timeout 60s; # 设置保持连接的超时时间为60秒
connection_pool_size 512; # 设置每个工作进程为每个上游服务器保留的空闲保持连接的最大数量为512
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
在这个例子中：
- 上游服务器
backend1.example.com和backend2.example.com配置了失败重试机制。 - 客户端请求的最大主体大小被限制为10MB。
- 保持连接的超时时间被设置为60秒。
- 每个工作进程为每个上游服务器保留最多512个空闲连接。
注意事项
- 资源分配：确保设置的
connection_pool_size不超过系统可用资源，避免因过高的连接数导致内存耗尽或其他资源瓶颈。 - 性能优化：根据实际负载情况调整连接池大小，过高或过低的值都可能影响性能。通常需要进行压力测试以找到最优配置。
- 监控与调整：定期监控服务器性能和资源使用情况，必要时调整
connection_pool_size及其他相关配置项，以维持最佳性能。
default_type
default_type 指令用于设置当 Nginx 无法根据文件扩展名或其他方式确定 MIME 类型时，默认使用的 MIME 类型。MIME 类型告诉客户端如何处理接收到的内容（例如，显示为文本、下载为文件等）。
Syntax: default_type mime-type;
Default: default_type text/plain;
Context: http, server, location
mime-type：指定默认的 MIME 类型。常见的 MIME 类型包括text/html,application/json,image/jpeg等。
案例
基本用法
最简单的 default_type 用法是指定一个默认的 MIME 类型：
server {
listen 80;
server_name example.com;
# 设置默认 MIME 类型为 text/html
default_type text/html;
location / {
root /var/www/html;
}
}
在这个例子中：
- 如果 Nginx 无法根据文件扩展名确定 MIME 类型，它将使用
text/html作为默认 MIME 类型来发送响应。
使用不同的默认 MIME 类型
如果你希望更改默认 MIME 类型以适应特定的应用场景，可以将其设置为其他值：
server {
listen 80;
server_name example.com;
# 设置默认 MIME 类型为 application/json
default_type application/json;
location /api {
root /var/www/api;
}
}
在这个例子中：
- 如果 Nginx 无法根据文件扩展名确定 MIME 类型，它将使用
application/json作为默认 MIME 类型来发送响应，这在 API 场景中特别有用。
在特定的
location块中设置不同的默认 MIME 类型
你可以根据需要为每个 location 块设置不同的 default_type 配置：
server {
listen 80;
server_name example.com;
location /static {
# 设置静态文件的默认 MIME 类型为 text/plain
default_type text/plain;
root /var/www/static;
}
location /images {
# 设置图片文件的默认 MIME 类型为 image/jpeg
default_type image/jpeg;
root /var/www/images;
}
location /api {
# 设置 API 的默认 MIME 类型为 application/json
default_type application/json;
root /var/www/api;
}
}
在这个例子中：
- 访问
/static时，如果 Nginx 无法确定 MIME 类型，将使用text/plain。 - 访问
/images时，如果 Nginx 无法确定 MIME 类型，将使用image/jpeg。 - 访问
/api时，如果 Nginx 无法确定 MIME 类型，将使用application/json。
注意事项
-
正确性：确保选择的默认 MIME 类型适合你的应用场景。错误的 MIME 类型可能导致客户端无法正确处理响应内容，甚至可能引发安全问题。
-
文件扩展名匹配优先：Nginx 首先尝试通过文件扩展名匹配 MIME 类型（基于
mime.types文件）。只有在无法匹配时才会使用default_type指定的类型。因此，通常不需要频繁修改default_type，除非有特殊情况。 -
性能考虑：虽然
default_type主要影响的是未明确指定 MIME 类型的响应，但合理设置该指令可以帮助提高整体应用的健壮性和兼容性。
directio
directio 指令在 Nginx 中用于控制何时使用直接 I/O（Direct I/O）方式处理文件。直接 I/O 允许应用程序绕过操作系统的缓存机制，直接与存储设备进行数据传输。这种方式可以减少内存占用，但可能会降低性能，尤其是在处理小文件时。
Syntax: directio size | off;
Default: directio off;
Context: http, server, location
This directive appeared in version 0.7.7.
size：当文件大小超过指定的值时，Nginx 将使用直接 I/O 方式读取或写入文件。例如，directio 4m表示当文件大小超过 4MB 时启用直接 I/O。off：禁用直接 I/O，所有文件操作都将通过操作系统缓存进行（默认行为）。
案例
基本用法
最简单的 directio 用法是指定一个适合你应用需求的阈值：
server {
listen 80;
server_name example.com;
location /large-files {
directio 4m; # 当文件大小超过4MB时启用直接I/O
root /var/www/large-files;
}
}
在这个例子中：
- 对于
/large-files路径下的文件，如果文件大小超过 4MB，Nginx 将使用直接 I/O 方式处理这些文件。较小的文件将继续使用操作系统的缓存机制。
禁用直接 I/O
如果你希望某些特定的服务器块或位置块不使用直接 I/O，可以将其设置为 off：
server {
listen 80;
server_name example.com;
location /small-files {
directio off; # 禁用直接I/O，所有文件操作都通过操作系统缓存进行
root /var/www/small-files;
}
}
在这个例子中：
- 对于
/small-files路径下的所有文件，无论文件大小如何，都不会使用直接 I/O，而是通过操作系统的缓存机制进行处理。
结合其他配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 directio：
server {
listen 80;
server_name example.com;
location /large-files {
directio 4m; # 当文件大小超过4MB时启用直接I/O
sendfile on; # 启用sendfile以提高大文件传输效率
aio on; # 启用异步I/O以进一步提高性能
root /var/www/large-files;
}
location /small-files {
directio off; # 禁用直接I/O
sendfile on; # 启用sendfile以提高小文件传输效率
root /var/www/small-files;
}
}
在这个例子中：
-
对于
/large-files路径下的文件：- 当文件大小超过 4MB 时，使用直接 I/O。
- 启用了
sendfile和aio来进一步提高大文件传输的效率。
-
对于
/small-files路径下的文件：- 禁用了直接 I/O，并启用了
sendfile以优化小文件的传输效率。
- 禁用了直接 I/O，并启用了
注意事项
- 性能影响：直接 I/O 绕过了操作系统的缓存机制，对于频繁访问的小文件，这可能会导致性能下降。因此，建议仅对大文件启用直接 I/O。
- 文件系统支持：并非所有文件系统都完全支持直接 I/O，使用前请确保你的文件系统兼容并测试其性能表现。
- 内存使用：直接 I/O 可以减少内存占用，特别是在处理大量大文件的情况下，但需要注意的是它也可能增加磁盘 I/O 的负担。
- 结合其他指令：如上所示，结合
sendfile和aio等其他指令可以进一步优化文件传输性能。特别是aio（异步 I/O），它可以显著提高大文件的处理速度。
directio_alignment
directio_alignment 指令用于设置直接I/O（Direct I/O）操作的对齐大小。直接I/O允许Nginx绕过操作系统缓存直接读写磁盘，适用于处理大文件时提高性能。此指令自Nginx版本0.8.11起可用。
Syntax: directio_alignment size;
Default: directio_alignment 512;
Context: http, server, location
size：指定直接I/O操作的对齐大小，默认值为512字节。通常情况下，这个值应与文件系统的块大小或设备的扇区大小对齐。
案例
基本用法
最简单的 directio_alignment 用法是指定一个对齐大小：
server {
listen 80;
server_name example.com;
location /large_files/ {
# 启用直接I/O并设置对齐大小为4KB
directio 4m;
directio_alignment 4k;
}
}
在这个例子中：
- 设置了
directio_alignment 4k，这意味着所有直接I/O操作将按4KB边界对齐。同时启用了directio 4m，表示对大于4MB的文件使用直接I/O。
使用默认对齐大小
你可以保持默认的对齐大小（512字节），适用于大多数场景：
server {
listen 80;
server_name example.com;
location /default_alignment/ {
# 启用直接I/O并使用默认对齐大小
directio 4m;
directio_alignment 512;
}
}
在这个例子中：
- 使用了默认的
directio_alignment 512，这意味着所有直接I/O操作将按512字节边界对齐。
在多个上下文中设置不同的对齐大小
你可以在不同的上下文中设置不同的对齐大小，以满足不同的需求：
http {
# 全局设置直接I/O对齐大小为1KB
directio_alignment 1k;
server {
listen 80;
server_name example.com;
# 特定服务器块设置直接I/O对齐大小为2KB
directio_alignment 2k;
location /files/ {
directio 4m;
}
}
server {
listen 80;
server_name another-example.com;
# 另一个特定服务器块保持默认对齐大小
directio_alignment 512;
location /files/ {
directio 4m;
}
}
}
在这个例子中：
- 在全局
http块中设置了directio_alignment 1k。 - 对于
example.com，将对齐大小设置为2k。 - 对于
another-example.com，保持默认的512字节对齐大小。
注意事项
- 文件系统和设备兼容性：确保所设置的对齐大小与文件系统的块大小或设备的扇区大小一致。不正确的对齐可能导致性能下降或数据损坏。
- 性能优化：对于处理大文件（如视频、音频等），适当的对齐大小可以显著提高直接I/O的性能。通常建议使用4KB或更大的对齐大小。
- 资源管理：直接I/O会绕过操作系统缓存，因此在高负载环境中，可能需要额外关注磁盘I/O性能和资源管理。
- 结合其他指令：通常与
directio指令结合使用，以确保大文件处理的最佳性能。例如，directio 4m表示对大于4MB的文件启用直接I/O。
disable_symlinks
disable_symlinks 指令用于控制Nginx是否允许处理符号链接（symlinks）。这对于增强文件系统的安全性非常有用，尤其是在多用户环境中或存在潜在恶意符号链接的情况下。
Syntax: disable_symlinks off;
disable_symlinks on | if_not_owner [from=part];
Default: disable_symlinks off;
Context: http, server, location
This directive appeared in version 1.1.15.
off：允许处理符号链接（默认行为）。on：完全禁止处理符号链接。if_not_owner：仅当符号链接的目标文件或目录的所有者与符号链接本身的所有者不同时，才禁止处理该符号链接。可选参数from=part指定要检查的部分路径。
案例
基本用法
最简单的disable_symlinks用法是指定是否允许处理符号链接：
server {
listen 80;
server_name example.com;
location /protected {
alias /var/www/protected_files/;
disable_symlinks on; # 完全禁止处理符号链接
}
}
在这个例子中，当用户访问/protected路径下的资源时，Nginx将完全禁止处理符号链接，确保无法通过符号链接访问其他不应被访问的文件或目录。
使用if_not_owner选项的例子如下：
server {
listen 80;
server_name example.com;
location /user-content {
alias /var/www/user_content/;
disable_symlinks if_not_owner from=/var/www/user_content; # 当符号链接目标所有者与链接所有者不同时禁止处理
}
}
在这个例子中，Nginx会检查符号链接的目标文件或目录的所有者。如果目标的所有者与符号链接的所有者不同，则禁止处理该符号链接。
在特定的
location块中设置
根据需要为不同的location块设置不同的disable_symlinks配置：
server {
listen 80;
server_name example.com;
location /public {
alias /var/www/public_files/;
disable_symlinks off; # 允许处理符号链接（默认行为）
}
location /secure {
alias /var/www/secure_files/;
disable_symlinks on; # 完全禁止处理符号链接
}
location /restricted {
alias /var/www/restricted_files/;
disable_symlinks if_not_owner from=/var/www/restricted_files; # 仅当目标所有者与链接所有者不同时禁止处理
}
}
在这个例子中：
/public路径下的请求允许处理符号链接（默认行为）。/secure路径下的请求完全禁止处理符号链接。/restricted路径下的请求仅在符号链接目标所有者与链接所有者不同时禁止处理。
注意事项
-
安全性：使用
disable_symlinks可以显著提高系统的安全性，特别是在共享主机或多用户环境中。然而，过度限制可能会导致合法的符号链接无法正常工作，因此需要仔细评估和测试。 -
性能影响：启用符号链接检查可能会带来一定的性能开销，特别是在处理大量符号链接时。确保对关键路径进行优化，并在必要时进行性能测试。
-
权限管理：确保文件和目录的权限设置正确，以避免不必要的符号链接问题。例如，确保只有授权用户能够创建和修改符号链接。
-
日志记录：启用适当的日志记录可以帮助你监控和调试符号链接相关的问题。你可以通过Nginx的日志配置记录相关的错误信息，以便快速定位和解决问题。
error_page
error_page 指令在Nginx中用于定义如何处理特定HTTP错误代码，并指定一个自定义的错误页面或重定向目标。通过该指令，您可以为不同的HTTP错误代码配置自定义的响应页面，从而提升用户体验和网站的专业性。
Syntax: error_page code ... [=[response]] uri;
Default: —
Context: http, server, location, if in location
code：一个或多个HTTP状态码，如404、500、502等。[[=response]]：可选参数，允许你更改返回给客户端的状态码。如果省略，则返回原始状态码。uri：指定要返回的错误页面或重定向的目标URI。
案例
基本用法
最简单的 error_page 使用方法是指定一个错误代码及其对应的错误页面：
server {
listen 80;
server_name example.com;
error_page 404 /404.html; # 当出现404错误时，返回/404.html页面
location / {
root /var/www/html;
index index.html;
}
location = /404.html {
root /var/www/html/errors; # 错误页面存储在特定目录下
}
}
在这个例子中，当请求的资源不存在时，Nginx会返回 /var/www/html/errors/404.html 页面。
更改返回的状态码
你可以使用 [[=response]] 参数来更改返回给客户端的状态码：
server {
listen 80;
server_name example.com;
error_page 404 =200 /custom_404.html; # 当出现404错误时，返回200状态码并显示/custom_404.html页面
location / {
root /var/www/html;
index index.html;
}
location = /custom_404.html {
root /var/www/html/errors; # 自定义错误页面存储在特定目录下
}
}
在这个例子中，当请求的资源不存在时，Nginx会返回 /var/www/html/errors/custom_404.html 页面，并且HTTP状态码将被更改为200。
处理多种错误代码
你可以为多个错误代码指定相同的错误页面或不同的错误页面：
server {
listen 80;
server_name example.com;
error_page 404 /404.html; # 404错误时返回/404.html页面
error_page 500 502 503 504 /50x.html; # 500、502、503、504错误时返回/50x.html页面
location / {
root /var/www/html;
index index.html;
}
location = /404.html {
root /var/www/html/errors;
}
location = /50x.html {
root /var/www/html/errors;
}
}
在这个例子中：
- 当出现404错误时，Nginx会返回
/var/www/html/errors/404.html页面。 - 当出现500、502、503或504错误时，Nginx会返回
/var/www/html/errors/50x.html页面。
内部重定向
你还可以使用 error_page 进行内部重定向，而不是直接返回静态页面：
server {
listen 80;
server_name example.com;
error_page 404 = @fallback; # 当出现404错误时，进行内部重定向到@fallback位置块
location / {
root /var/www/html;
index index.html;
}
location @fallback {
proxy_pass http://backup-server; # 将请求代理到备份服务器
}
}
在这个例子中，当请求的资源不存在时，Nginx会将请求内部重定向到名为 @fallback 的位置块，并将请求代理到 http://backup-server。
注意事项
- 自定义页面路径：确保指定的错误页面路径正确无误，并且Nginx有权限访问这些路径。
- 状态码管理：谨慎使用
[[=response]]参数更改返回的状态码，因为这可能会影响客户端对错误的理解和处理逻辑。 - 性能考虑：对于高并发场景，尽量减少复杂的错误处理逻辑以避免额外的性能开销。
- 测试与验证：在生产环境中应用之前，务必在开发或测试环境中充分测试所有错误页面和重定向规则，确保它们按预期工作。
etag
etag 指令用于控制 Nginx 是否在响应头中添加 ETag（实体标签）。ETag 是一种 HTTP 头信息，用于标识特定版本的资源。客户端可以通过发送带有 If-None-Match 头的请求来验证其缓存的资源是否仍然有效，从而减少不必要的数据传输。
Syntax: etag on | off;
Default: etag on;
Context: http, server, location
This directive appeared in version 1.3.3.
on | off：决定是否启用 ETag 响应头。on（默认值）：启用 ETag 响应头。Nginx 将在响应中包含 ETag 头。off：禁用 ETag 响应头。Nginx 将不会在响应中包含 ETag 头。
案例
基本用法
最简单的 etag 用法是指定是否启用该功能：
server {
listen 80;
server_name example.com;
# 启用 ETag 响应头
etag on;
location / {
root /var/www/html;
}
}
在这个例子中：
- 当用户访问
/时，Nginx 将在响应头中包含 ETag，允许客户端缓存并验证资源的有效性。
禁用 ETag 响应头
如果你希望禁用 ETag 响应头，可以将 etag 设置为 off：
server {
listen 80;
server_name example.com;
# 禁用 ETag 响应头
etag off;
location / {
root /var/www/html;
}
}
在这个例子中：
- 当用户访问
/时，Nginx 将不会在响应头中包含 ETag。
在特定的
location块中设置不同的 ETag 配置
你可以根据需要为每个 location 块设置不同的 etag 配置：
server {
listen 80;
server_name example.com;
location /static {
# 启用 ETag 响应头
etag on;
root /var/www/static;
}
location /dynamic {
# 禁用 ETag 响应头
etag off;
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/static时，Nginx 将在响应头中包含 ETag，允许客户端缓存静态资源。 - 访问
/dynamic时，Nginx 将不会在响应头中包含 ETag，因为动态内容通常不适合长时间缓存。
注意事项
-
缓存有效性：ETag 提供了一种高效的方式来验证缓存的有效性，减少了不必要的数据传输。但是，如果您的应用生成的内容变化频繁且不需要客户端缓存，禁用 ETag 可能是更好的选择。
-
性能考虑：虽然 ETag 有助于优化缓存，但在高并发场景下，处理大量的 If-None-Match 请求可能会增加服务器负担。因此，在某些情况下，可能需要权衡是否使用 ETag。
-
兼容性：确保客户端支持 ETag 和相应的缓存机制。大多数现代浏览器和 HTTP 客户端都支持 ETag，但一些旧版客户端可能不完全支持。
http
http 块是 Nginx 配置文件中的一个核心部分，用于定义 HTTP 服务器和相关设置。它包含了多个子指令和块（如 server 和 location），用于配置如何处理客户端请求、代理请求、负载均衡等。http 块只能在 main 上下文中使用，即它必须直接位于配置文件的顶层。
Syntax: http { ... }
Default: —
Context: main
{ ... }：包含一系列与 HTTP 服务相关的配置指令和子块。这些配置项可以包括全局设置、服务器块、位置块、上游服务器组等。
案例
基本用法
最简单的 http 块配置示例包括基本的服务器配置：
http {
include mime.types; # 包含 MIME 类型配置
default_type application/octet-stream; # 默认 MIME 类型
sendfile on; # 启用 sendfile 以优化文件传输
keepalive_timeout 65; # 设置长连接超时时间
server {
listen 80; # 监听端口 80
server_name example.com; # 服务器名称
location / {
root /var/www/html; # 网站根目录
index index.html index.htm; # 默认主页
}
error_page 404 /404.html; # 自定义 404 页面
error_page 500 502 503 504 /50x.html; # 自定义 50x 错误页面
}
}
在这个例子中：
include mime.types;：引入了 MIME 类型配置文件，用于识别不同类型的文件。default_type application/octet-stream;：设置了默认的 MIME 类型。sendfile on;：启用了sendfile来优化文件传输效率。keepalive_timeout 65;：设置了长连接的超时时间为 65 秒。server块定义了一个监听 80 端口的 HTTP 服务器，并指定了服务器名称和网站根目录。location /块定义了网站的根路径，并指定了默认主页。error_page指令定义了自定义的错误页面。
多个服务器配置
你可以在 http 块中定义多个 server 块来处理不同的域名或端口：
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name example.com;
location / {
root /var/www/example.com;
index index.html index.htm;
}
}
server {
listen 80;
server_name another-example.com;
location / {
root /var/www/another-example.com;
index index.html index.htm;
}
}
}
在这个例子中：
- 定义了两个
server块，分别处理example.com和another-example.com的请求。 - 每个
server块都有自己的root路径，指向不同的网站根目录。
结合其他配置项
为了进一步优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用：
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on; # 启用 TCP_NOPUSH 选项，优化大文件传输
keepalive_timeout 65;
client_max_body_size 10m; # 设置最大请求体大小为 10MB
upstream backend {
server backend1.example.com;
server backend2.example.com;
least_conn; # 使用最少连接策略进行负载均衡
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend; # 反向代理到后端服务器组
proxy_set_header Host $host; # 设置正确的主机头
}
location /static/ {
alias /var/www/static/; # 静态文件目录
}
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
}
}
在这个例子中：
tcp_nopush on;：启用了TCP_NOPUSH选项，优化大文件传输。client_max_body_size 10m;：设置了允许的最大请求体大小为 10MB。upstream backend块定义了一个后端服务器组，并使用最少连接策略进行负载均衡。proxy_pass http://backend;：将请求反向代理到后端服务器组，并通过proxy_set_header设置正确的主机头。location /static/块定义了静态文件目录，避免不必要的代理转发。
注意事项
- 配置层次结构：
http块是顶级配置块，包含所有与 HTTP 服务相关的配置。在其内部可以定义多个server块和其他配置项。 - 性能优化：结合使用
sendfile,tcp_nopush,keepalive_timeout等指令可以显著提高服务器性能。 - 安全性：合理设置
client_max_body_size等参数可以防止恶意用户通过发送过大的请求攻击服务器。 - 负载均衡：通过
upstream块可以实现灵活的负载均衡策略，如轮询、最少连接、IP 哈希等，确保高可用性和稳定性。 - 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。
if_modified_since
if_modified_since 指令用于控制Nginx如何处理 If-Modified-Since 请求头。此指令可以帮助优化缓存行为，并减少不必要的数据传输。默认情况下，Nginx使用 exact 模式来处理 If-Modified-Since 请求头。此指令自Nginx版本0.7.24起可用。
Syntax: if_modified_since off | exact | before;
Default: if_modified_since exact;
Context: http, server, location
off：禁用If-Modified-Since头的处理。exact：仅当客户端请求中的If-Modified-Since时间与文件的修改时间完全匹配时，返回304 Not Modified 响应。before：如果客户端请求中的If-Modified-Since时间早于或等于文件的修改时间，则返回304 Not Modified 响应。
案例
基本用法
最简单的 if_modified_since 用法是指定一个处理模式：
server {
listen 80;
server_name example.com;
location /static/ {
# 使用精确匹配模式
if_modified_since exact;
# 设置静态文件根目录
root /var/www/static;
}
}
在这个例子中：
- 启用了
if_modified_since exact，这意味着只有当客户端请求中的If-Modified-Since时间与文件的修改时间完全匹配时，才会返回304 Not Modified 响应。
禁用
If-Modified-Since头处理
你可以根据需要禁用 If-Modified-Since 头的处理：
server {
listen 80;
server_name example.com;
location /static/ {
# 禁用 If-Modified-Since 头处理
if_modified_since off;
# 设置静态文件根目录
root /var/www/static;
}
}
在这个例子中：
- 启用了
if_modified_since off，这意味着Nginx将忽略客户端请求中的If-Modified-Since头。
使用
before模式
你可以根据需要使用 before 模式来处理 If-Modified-Since 请求头：
server {
listen 80;
server_name example.com;
location /static/ {
# 使用 before 模式
if_modified_since before;
# 设置静态文件根目录
root /var/www/static;
}
}
在这个例子中：
- 启用了
if_modified_since before，这意味着如果客户端请求中的If-Modified-Since时间早于或等于文件的修改时间，则返回304 Not Modified 响应。
注意事项
- 缓存行为：正确配置
if_modified_since可以显著减少不必要的数据传输，特别是在高流量网站上。这有助于提高性能并降低带宽成本。 - 精确匹配 vs. Before 匹配：选择
exact或before模式取决于你的应用需求。exact模式更为严格，而before模式则更加灵活，适用于希望减少缓存失效的情况。 - 调试和监控：如果你遇到缓存相关的问题，可以考虑调整此设置并结合日志进行进一步分析。
- 结合其他缓存相关指令：通常与
expires、etag等缓存相关的指令一起使用，以实现更高效的缓存策略。
ignore_invalid_headers
ignore_invalid_headers 指令用于控制Nginx是否忽略无效的请求头（headers）。这对于提高系统的健壮性和安全性非常有用，尤其是在处理来自不可信客户端的请求时。
Syntax: ignore_invalid_headers on | off;
Default: ignore_invalid_headers on;
Context: http, server
on：忽略无效的请求头（默认行为）。off：不忽略无效的请求头，Nginx会返回400（Bad Request）错误给客户端。
案例
基本用法
最简单的ignore_invalid_headers用法是指定是否忽略无效的请求头：
server {
listen 80;
server_name example.com;
ignore_invalid_headers on; # 忽略无效的请求头（默认行为）
}
在这个例子中，当客户端发送包含无效请求头的请求时，Nginx将忽略这些无效的请求头并继续处理请求。
禁用忽略无效请求头
禁用忽略无效请求头的例子如下：
server {
listen 80;
server_name example.com;
ignore_invalid_headers off; # 不忽略无效的请求头，返回400错误
}
在这个例子中，如果客户端发送包含无效请求头的请求，Nginx将返回400（Bad Request）错误给客户端，而不是忽略这些无效请求头。
不同
server设置
根据需要为不同的server块设置不同的ignore_invalid_headers配置：
http {
include mime.types;
default_type application/octet-stream;
# 全局设置，忽略无效请求头
ignore_invalid_headers on;
server {
listen 80;
server_name public.example.com;
ignore_invalid_headers on; # 继承全局设置，忽略无效请求头
}
server {
listen 80;
server_name secure.example.com;
ignore_invalid_headers off; # 禁用忽略无效请求头，返回400错误
}
}
在这个例子中：
public.example.com服务器块继承了全局设置，忽略无效请求头。secure.example.com服务器块禁用了忽略无效请求头，任何无效请求头都会导致返回400错误。
注意事项
-
安全性：忽略无效请求头可以提高系统的健壮性，但有时也可能隐藏潜在的安全问题。如果你的应用程序对请求头有严格的格式要求，或者你希望严格验证所有输入，那么禁用忽略无效请求头可能更合适。
-
日志记录：启用适当的日志记录可以帮助你监控和调试无效请求头相关的问题。你可以通过Nginx的日志配置记录400错误的发生情况，以便快速定位和解决问题。
-
性能影响：虽然忽略无效请求头通常不会显著影响性能，但在高并发环境下，禁用忽略无效请求头可能会增加处理开销，因为每个请求都需要进行额外的验证。
-
与代理结合使用：如果你使用Nginx作为反向代理服务器，确保后端服务器也能够正确处理无效请求头。否则，即使Nginx忽略了无效请求头，后端服务器仍可能出现问题。
internal
internal 指令在Nginx中用于标记一个location块为内部使用，这意味着该location只能由Nginx内部的重定向或子请求访问，而不能直接从客户端请求访问。这有助于保护敏感资源和逻辑，防止未经授权的外部访问。
Syntax: internal;
Default: —
Context: location
- 无参数：此指令不需要任何参数，只需在其所在的location块中声明即可。
案例
基本用法
最简单的 internal 使用方法是将其添加到一个location块中，以确保该location只能通过内部请求访问：
server {
listen 80;
server_name example.com;
location /protected {
internal; # 标记此location为内部使用，不允许直接访问
root /var/www/html/protected;
}
location /download {
alias /var/www/html/downloads; # 设置下载路径
if ($request_method = GET) {
rewrite ^ /protected/$1 break; # 内部重定向到/protected位置
}
}
}
在这个例子中：
/protected路径下的资源只能通过内部重定向访问，直接访问会返回404错误。/download路径下的GET请求会被内部重定向到/protected路径。
结合error_page使用
您可以结合 error_page 和 internal 来处理特定的错误情况，并将用户重定向到一个内部的错误页面：
server {
listen 80;
server_name example.com;
error_page 404 /custom_404.html; # 自定义404错误页面
location /custom_404.html {
internal; # 确保此页面只能通过内部重定向访问
root /var/www/html/errors;
}
location / {
try_files $uri $uri/ @not_found; # 尝试查找文件或目录，否则重定向到@not_found
}
location @not_found {
return 404; # 返回404状态码，触发error_page
}
}
在这个例子中：
- 当找不到请求的资源时，Nginx会返回404状态码并触发
error_page指令。 error_page指令会将请求重定向到/custom_404.html页面，该页面被标记为内部使用，确保它不会被直接访问。
处理代理请求
您还可以使用 internal 来保护代理请求的目标资源：
server {
listen 80;
server_name example.com;
location /backend {
internal; # 标记此location为内部使用
proxy_pass http://backend-server;
}
location /api {
if ($request_method = POST) {
rewrite ^ /backend$uri break; # 内部重定向到/backend位置
}
proxy_pass http://frontend-server; # 默认情况下代理到前端服务器
}
}
在这个例子中：
/backend路径下的资源只能通过内部重定向访问，不能直接从客户端请求访问。/api路径下的POST请求会被内部重定向到/backend路径，并代理到http://backend-server。
处理子请求
internal 指令通常与子请求一起使用，以保护某些需要内部处理的资源或逻辑：
server {
listen 80;
server_name example.com;
location /generate_report {
internal; # 标记此location为内部使用
content_by_lua_block {
ngx.say("This is a generated report.")
}
}
location /reports {
content_by_lua_block {
local res = ngx.location.capture("/generate_report") -- 发起子请求生成报告
ngx.say(res.body)
}
}
}
在这个例子中：
/generate_report路径下的资源只能通过内部子请求访问。/reports路径下的请求会发起一个子请求到/generate_report，获取生成的报告内容并返回给客户端。
注意事项
- 安全性：使用
internal可以有效保护敏感资源，防止未经授权的外部访问。确保所有需要保护的location都正确标记为内部使用。 - 调试与测试：由于内部location无法直接访问，调试时可能需要通过日志或子请求的方式来验证其行为是否符合预期。
- 性能考虑：虽然
internal提供了额外的安全层，但过多的内部重定向或子请求可能会增加处理时间。请根据实际情况合理使用。
keepalive_disable
keepalive_disable 指令用于禁用特定浏览器或客户端的 HTTP 长连接（Keep-Alive）功能。HTTP 长连接允许客户端和服务器在同一个连接上发送多个请求和响应，从而减少建立新连接的开销。然而，某些旧版本的浏览器可能对长连接支持不佳，因此可以通过该指令禁用这些浏览器的长连接功能。
Syntax: keepalive_disable none | browser ...;
Default: keepalive_disable msie6;
Context: http, server, location
none | browser ...：指定要禁用长连接的浏览器或客户端名称。可以使用多个浏览器名称，以空格分隔。如果设置为none，则不针对任何特定浏览器禁用长连接。
案例
基本用法
最简单的 keepalive_disable 用法是指定禁用长连接的浏览器：
server {
listen 80;
server_name example.com;
# 禁用 MSIE6 的长连接
keepalive_disable msie6;
location / {
root /var/www/html;
}
}
在这个例子中：
- 当 MSIE6 浏览器访问
/时，Nginx 将不会使用长连接。 - 其他浏览器仍然可以使用长连接。
在特定的
location块中设置不同的keepalive_disable配置
你可以根据需要为每个 location 块设置不同的 keepalive_disable 配置：
server {
listen 80;
server_name example.com;
location /static {
# 禁用 MSIE6 和 Safari 5 的长连接
keepalive_disable msie6 safari5;
root /var/www/static;
}
location /dynamic {
# 不禁用任何浏览器的长连接
keepalive_disable none;
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/static时，MSIE6 和 Safari 5 浏览器将不会使用长连接，其他浏览器仍然可以使用长连接。 - 访问
/dynamic时，所有浏览器都可以使用长连接。
注意事项
-
兼容性：现代浏览器通常都很好地支持 HTTP 长连接，但对于一些老旧浏览器（如 MSIE6），禁用长连接可以避免潜在的问题。确保你了解目标用户群体使用的浏览器类型，并据此调整配置。
-
性能考虑：长连接可以显著提高性能，特别是在高并发场景下。禁用长连接可能会增加连接建立的开销，导致性能下降。因此，建议仅在必要时禁用特定浏览器的长连接。
-
调试与测试：在实际生产环境中应用前，建议先在测试环境中验证配置效果，确保不会影响用户体验。
keepalive_min_timeout
keepalive_min_timeout 指令在 Nginx 中用于设置客户端连接的最小保持活动（Keep-Alive）超时时间。这个指令确保了即使客户端设置了较短的 Keep-Alive 超时时间，Nginx 也会至少保持连接打开指定的时间。这对于需要长时间保持连接的应用场景非常重要。
Syntax: keepalive_min_timeout timeout;
Default: keepalive_min_timeout 0;
Context: http, server, location
This directive appeared in version 1.27.4.
timeout：指定最小的 Keep-Alive 超时时间，单位为秒。默认值是0，表示没有最小超时限制，即完全依赖于客户端设置的超时时间。
案例
基本用法
最简单的 keepalive_min_timeout 用法是指定一个适合你应用需求的最小超时时间：
server {
listen 80;
server_name example.com;
keepalive_min_timeout 30s; # 设置最小 Keep-Alive 超时时间为30秒
location / {
proxy_pass http://backend;
}
}
在这个例子中：
- 客户端连接的最小 Keep-Alive 超时时间被设置为 30 秒。这意味着即使客户端设置了更短的超时时间，Nginx 也会保持连接至少 30 秒。
根据上下文调整最小超时时间
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 keepalive_min_timeout 的值：
http {
keepalive_min_timeout 60s; # 全局设置为60秒
server {
listen 80;
server_name example.com;
location /short-timeout {
keepalive_min_timeout 15s; # 特定位置设置为15秒
proxy_pass http://backend;
}
location /long-timeout {
keepalive_min_timeout 120s; # 特定位置设置为120秒
proxy_pass http://backend;
}
}
}
在这个例子中：
- 全局配置下，默认最小 Keep-Alive 超时时间被设置为 60 秒。
- 对于
/short-timeout位置块中的请求，最小 Keep-Alive 超时时间被设置为 15 秒。 - 对于
/long-timeout位置块中的请求，最小 Keep-Alive 超时时间被设置为 120 秒。
结合其他配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 keepalive_min_timeout：
server {
listen 80;
server_name example.com;
keepalive_min_timeout 30s; # 设置最小 Keep-Alive 超时时间为30秒
keepalive_timeout 60s; # 设置总的 Keep-Alive 超时时间为60秒
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
client_header_timeout 60s; # 设置读取请求头超时时间为60秒
location / {
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
}
}
在这个例子中：
- 设置了最小 Keep-Alive 超时时间为 30 秒，确保即使客户端设置了更短的超时时间，Nginx 也会保持连接至少 30 秒。
- 设置了总的 Keep-Alive 超时时间为 60 秒，控制整个连接的最长保持时间。
- 设置了读取请求体和请求头的超时时间，确保长时间没有活动的连接能及时关闭，释放资源。
注意事项
- 连接管理：合理设置
keepalive_min_timeout和keepalive_timeout可以有效管理长连接，避免过多的空闲连接占用服务器资源。 - 兼容性：确保客户端支持并正确处理你所设置的 Keep-Alive 超时时间。某些旧客户端可能不支持或无法正确处理较长的超时时间。
- 性能与资源平衡：虽然较长的 Keep-Alive 超时时间可以减少重复建立连接的开销，但也可能导致更多的空闲连接占用服务器资源。应根据实际应用场景和服务器负载情况进行调整。
- 安全性：确保合理的超时设置，防止恶意用户通过长时间保持连接的方式消耗服务器资源。
keepalive_requests
keepalive_requests 指令用于设置一个保持连接（keep-alive connection）可以服务的最大请求数。默认情况下，Nginx允许每个保持连接处理最多1000个请求。此指令自Nginx版本0.8.0起可用。
Syntax: keepalive_requests number;
Default: keepalive_requests 1000;
Context: http, server, location
number：指定一个保持连接可以处理的最大请求数，默认值为1000。
案例
基本用法
最简单的 keepalive_requests 用法是指定一个最大请求数：
server {
listen 80;
server_name example.com;
location /api/ {
# 设置每个保持连接可以处理的最大请求数为500
keepalive_requests 5/XMLSchemaDoc
}
}
在这个例子中：
- 设置了
keepalive_requests 500，这意味着每个保持连接在/api/路径下最多可以处理500个请求。
结合其他指令
你可以结合其他指令：
server {
listen 80;
server_name example.com;
location /api/ {
# 设置每个保持连接可以处理的最大请求数为500
keepalive_requests 500;
# 设置保持连接的超时时间为60秒
keepalive_timeout 60s;
# 设置静态文件根目录
root /var/www/api;
}
}
-
在这个例子中：
-
结合了
keepalive_requests 500和keepalive_timeout 60s，确保每个保持连接在60秒内可以处理最多500个请求。 -
调试和监控：如果你遇到连接问题或资源耗尽的情况，可以考虑调整
keepalive_requests的值，并结合日志进行进一步分析。
-
注意事项
- 资源管理：较高的
keepalive_requests值可以减少客户端与服务器之间建立新连接的开销，但也会占用更多的服务器资源。根据实际负载情况调整该值。 - 性能优化：对于高并发场景，适当增加
keepalive_requests的值可以提高性能，因为减少了频繁建立和关闭连接的开销。 - 结合其他指令：通常与
keepalive_timeout等指令结合使用，以确保保持连接的有效性和高效性。
keepalive_time
keepalive_time 指令用于设置客户端连接在空闲状态下保持打开的最大时间。这有助于优化长连接的使用，减少频繁建立和关闭连接带来的开销，从而提高服务器性能和响应速度。
Syntax: keepalive_time time;
Default: keepalive_time 1h;
Context: http, server, location
This directive appeared in version 1.19.10.
time：指定客户端连接在空闲状态下保持打开的最大时间。可以使用秒（s）、分钟（m）、小时（h）等单位。例如，1h表示1小时。
案例
基本用法
最简单的keepalive_time用法是指定客户端连接在空闲状态下保持打开的最大时间：
server {
listen 80;
server_name example.com;
keepalive_time 30m; # 设置客户端连接在空闲状态下保持打开的最大时间为30分钟
}
在这个例子中，当客户端与Nginx建立连接后，如果该连接在30分钟内没有活动，Nginx将关闭该连接。这有助于释放服务器资源，并防止过多的空闲连接占用系统资源。
不同
server配置
根据需要为不同的server或location块设置不同的keepalive_time配置：
http {
include mime.types;
default_type application/octet-stream;
# 全局设置，保持连接时间为1小时
keepalive_time 1h;
server {
listen 80;
server_name public.example.com;
location /api/ {
keepalive_time 15m; # 对于/api/路径下的请求，保持连接时间为15分钟
}
location /static/ {
keepalive_time 1h; # 继承全局设置，保持连接时间为1小时
}
}
server {
listen 80;
server_name secure.example.com;
keepalive_time 2h; # 对于secure.example.com，保持连接时间为2小时
}
}
在这个例子中：
public.example.com服务器块中的/api/路径设置为保持连接时间为15分钟。public.example.com服务器块中的/static/路径继承了全局设置，保持连接时间为1小时。secure.example.com服务器块设置为保持连接时间为2小时。
注意事项
-
资源管理：虽然长连接可以减少连接建立和关闭的开销，但过多的长时间空闲连接会占用服务器资源。合理设置
keepalive_time值，确保不会因为过多的空闲连接导致资源耗尽。 -
性能优化：对于频繁交互的应用（如WebSocket、AJAX轮询等），适当增加
keepalive_time可以显著提升性能。但对于较少交互的应用，过长的保持时间可能浪费资源。 -
与代理结合使用：如果你使用Nginx作为反向代理服务器，确保后端服务器也支持并正确配置了长连接相关的参数（如
proxy_http_version 1.1;和proxy_set_header Connection "";），以充分利用长连接的优势。 -
日志记录：启用适当的日志记录可以帮助你监控连接的使用情况。你可以通过Nginx的日志配置记录连接超时或其他相关事件，以便快速定位和解决问题。
keepalive_timeout
keepalive_timeout 指令在Nginx中用于设置HTTP keep-alive连接的超时时间。Keep-alive连接允许客户端和服务器之间维持一个持久连接，从而减少每次请求都需要重新建立连接的开销，提高性能。通过调整 keepalive_timeout，您可以优化服务器的性能和资源使用。
Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;
Context: http, server, location
timeout：指定服务器在关闭连接之前等待下一个请求的最大时间（以秒为单位）。header_timeout（可选）：指定发送给客户端的响应头中的Keep-Alive超时值。如果未指定，则默认与timeout相同。
案例
基本用法
最简单的 keepalive_timeout 使用方法是指定一个适合您应用场景的超时时间：
server {
listen 80;
server_name example.com;
keepalive_timeout 60s; # 设置保持连接的超时时间为60秒
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在60秒内保持连接打开状态，等待客户端发起新的请求。如果在这段时间内没有新的请求，连接将被关闭。
设置响应头中的 Keep-Alive 超时值
您可以同时指定 timeout 和 header_timeout，以控制发送给客户端的响应头中的 Keep-Alive 超时值：
server {
listen 80;
server_name example.com;
keepalive_timeout 60s 30s; # 设置服务器端的超时时间为60秒，响应头中的超时时间为30秒
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中：
- 服务器将在60秒内保持连接打开状态。
- 发送给客户端的响应头中的
Keep-Alive超时值为30秒。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 keepalive_timeout：
http {
keepalive_requests 100; # 每个keep-alive连接最多处理100个请求
keepalive_timeout 60s 30s; # 设置服务器端的超时时间为60秒，响应头中的超时时间为30秒
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /downloads {
keepalive_timeout 120s; # 下载路径的保持连接超时时间为120秒
alias /var/www/downloads;
}
}
}
在这个例子中：
- 全局配置中设置了每个keep-alive连接最多处理100个请求。
- 全局
keepalive_timeout设置为60秒，响应头中的超时值为30秒。 - 对于
/downloads路径，保持连接的超时时间被延长至120秒，以适应大文件下载的需求。
注意事项
- 性能优化：合理设置
keepalive_timeout可以显著提升高并发场景下的性能表现。过短的超时时间可能导致频繁的连接重建，而过长的超时时间可能占用过多的服务器资源。 - 资源管理：确保设置的
keepalive_timeout不会导致服务器资源耗尽。特别是在高并发环境下，需要仔细权衡超时时间和资源使用情况。 - 浏览器兼容性：某些浏览器或客户端对
Keep-Alive头的支持可能存在差异，请确保您的设置在目标环境中能够正常工作。 - 监控与调整：定期监控服务器的连接状态和性能指标，必要时调整
keepalive_timeout及其他相关配置项，以维持最佳性能。
large_client_header_buffers
large_client_header_buffers 指令用于设置处理大客户端请求头所需的缓冲区数量和每个缓冲区的大小。当客户端发送较大的请求头（如包含大量 cookie 或长 URL 的请求）时，Nginx 需要足够的缓冲区来存储这些请求头数据。
Syntax: large_client_header_buffers number size;
Default: large_client_header_buffers 4 8k;
Context: http, server
number：指定用于存储大客户端请求头的缓冲区数量。size：指定每个缓冲区的大小。
案例
基本用法
最简单的 large_client_header_buffers 用法是指定缓冲区的数量和大小：
server {
listen 80;
server_name example.com;
# 设置 4 个 8KB 的缓冲区来处理大客户端请求头
large_client_header_buffers 4 8k;
location / {
root /var/www/html;
}
}
在这个例子中：
- Nginx 将使用 4 个 8KB 的缓冲区来存储大客户端请求头。如果请求头超过 32KB（4 * 8KB），Nginx 将返回 414 (Request-URI Too Large) 或 400 (Bad Request) 错误。
增加缓冲区数量和大小
如果你的应用场景需要处理更大的请求头，可以增加缓冲区的数量或大小：
server {
listen 80;
server_name example.com;
# 设置 8 个 16KB 的缓冲区来处理大客户端请求头
large_client_header_buffers 8 16k;
location / {
root /var/www/html;
}
}
在这个例子中：
- Nginx 将使用 8 个 16KB 的缓冲区来存储大客户端请求头。这样总共可以处理高达 128KB 的请求头数据。
在特定的
server块中设置不同的缓冲区配置
你可以根据需要为不同的 server 块设置不同的 large_client_header_buffers 配置：
http {
# 默认配置
large_client_header_buffers 4 8k;
server {
listen 80;
server_name example1.com;
# 使用默认配置
location / {
root /var/www/example1;
}
}
server {
listen 80;
server_name example2.com;
# 设置 6 个 12KB 的缓冲区来处理大客户端请求头
large_client_header_buffers 6 12k;
location / {
root /var/www/example2;
}
}
}
在这个例子中：
- 对于
example1.com，Nginx 将使用默认的 4 个 8KB 的缓冲区。 - 对于
example2.com，Nginx 将使用 6 个 12KB 的缓冲区，总共可以处理高达 72KB 的请求头数据。
注意事项
-
性能与资源消耗：虽然增加缓冲区的数量和大小可以处理更大的请求头，但也会占用更多的服务器内存。确保根据实际需求合理配置缓冲区，避免不必要的内存开销。
-
错误处理：如果请求头超过了配置的最大值，Nginx 将返回 414 (Request-URI Too Large) 或 400 (Bad Request) 错误。确保监控日志并调整配置以适应实际流量需求。
-
安全性考虑：过大的请求头可能会被恶意利用进行拒绝服务攻击（DoS）。适当限制缓冲区大小有助于减轻这种风险。
limit_except
limit_except 指令在 Nginx 中用于限制指定位置块中允许的 HTTP 方法。通过使用 limit_except，你可以明确指定哪些 HTTP 方法是允许的，并为这些方法定义额外的访问控制规则（如认证、授权等）。这对于增强安全性非常有用，特别是当你希望仅允许特定类型的请求时。
Syntax: limit_except method ... { ... }
Default: —
Context: location
method：指定允许的 HTTP 方法。常见的 HTTP 方法包括GET,POST,PUT,DELETE,HEAD等。{ ... }：包含附加的指令，通常用于设置访问控制规则（如认证）。
案例
基本用法
最简单的 limit_except 用法是指定一个或多个允许的 HTTP 方法：
server {
listen 80;
server_name example.com;
location /api/ {
limit_except GET POST { # 仅允许 GET 和 POST 请求
allow 192.168.1.0/24; # 允许来自 192.168.1.0/24 子网的请求
deny all; # 拒绝所有其他来源的请求
}
proxy_pass http://backend;
}
}
在这个例子中：
/api/路径下的资源仅允许GET和POST请求。- 来自
192.168.1.0/24子网的客户端可以访问这些资源，而其他来源的请求将被拒绝。
允许多种方法并设置认证
你可以在 limit_except 块中添加认证或其他访问控制规则：
server {
listen 80;
server_name example.com;
location /admin/ {
limit_except GET POST PUT DELETE { # 仅允许 GET, POST, PUT 和 DELETE 请求
auth_basic "Restricted Area"; # 启用基本认证
auth_basic_user_file /etc/nginx/.htpasswd; # 指定用户文件
}
root /var/www/admin;
}
}
在这个例子中：
/admin/路径下的资源仅允许GET,POST,PUT和DELETE请求。- 对于这些允许的方法，启用了基本认证机制，并指定了用户文件路径
/etc/nginx/.htpasswd。
结合其他配置项
为了进一步优化和增强安全性，可以结合其他相关配置项一起使用 limit_except：
server {
listen 80;
server_name example.com;
location /secure/ {
limit_except GET POST { # 仅允许 GET 和 POST 请求
allow 192.168.1.0/24; # 允许来自 192.168.1.0/24 子网的请求
deny all; # 拒绝所有其他来源的请求
auth_basic "Restricted Area"; # 启用基本认证
auth_basic_user_file /etc/nginx/.htpasswd; # 指定用户文件
}
client_max_body_size 10m; # 设置最大请求体大小为 10MB
proxy_pass http://backend;
proxy_set_header Host $host; # 设置正确的主机头
}
location /public/ {
limit_except GET HEAD { # 仅允许 GET 和 HEAD 请求
allow 192.168.1.0/24; # 允许来自 192.168.1.0/24 子网的请求
deny all; # 拒绝所有其他来源的请求
}
root /var/www/public;
}
}
在这个例子中：
-
/secure/路径下的资源仅允许GET和POST请求：- 允许来自
192.168.1.0/24子网的客户端访问，并设置了基本认证。 - 设置了最大请求体大小为 10MB，并通过反向代理转发请求到后端服务器。
- 允许来自
-
/public/路径下的资源仅允许GET和HEAD请求：- 允许来自
192.168.1.0/24子网的客户端访问，其他来源的请求将被拒绝。
- 允许来自
注意事项
- 安全性：通过限制允许的 HTTP 方法，可以有效防止某些类型的攻击（如 CSRF 攻击）。确保只启用实际需要的方法，并对敏感操作（如修改数据）进行严格的访问控制。
- 兼容性：确保客户端支持并正确处理你所限制的 HTTP 方法。某些旧客户端可能不支持较新的 HTTP 方法（如
PATCH或OPTIONS）。 - 性能与资源平衡：虽然限制 HTTP 方法可以提高安全性，但也可能导致某些合法请求被拒绝。应根据实际应用场景和需求进行调整。
- 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。
limit_rate
limit_rate 指令用于设置每个连接的数据传输速率上限（以字节每秒为单位）。通过限制传输速率，可以避免某些客户端占用过多带宽，从而确保服务器资源的公平分配。默认情况下，该值为0，表示不限制传输速率。此指令可以在 http、server、location 和 if in location 上下文中使用。
Syntax: limit_rate rate;
Default: limit_rate 0;
Context: http, server, location, if in location
rate：指定数据传输速率上限，单位为字节每秒。例如，1024表示每秒传输1KB，1024k表示每秒传输1MB。
案例
基本用法
最简单的 limit_rate 用法是指定一个传输速率上限：
server {
listen 80;
server_name example.com;
location /downloads/ {
# 设置每个连接的最大传输速率为500KB/s
limit_rate 500k;
}
}
在这个例子中：
- 设置了
limit_rate 500k，这意味着每个连接在/downloads/路径下的最大传输速率为500KB/s。
使用默认值（不限制）
你可以保持默认设置，不限制传输速率：
server {
listen 80;
server_name example.com;
location /static/ {
# 使用默认值，不限制传输速率
limit_rate 0;
# 设置静态文件根目录
root /var/www/static;
}
}
在这个例子中：
- 使用默认值
limit_rate 0，这意味着不限制传输速率。
动态调整速率
你可以在运行时根据条件动态调整传输速率：
server {
listen 80;
server_name example.com;
location /downloads/ {
set $limit_rate_value "1m";
if ($http_user_agent ~* "Mobile") {
# 如果是移动设备，将传输速率限制为500KB/s
set $limit_rate_value "500k";
}
# 根据条件设置传输速率
limit_rate $limit_rate_value;
}
}
在这个例子中：
- 根据用户代理（User-Agent）判断是否为移动设备，并相应地设置不同的传输速率。对于移动设备，传输速率限制为500KB/s；对于其他设备，传输速率为1MB/s。
在多个上下文中设置不同的速率限制
你可以在不同的上下文中设置不同的速率限制，以满足不同的需求：
http {
# 全局设置每个连接的最大传输速率为2MB/s
limit_rate 2m;
server {
listen 80;
server_name example.com;
# 特定服务器块设置每个连接的最大传输速率为1MB/s
limit_rate 1m;
location /api/ {
# 设置静态文件根目录
root /var/www/api;
}
}
server {
listen 80;
server_name another-example.com;
# 另一个特定服务器块使用全局设置
location /files/ {
# 设置静态文件根目录
root /var/www/files;
}
}
}
在这个例子中：
- 在全局
http块中设置了limit_rate 2m。 - 对于
example.com，将最大传输速率设置为1m。 - 对于
another-example.com，使用全局设置的2m。
注意事项
- 带宽管理：合理设置
limit_rate可以有效管理服务器带宽，防止个别客户端占用过多资源，影响其他用户的体验。 - 用户体验：过低的传输速率可能会影响用户体验，特别是在需要快速加载大文件或视频流的情况下。因此，应根据实际需求和网络条件进行调整。
- 结合其他指令：通常与
limit_rate_after指令结合使用，以实现更灵活的速率控制策略。
limit_rate_after
limit_rate_after 指令用于指定在传输多少数据之后开始限制传输速率。这对于控制客户端下载速度、防止带宽滥用以及确保公平的资源分配非常有用。
Syntax: limit_rate_after size;
Default: limit_rate_after 0;
Context: http, server, location, if in location
This directive appeared in version 0.8.0.
size：指定在开始限制传输速率之前允许传输的数据量。可以使用字节（B）、KB（K）、MB（M）、GB（G）等单位。例如，1m表示1 MB。
案例
基本用法
最简单的limit_rate_after用法是指定在传输多少数据之后开始限制传输速率：
server {
listen 80;
server_name example.com;
location /downloads/ {
limit_rate_after 1m; # 在传输了1MB数据之后开始限制传输速率
limit_rate 50k; # 限制传输速率为50KB/s
}
}
在这个例子中，当用户从/downloads/路径下载文件时，前1 MB的数据会以最大可能的速度传输，之后的传输速率将被限制为50 KB/s。
以下是一个结合if条件语句的示例，展示了如何根据用户IP地址动态设置limit_rate_after和limit_rate：
server {
listen 80;
server_name example.com;
location /downloads/ {
# 默认设置
limit_rate_after 1m;
limit_rate 50k;
# 根据用户IP地址动态调整速率限制
if ($remote_addr = "192.168.1.100") {
limit_rate_after 2m;
limit_rate 100k;
}
if ($remote_addr ~* "^10\..*") {
limit_rate_after 512k;
limit_rate 25k;
}
}
error_page 413 /413.html; # 自定义413错误页面
location = /413.html {
root /usr/share/nginx/html;
}
}
在这个完整示例中：
- 默认情况下，
/downloads/路径下的请求在传输了1 MB数据之后开始限制传输速率为50 KB/s。 - 如果用户的IP地址是
192.168.1.100，则在传输了2 MB数据之后开始限制传输速率为100 KB/s。 - 如果用户的IP地址属于
10.x.x.x网段，则在传输了512 KB数据之后开始限制传输速率为25 KB/s。
注意事项
-
用户体验：合理设置
limit_rate_after值可以平衡用户体验和带宽管理。对于小文件，可以设置较小的阈值，而对于大文件，可以设置较大的阈值，以确保用户能够快速获取初始部分的内容。 -
性能优化：通过结合
limit_rate指令，可以在保证用户体验的同时有效控制带宽使用。特别是对于大文件下载或视频流媒体服务，合理的速率限制可以避免带宽被少数大文件下载占用过多资源。 -
与条件语句结合使用：
limit_rate_after可以在if条件语句中使用，从而实现更灵活的速率限制策略。例如，可以根据用户IP地址或其他条件动态调整速率限制。
lingering_close
lingering_close 指令在Nginx中用于控制如何处理客户端关闭连接时的剩余数据。该指令帮助服务器在客户端关闭连接后，优雅地处理任何未完成的数据传输，从而避免潜在的资源泄漏和提高服务器的稳定性。
Syntax: lingering_close off | on | always;
Default: lingering_close on;
Context: http, server, location
This directive appeared in versions 1.1.0 and 1.0.6.
off：关闭延迟关闭功能。Nginx会在发送完响应后立即关闭连接，不等待客户端的确认。on（默认）：启用延迟关闭功能。Nginx会等待客户端发送完所有数据并确认后再关闭连接。always：强制启用延迟关闭功能。即使客户端没有发送任何数据，Nginx也会等待一段时间再关闭连接。
案例
基本用法
最简单的 lingering_close 使用方法是指定一个适合您应用场景的选项：
server {
listen 80;
server_name example.com;
lingering_close on; # 启用延迟关闭功能
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在发送完响应后等待客户端发送完所有数据并确认后再关闭连接。
关闭延迟关闭功能
如果您希望禁用延迟关闭功能，可以将 lingering_close 设置为 off：
server {
listen 80;
server_name example.com;
lingering_close off; # 禁用延迟关闭功能
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在发送完响应后立即关闭连接，不等待客户端的确认。
强制启用延迟关闭功能
如果您希望确保在所有情况下都使用延迟关闭功能，可以将其设置为 always：
server {
listen 80;
server_name example.com;
lingering_close always; # 强制启用延迟关闭功能
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，即使客户端没有发送任何数据，Nginx也会等待一段时间再关闭连接。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 lingering_close：
http {
client_body_timeout 60s; # 客户端请求体超时时间为60秒
send_timeout 30s; # 发送响应的超时时间为30秒
lingering_close on; # 启用延迟关闭功能
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location /api {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /downloads {
lingering_close always; # 下载路径强制启用延迟关闭功能
alias /var/www/downloads;
}
}
}
在这个例子中：
- 全局配置中设置了客户端请求体超时时间和发送响应的超时时间。
- 全局
lingering_close设置为on，启用延迟关闭功能。 - 对于
/downloads路径，强制启用延迟关闭功能，以确保大文件下载完成后能够正确处理连接关闭。
注意事项
- 资源管理：启用
lingering_close可以帮助避免资源泄漏，特别是在高并发环境下。然而，在某些情况下，这可能会导致连接保持更长时间，占用更多资源。请根据实际需求选择合适的设置。 - 性能考虑：对于大多数应用，默认的
on设置已经足够。如果您的应用需要快速释放资源或有特定的需求，可以根据实际情况调整为off或always。 - 兼容性：确保客户端和下游服务器能够适应这种连接关闭机制，特别是在涉及复杂的交互逻辑时。
- 调试与监控：定期监控服务器的连接状态和性能指标，必要时调整
lingering_close及其他相关配置项，以维持最佳性能。
lingering_time
lingering_time 指令用于设置 Nginx 在关闭连接之前等待客户端读取响应的最长时间。这个指令有助于处理那些在发送完请求后不立即关闭连接的客户端，防止这些客户端占用服务器资源过长时间。通过设置 lingering_time，Nginx 可以确保在合理的时间内关闭连接，从而释放资源。
Syntax: lingering_time time;
Default: lingering_time 30s;
Context: http, server, location
time：指定 Nginx 在关闭连接之前等待客户端读取响应的最长时间。可以使用秒（例如30s）或毫秒（例如500ms）作为单位。
案例
基本用法
最简单的 lingering_time 用法是指定等待时间：
server {
listen 80;
server_name example.com;
# 设置等待时间为 30 秒
lingering_time 30s;
location / {
root /var/www/html;
}
}
在这个例子中：
- 当客户端发送请求并接收到响应后，Nginx 将等待最多 30 秒让客户端完成读取响应。如果超过 30 秒，Nginx 将关闭连接。
缩短等待时间
如果你希望缩短等待时间以更快地释放资源，可以将 lingering_time 设置为较短的时间：
server {
listen 80;
server_name example.com;
# 设置等待时间为 10 秒
lingering_time 10s;
location / {
root /var/www/html;
}
}
在这个例子中：
- 当客户端发送请求并接收到响应后，Nginx 将等待最多 10 秒让客户端完成读取响应。如果超过 10 秒，Nginx 将关闭连接。
在特定的
location块中设置不同的等待时间
你可以根据需要为每个 location 块设置不同的 lingering_time 配置：
server {
listen 80;
server_name example.com;
location /fast-response {
# 设置较短的等待时间
lingering_time 5s;
root /var/www/fast-response;
}
location /slow-response {
# 设置较长的等待时间
lingering_time 60s;
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/fast-response时，Nginx 将等待最多 5 秒让客户端完成读取响应。 - 访问
/slow-response时，Nginx 将等待最多 60 秒让客户端完成读取响应。
注意事项
-
性能与资源管理：较短的
lingering_time可以帮助快速释放服务器资源，减少被慢速客户端占用的风险。但是，过短的等待时间可能会导致一些合法但速度较慢的客户端请求被中断，影响用户体验。 -
用户体验：确保等待时间足够长，以便客户端有足够的时间接收完整的响应内容。否则，用户可能会遇到未完整加载的页面或数据丢失的情况。
-
错误处理：如果客户端在
lingering_time超时前未能完成读取响应，Nginx 将关闭连接。这可能会导致部分响应未完全传输到客户端，因此建议根据实际应用场景合理设置该值。
lingering_timeout
lingering_timeout 指令在 Nginx 中用于设置客户端关闭连接前，Nginx 等待客户端发送剩余数据的时间。这个指令确保了即使客户端已经开始关闭连接，Nginx 也会等待一段时间以接收客户端可能仍在发送的数据。这对于处理某些类型的客户端行为（如部分上传）非常有用。
Syntax: lingering_timeout time;
Default: lingering_timeout 5s;
Context: http, server, location
time：指定 Nginx 在客户端关闭连接之前等待剩余数据的最大时间。默认值是5s（5秒）。
案例
基本用法
最简单的 lingering_timeout 用法是指定一个适合你应用需求的超时时间：
server {
listen 80;
server_name example.com;
lingering_timeout 10s; # 设置等待客户端发送剩余数据的超时时间为10秒
location /upload {
proxy_pass http://backend;
}
}
在这个例子中：
- 客户端关闭连接前，Nginx 将等待最多 10 秒来接收客户端可能仍在发送的数据。
结合其他相关配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 lingering_timeout：
server {
listen 80;
server_name example.com;
lingering_timeout 10s; # 设置等待客户端发送剩余数据的超时时间为10秒
lingering_close always; # 强制启用延迟关闭机制
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
client_header_timeout 60s; # 设置读取请求头超时时间为60秒
location /upload {
client_max_body_size 50m; # 设置允许的最大请求体大小为50MB
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
}
}
在这个例子中：
- 设置了
lingering_timeout为 10 秒，确保客户端关闭连接前有足够的时间发送剩余数据。 - 启用了
lingering_close always，强制启用延迟关闭机制。 - 设置了读取请求体和请求头的超时时间，确保长时间没有活动的连接能及时关闭，释放资源。
- 对于
/upload路径下的请求，设置了最大请求体大小为 50MB，并通过反向代理转发请求到后端服务器。
注意事项
- 延迟关闭机制：
lingering_timeout和lingering_close一起使用可以确保在客户端开始关闭连接时，Nginx 仍然能够处理未完成的请求数据。这对于处理文件上传等场景特别重要。 - 性能与资源平衡：虽然延长
lingering_timeout可以提高对不完整请求的容错能力，但也可能导致更多的空闲连接占用服务器资源。应根据实际应用场景和服务器负载情况进行调整。 - 安全性：合理设置
lingering_timeout和其他超时参数，防止恶意用户通过长时间保持连接的方式消耗服务器资源。 - 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。
listen
listen 指令用于指定Nginx服务器监听的IP地址和端口，以及其他与监听相关的选项。此指令允许你配置多个参数以满足不同的网络需求。默认情况下，Nginx监听所有接口的80端口或8000端口。
Syntax: listen address[:port] [default_server] [ssl] [http2 | quic] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on|off] [reuseport] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];
listen port [default_server] [ssl] [http2 | quic] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on|off] [reuseport] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];
listen unix:path [default_server] [ssl] [http2 | quic] [proxy_protocol] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]];
Default: listen *:80 | *:8000;
Context: server
案例
基本用法
最简单的 listen 用法是指定一个监听地址和端口：
server {
# 监听所有接口的80端口
listen 80;
server_name example.com;
}
在这个例子中：
- 设置了
listen 80，这意味着Nginx将监听所有接口的80端口。
使用特定IP地址
你可以根据需要指定特定的IP地址：
server {
# 监听特定IP地址的80端口
listen 192.168.1.100:80;
server_name example.com;
}
在这个例子中：
- 设置了
listen 192.168.1.100:80，这意味着Nginx将仅监听IP地址为192.168.1.100的80端口。
启用SSL和HTTP/2
你可以启用SSL和HTTP/2协议：
server {
# 监听443端口并启用SSL和HTTP/2
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
}
在这个例子中：
- 设置了
listen 443 ssl http2，这意味着Nginx将监听443端口，并启用SSL和HTTP/2协议。
使用Unix套接字
你可以使用Unix套接字进行监听：
server {
# 监听Unix套接字
listen unix:/var/run/nginx.sock;
server_name example.com;
}
在这个例子中：
- 设置了
listen unix:/var/run/nginx.sock，这意味着Nginx将监听指定的Unix套接字路径。
结合多个选项
你可以结合多个选项来满足复杂的需求：
server {
# 监听80端口，启用proxy_protocol，并设置backlog为1024
listen 80 proxy_protocol backlog=1024;
server_name example.com;
# 处理proxy_protocol头信息
set_real_ip_from 192.168.1.0/24;
real_ip_header proxy_protocol;
}
在这个例子中：
- 设置了
listen 80 proxy_protocol backlog=1024，这意味着Nginx将监听80端口，并启用proxy_protocol和设置backlog为1024。
注意事项
- IP地址和端口选择：确保所选的IP地址和端口未被其他服务占用，并且符合你的网络架构需求。
- SSL/TLS配置：如果启用了SSL/TLS，请确保正确配置证书和密钥文件。错误的配置可能导致连接失败或安全问题。
- 性能优化：通过调整
backlog、rcvbuf、sndbuf等参数可以优化服务器的性能。例如，增加backlog可以提高高并发场景下的连接处理能力。 - 兼容性和安全性：启用
http2或quic可以提高现代浏览器的性能，但请确保客户端支持这些协议。同时，注意启用proxy_protocol时要确保代理服务器正确发送代理协议头信息。 - Unix套接字：使用Unix套接字可以减少网络开销，适用于同一主机上的进程间通信（如与后端应用服务器通信）。
- 调试和监控：如果你遇到连接问题或性能瓶颈，可以通过调整
listen指令的参数，并结合日志进行进一步分析。
location
location 指令用于定义如何匹配请求的URI，并指定这些请求应如何处理。Nginx支持多种匹配方式，包括精确匹配、正则表达式匹配和前缀匹配等。这使得你可以灵活地配置不同的处理逻辑来应对各种类型的请求。
Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default: —
Context: server, location
=：精确匹配。只有当请求的URI与指定的URI完全相同时才会匹配。~：区分大小写的正则表达式匹配。~*：不区分大小写的正则表达式匹配。^~：前缀匹配。如果找到匹配项，则不再检查正则表达式。@name：命名位置（内部重定向）。通常用于错误页面或内部跳转。
案例
精确匹配 (
=)**
精确匹配仅在请求的URI与指定的URI完全相同时才会匹配。
server {
listen 80;
server_name example.com;
location = /exact-match.html {
root /var/www/html;
# 只有当请求为/exact-match.html时才会匹配此location块
}
}
区分大小写的正则表达式匹配 (
~)
使用区分大小写的正则表达式匹配请求的URI。
server {
listen 80;
server_name example.com;
location ~ /images/[0-9]+\.jpg$ {
root /var/www/images;
# 匹配类似/images/123.jpg的请求
}
}
不区分大小写的正则表达式匹配 (
~*)
使用不区分大小写的正则表达式匹配请求的URI。
server {
listen 80;
server_name example.com;
location ~* \.(jpg|jpeg|png|gif)$ {
root /var/www/media;
# 匹配所有以.jpg, .jpeg, .png, .gif结尾的请求，不区分大小写
}
}
前缀匹配 (
^~)
前缀匹配会优先于正则表达式匹配，但只要找到匹配项，就不会再检查正则表达式。
server {
listen 80;
server_name example.com;
location ^~ /static/ {
root /var/www/static;
# 匹配所有以/static/开头的请求，并且不会再检查后续的正则表达式匹配
}
location ~ \.html$ {
root /var/www/html;
# 这个正则表达式匹配不会应用于/static/开头的请求
}
}
命名位置 (
@name)
命名位置通常用于内部重定向或错误处理。
server {
listen 80;
server_name example.com;
location / {
try_files $uri $uri/ @fallback;
}
location @fallback {
rewrite ^ /custom_404.html break;
root /var/www/html;
# 当try_files找不到文件时，内部重定向到@fallback位置
}
error_page 404 = @fallback;
# 当发生404错误时，重定向到@fallback位置
}
注意事项
-
匹配顺序：Nginx按照一定的顺序处理
location块：- 首先检查前缀匹配（
^~）。 - 然后检查精确匹配（
=）。 - 接着检查正则表达式匹配（
~和~*），按它们在配置文件中出现的顺序进行匹配。 - 如果没有匹配到任何正则表达式，则使用最长前缀匹配的结果。
- 首先检查前缀匹配（
-
性能考虑：尽量使用前缀匹配而不是正则表达式匹配，因为前缀匹配通常更高效。如果必须使用正则表达式，确保其尽可能简单和明确，以减少计算开销。
-
内部重定向：命名位置（
@name）主要用于内部重定向和错误处理，避免不必要的外部重定向，提升用户体验和系统效率。 -
日志记录：启用适当的日志记录可以帮助你监控和调试
location匹配相关的问题。你可以通过Nginx的日志配置记录相关的请求信息，以便快速定位和解决问题。
log_not_found
log_not_found 指令在Nginx中用于控制是否记录文件或目录未找到（404错误）的日志信息。通过启用或禁用此指令，您可以管理日志输出的详细程度，从而优化日志管理和服务器性能。
Syntax: log_not_found on | off;
Default: log_not_found on;
Context: http, server, location
on（默认）：启用记录文件或目录未找到的日志。off：禁用记录文件或目录未找到的日志。
案例
基本用法
最简单的 log_not_found 使用方法是指定一个适合您应用场景的选项：
server {
listen 80;
server_name example.com;
log_not_found on; # 启用记录文件或目录未找到的日志
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在文件或目录未找到时记录相应的404错误日志。
禁用记录404错误日志
如果您不希望记录文件或目录未找到的日志，可以将其设置为 off：
server {
listen 80;
server_name example.com;
log_not_found off; # 禁用记录文件或目录未找到的日志
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，即使请求的文件或目录不存在，Nginx也不会记录相应的404错误日志。
根据不同位置配置不同的设置
您可以根据不同的location块配置不同的 log_not_found 设置，以适应不同的需求：
server {
listen 80;
server_name example.com;
location /api {
proxy_pass http://backend-api;
log_not_found off; # 对于API请求，禁用记录文件或目录未找到的日志
}
location /static {
root /var/www/static;
log_not_found on; # 对于静态文件请求，启用记录文件或目录未找到的日志
}
}
在这个例子中：
/api路径下的请求，禁用记录文件或目录未找到的日志，并代理到后台API服务器。/static路径下的请求，启用记录文件或目录未找到的日志，并直接从静态文件目录提供服务。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 log_not_found：
http {
error_log /var/log/nginx/error.log warn; # 设置全局错误日志级别为warn
log_not_found on; # 全局启用记录文件或目录未找到的日志
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /downloads {
alias /var/www/downloads;
log_not_found off; # 对于下载路径，禁用记录文件或目录未找到的日志
}
}
}
在这个例子中：
- 全局配置中设置了错误日志级别为
warn，并启用了记录文件或目录未找到的日志。 - 对于
/downloads路径，禁用记录文件或目录未找到的日志，以减少不必要的日志条目。
注意事项
- 日志管理：启用
log_not_found可以帮助您追踪和调试文件或目录未找到的问题，但过多的404错误日志可能会使日志文件变得庞大，影响日志分析效率。请根据实际需求选择合适的设置。 - 性能考虑：禁用
log_not_found可以减少日志写入操作，从而提高性能，尤其是在高并发环境下频繁出现404错误时。 - 调试与监控：定期检查日志文件，确保关键问题能够被及时发现和处理。如果某些路径不需要详细的404日志记录，可以针对性地禁用该功能。
- 安全性和隐私：避免记录敏感信息到日志文件中，特别是对于公开访问的资源。禁用不必要的日志记录可以帮助保护用户隐私。
log_subrequest
log_subrequest 指令用于控制是否在访问日志中记录子请求的信息。子请求是指在一个主请求处理过程中由 Nginx 内部生成的额外请求（例如通过 include、rewrite 或 proxy_pass 等指令触发的请求）。默认情况下，Nginx 不会在访问日志中记录子请求。
Syntax: log_subrequest on | off;
Default: log_subrequest off;
Context: http, server, location
on | off：决定是否在访问日志中记录子请求。on：启用子请求的日志记录。所有子请求及其相关信息将被记录到访问日志中。off（默认值）：禁用子请求的日志记录。只有主请求会被记录到访问日志中。
案例
基本用法
最简单的 log_subrequest 用法是指定是否启用子请求的日志记录：
server {
listen 80;
server_name example.com;
# 启用子请求的日志记录
log_subrequest on;
location /main {
# 主请求处理逻辑
root /var/www/html;
}
location /sub {
# 子请求处理逻辑
internal; # 标记为内部请求，防止外部直接访问
proxy_pass http://backend_server;
}
}
在这个例子中：
- 当
/main被访问时，如果它触发了对/sub的子请求，Nginx 将在访问日志中记录/sub子请求的相关信息。
禁用子请求的日志记录
如果你不希望在访问日志中记录子请求，可以将 log_subrequest 设置为 off：
server {
listen 80;
server_name example.com;
# 禁用子请求的日志记录
log_subrequest off;
location /main {
# 主请求处理逻辑
root /var/www/html;
}
location /sub {
# 子请求处理逻辑
internal; # 标记为内部请求，防止外部直接访问
proxy_pass http://backend_server;
}
}
在这个例子中：
- 当
/main被访问时，即使它触发了对/sub的子请求，Nginx 也不会在访问日志中记录/sub子请求的相关信息。
注意事项
-
日志量管理：启用子请求的日志记录会增加日志文件的大小和复杂性，特别是在大量使用子请求的应用场景中。确保监控日志文件的增长，并根据需要调整配置。
-
调试与性能：在调试阶段，启用子请求的日志记录可以帮助你更好地理解请求流和内部处理过程。但在生产环境中，建议仅在必要时启用该功能，以避免不必要的性能开销。
-
安全考虑：确保敏感信息不会通过日志泄露。启用子请求的日志记录可能会暴露更多的内部请求细节，因此需要仔细审查和保护日志内容。
max_ranges
max_ranges 指令在 Nginx 中用于限制客户端请求中指定的 HTTP 范围（ranges）的数量。这个指令有助于防止某些类型的拒绝服务（DoS）攻击，这些攻击通过发送大量范围请求来消耗服务器资源。通过设置 max_ranges，你可以控制单个请求中允许的最大范围数量。
Syntax: max_ranges number;
Default: —
Context: http, server, location
This directive appeared in version 1.1.2.
number：指定一个请求中允许的最大范围数。如果未设置或设置为0，则不限制范围数量。
案例
基本用法
最简单的 max_ranges 用法是指定一个适合你应用需求的最大范围数：
server {
listen 80;
server_name example.com;
location /videos/ {
max_ranges 5; # 设置每个请求中允许的最大范围数为5
root /var/www/videos;
}
}
在这个例子中：
/videos/路径下的资源，每个请求中最多允许 5 个范围请求。超过这个数量的范围请求将被拒绝。
结合其他相关配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 max_ranges：
server {
listen 80;
server_name example.com;
max_ranges 10; # 设置每个请求中允许的最大范围数为10
client_max_body_size 50m; # 设置允许的最大请求体大小为50MB
location /videos/ {
max_ranges 5; # 设置每个请求中允许的最大范围数为5
root /var/www/videos;
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
sendfile on; # 启用sendfile以优化文件传输
}
location /images/ {
max_ranges 3; # 设置每个请求中允许的最大范围数为3
root /var/www/images;
}
}
在这个例子中：
- 全局配置中设置了每个请求中允许的最大范围数为 10，并且设置了允许的最大请求体大小为 50MB。
- 对于
/videos/路径下的资源：- 每个请求中最多允许 5 个范围请求。
- 设置了读取请求体的超时时间为 60 秒，并启用了
sendfile以优化大文件传输。
- 对于
/images/路径下的资源，每个请求中最多允许 3 个范围请求。
注意事项
- 安全性：合理设置
max_ranges可以有效防止某些类型的 DoS 攻击，特别是那些通过发送大量范围请求来消耗服务器资源的攻击。确保根据实际应用场景设置合适的最大范围数。 - 性能与资源平衡：虽然限制范围数量可以提高安全性，但也可能导致某些合法请求被拒绝。应根据实际应用场景和服务器负载情况进行调整。
- 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的范围请求错误，可以通过日志分析找到问题根源。
- 用户体验：确保合理的范围限制不会影响用户体验。例如，在视频流媒体场景中，用户可能需要多个范围请求来实现无缝播放，因此应根据具体需求设置合理的范围限制。
merge_slashes
merge_slashes 指令用于控制Nginx是否合并多个连续的斜杠（/）为一个斜杠。启用此选项可以帮助规范化URL路径，避免因路径中多余的斜杠导致的问题。默认情况下，该选项是开启的。
Syntax: merge_slashes on | off;
Default: merge_slashes on;
Context: http, server
on：启用合并多个连续斜杠的功能。off：禁用合并多个连续斜杠的功能。
案例：
基本用法
最简单的 merge_slashes 用法是指定一个开关状态：
server {
listen 80;
server_name example.com;
# 启用合并多个连续斜杠的功能
merge_slashes on;
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中：
- 设置了
merge_slashes on，这意味着当请求路径包含多个连续斜杠时，Nginx会将它们合并为一个斜杠。例如，http://example.com//path///to/resource会被规范化为http://example.com/path/to/resource。
禁用合并多个连续斜杠
你可以根据需要禁用合并多个连续斜杠的功能：
server {
listen 80;
server_name example.com;
# 禁用合并多个连续斜杠的功能
merge_slashes off;
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中：
- 设置了
merge_slashes off，这意味着Nginx不会合并多个连续斜杠。例如，http://example.com//path///to/resource将保持原样处理。
结合其他配置
server {
listen 80;
server_name example.com;
# 启用合并多个连续斜杠的功能
merge_slashes on;
location /old-path/ {
# 使用 rewrite 规则将旧路径重定向到新路径
rewrite ^/old-path/(.*)$ /new-path/$1 permanent;
}
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中：
- 结合了
merge_slashes on和rewrite指令，确保路径规范化的同时，正确处理旧路径到新路径的重定向。
注意事项
- URL规范化：启用
merge_slashes可以帮助规范化URL路径，避免因路径中多余的斜杠导致的潜在问题，如重复内容、重定向循环等。 - SEO影响：搜索引擎可能将带有多个连续斜杠和单一斜杠的URL视为不同的页面，这可能导致重复内容问题。启用
merge_slashes可以避免这种情况。 - 兼容性考虑：某些应用程序或API可能依赖于路径中的多个连续斜杠来区分不同的资源或功能。如果你的应用有这种需求，请谨慎使用
merge_slashes。 - 调试和监控：如果你遇到与路径相关的重定向或路由问题，可以检查
merge_slashes的配置，并结合日志进行进一步分析。 - 结合其他指令：通常与
rewrite和try_files等指令结合使用，以实现更复杂的URL处理逻辑
msie_padding
msie_padding 指令用于控制Nginx是否为Microsoft Internet Explorer（MSIE）浏览器添加额外的填充数据（padding）。这有助于处理某些旧版本MSIE浏览器在处理响应时可能出现的问题，特别是与保持连接相关的bug。
Syntax: msie_padding on | off;
Default: msie_padding on;
Context: http, server, location
on：启用MSIE填充（默认行为）。Nginx会在响应中添加额外的填充数据以确保兼容性。off：禁用MSIE填充。Nginx不会添加任何额外的填充数据。
案例
基本用法
最简单的msie_padding用法是指定是否为MSIE浏览器添加额外的填充数据：
server {
listen 80;
server_name example.com;
msie_padding on; # 启用MSIE填充（默认行为）
}
在这个例子中，当MSIE浏览器请求资源时，Nginx会自动添加额外的填充数据，以确保更好的兼容性。
禁用MSIE
禁用MSIE填充的例子如下：
server {
listen 80;
server_name example.com;
msie_padding off; # 禁用MSIE填充
}
在这个例子中，Nginx不会为MSIE浏览器的请求添加任何额外的填充数据。
不同
server配置
根据需要为不同的server或location块设置不同的msie_padding配置：
http {
include mime.types;
default_type application/octet-stream;
# 全局设置，启用MSIE填充
msie_padding on;
server {
listen 80;
server_name public.example.com;
location /legacy/ {
msie_padding on; # 继承全局设置，启用MSIE填充
}
location /modern/ {
msie_padding off; # 禁用MSIE填充，适用于现代浏览器优化
}
}
server {
listen 80;
server_name secure.example.com;
msie_padding off; # 禁用MSIE填充，适用于特定安全需求
}
}
在这个例子中：
public.example.com服务器块中的/legacy/路径继承了全局设置，启用了MSIE填充。public.example.com服务器块中的/modern/路径禁用了MSIE填充，适用于现代浏览器优化。secure.example.com服务器块禁用了MSIE填充，适用于特定的安全需求。
注意事项
-
兼容性：尽管现代浏览器已经不再需要这种填充机制，但在支持旧版本MSIE浏览器时，启用
msie_padding可以避免一些已知的兼容性问题。如果你的应用主要面向现代浏览器，则可以考虑禁用该选项以减少不必要的开销。 -
性能影响：启用
msie_padding可能会增加少量的数据传输量，尽管这个增量通常很小。对于高流量网站或对性能要求较高的场景，禁用此选项可能有助于优化带宽使用。 -
日志记录：启用适当的日志记录可以帮助你监控和调试与MSIE浏览器相关的响应问题。你可以通过Nginx的日志配置记录相关事件，以便快速定位和解决问题。
-
逐步淘汰：考虑到微软已经停止对旧版Internet Explorer的支持，并且现代浏览器已经广泛普及，建议逐步淘汰对旧版MSIE的支持，并相应地调整Nginx配置。
msie_refresh
msie_refresh 指令在Nginx中用于控制是否对Microsoft Internet Explorer（MSIE）浏览器使用刷新指令（Refresh header）。这个指令主要用于兼容旧版本的Internet Explorer，因为这些浏览器可能不完全支持标准的HTTP重定向机制。
Syntax: msie_refresh on | off;
Default: msie_refresh off;
Context: http, server, location
on：启用对MSIE浏览器使用Refresh头进行重定向。off（默认）：禁用对MSIE浏览器使用Refresh头进行重定向，使用标准的Location头。
案例
基本用法
最简单的 msie_refresh 使用方法是指定一个适合您应用场景的选项：
server {
listen 80;
server_name example.com;
msie_refresh off; # 禁用对MSIE浏览器使用Refresh头
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx不会对MSIE浏览器使用 Refresh 头进行重定向，而是使用标准的 Location 头。
启用对MSIE浏览器使用 Refresh 头
如果您需要处理旧版Internet Explorer中的兼容性问题，可以启用 msie_refresh：
server {
listen 80;
server_name example.com;
msie_refresh on; # 启用对MSIE浏览器使用Refresh头
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会对MSIE浏览器使用 Refresh 头进行重定向，以确保兼容性。
根据不同位置配置不同的设置
您可以根据不同的location块配置不同的 msie_refresh 设置，以适应不同的需求：
server {
listen 80;
server_name example.com;
location /api {
proxy_pass http://backend-api;
msie_refresh off; # 对于API请求，禁用对MSIE浏览器使用Refresh头
}
location /legacy {
alias /var/www/legacy;
msie_refresh on; # 对于旧版应用路径，启用对MSIE浏览器使用Refresh头
}
}
在这个例子中：
/api路径下的请求，禁用对MSIE浏览器使用Refresh头，并代理到后台API服务器。/legacy路径下的请求，启用对MSIE浏览器使用Refresh头，以确保与旧版应用的兼容性。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 msie_refresh：
http {
error_log /var/log/nginx/error.log warn; # 设置全局错误日志级别为warn
msie_refresh off; # 全局禁用对MSIE浏览器使用Refresh头
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /old-system {
alias /var/www/old-system;
msie_refresh on; # 对于旧系统路径，启用对MSIE浏览器使用Refresh头
}
}
}
在这个例子中：
- 全局配置中设置了错误日志级别为
warn，并禁用了对MSIE浏览器使用Refresh头。 - 对于
/old-system路径，启用了对MSIE浏览器使用Refresh头，以确保与旧系统的兼容性。
注意事项
- 兼容性：
msie_refresh主要用于解决旧版Internet Explorer中的兼容性问题。对于现代浏览器和大多数用户来说，通常不需要启用此功能。 - 性能考虑：启用
msie_refresh可能会增加一些额外的处理开销，特别是在高并发环境下。因此，仅在确实需要处理特定的兼容性问题时才启用该选项。 - 调试与监控：定期检查日志文件，确保关键问题能够被及时发现和处理。如果某些路径需要特殊的兼容性处理，可以针对性地启用
msie_refresh。 - 逐步淘汰：考虑到Internet Explorer的使用率逐渐下降，建议逐步淘汰对IE的特殊处理，转向更现代的标准和技术。
open_file_cache
open_file_cache 指令用于控制 Nginx 是否缓存文件描述符、文件查找结果和目录结构。通过启用此缓存，Nginx 可以减少对文件系统的访问次数，从而提高性能。默认情况下，该指令是关闭的。
Syntax: open_file_cache off;
open_file_cache max=N [inactive=time];
Default: open_file_cache off;
Context: http, server, location
off：禁用文件缓存。max=N：设置缓存的最大条目数为 N。inactive=time：设置缓存条目的非活动时间。如果在指定时间内没有访问某个条目，它将被从缓存中移除。时间单位可以是毫秒（ms）、秒（s）、分钟（m）或小时（h）。
案例
基本用法
最简单的 open_file_cache 用法是指定是否启用缓存以及设置最大条目数和非活动时间：
server {
listen 80;
server_name example.com;
# 启用文件缓存，最多缓存 1000 条目，30 分钟内未使用的条目将被移除
open_file_cache max=1000 inactive=30m;
location / {
root /var/www/html;
}
}
在这个例子中：
- Nginx 将缓存最多 1000 个文件描述符和查找结果。
- 如果某个条目在 30 分钟内没有被访问，它将从缓存中移除。
禁用文件缓存
如果你不希望使用文件缓存，可以将其设置为 off：
server {
listen 80;
server_name example.com;
# 禁用文件缓存
open_file_cache off;
location / {
root /var/www/html;
}
}
在这个例子中：
- Nginx 不会缓存任何文件描述符或查找结果。
在特定的
location块中设置不同的缓存配置
你可以根据需要为每个 location 块设置不同的 open_file_cache 配置：
server {
listen 80;
server_name example.com;
location /static {
# 启用文件缓存，最多缓存 2000 条目，60 分钟内未使用的条目将被移除
open_file_cache max=2000 inactive=60m;
root /var/www/static;
}
location /dynamic {
# 禁用文件缓存
open_file_cache off;
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/static时，Nginx 将缓存最多 2000 个文件描述符和查找结果，并在 60 分钟内未使用的条目将被移除。 - 访问
/dynamic时，Nginx 不会缓存任何文件描述符或查找结果。
注意事项
-
性能优化：启用
open_file_cache可以显著提高处理静态资源（如 HTML、CSS、JavaScript 和图像文件）的性能，因为它减少了对文件系统的访问次数。然而，在动态内容较多的应用场景中，缓存的效果可能不明显，甚至可能导致不必要的内存占用。 -
内存管理：缓存条目的数量应根据服务器的内存容量合理设置。过多的缓存条目可能会导致内存耗尽，影响系统性能。
-
缓存失效：确保缓存中的条目不会过期太久，避免返回陈旧的数据。通过合理设置
inactive参数，可以让 Nginx 自动清理不再使用的缓存条目。 -
监控与调整：定期监控缓存命中率和服务器性能，根据实际情况调整
max和inactive参数，以达到最佳性能。
open_file_cache_errors
open_file_cache_errors 指令在 Nginx 中用于控制是否将文件操作错误缓存到 open_file_cache 中。通过启用此指令，Nginx 可以缓存文件操作中的错误（如文件未找到、权限不足等），从而减少对文件系统的访问次数，并提高性能。然而，在某些情况下，禁用此选项可能有助于更快地检测到文件系统的变化。
Syntax: open_file_cache_errors on | off;
Default: open_file_cache_errors off;
Context: http, server, location
on：启用文件操作错误的缓存。off：禁用文件操作错误的缓存（默认行为）。
案例
基本用法
最简单的 open_file_cache_errors 用法是指定是否启用文件操作错误的缓存：
server {
listen 80;
server_name example.com;
open_file_cache_errors on; # 启用文件操作错误的缓存
location /static/ {
root /var/www/static;
open_file_cache max=1000 inactive=20s; # 启用 open_file_cache 并设置参数
}
}
在这个例子中：
- 启用了
open_file_cache_errors，这意味着文件操作中的错误会被缓存到open_file_cache中。 - 在
/static/路径下启用了open_file_cache，并设置了最大缓存条目数为 1000，非活跃时间（inactive time）为 20 秒。
禁用文件操作错误的缓存
如果你希望某些特定的服务器块或位置块不缓存文件操作错误，可以将其设置为 off：
server {
listen 80;
server_name example.com;
location /dynamic/ {
root /var/www/dynamic;
open_file_cache_errors off; # 禁用文件操作错误的缓存
open_file_cache max=500 inactive=10s; # 启用 open_file_cache 并设置参数
}
}
在这个例子中：
- 对于
/dynamic/路径下的请求，禁用了open_file_cache_errors，这意味着文件操作中的错误不会被缓存。 - 同时启用了
open_file_cache，并设置了最大缓存条目数为 500，非活跃时间为 10 秒。
结合其他相关配置项
为了优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 open_file_cache_errors：
server {
listen 80;
server_name example.com;
open_file_cache max=2000 inactive=30s; # 启用 open_file_cache 并设置参数
open_file_cache_valid 60s; # 设置验证缓存的时间间隔为60秒
open_file_cache_min_uses 2; # 设置一个文件必须被访问至少2次才被缓存
open_file_cache_errors on; # 启用文件操作错误的缓存
location /static/ {
root /var/www/static;
sendfile on; # 启用sendfile以优化文件传输
client_max_body_size 50m; # 设置允许的最大请求体大小为50MB
}
location /dynamic/ {
root /var/www/dynamic;
open_file_cache_errors off; # 特定位置禁用文件操作错误的缓存
open_file_cache max=500 inactive=10s; # 启用 open_file_cache 并设置参数
}
}
在这个例子中：
- 启用了
open_file_cache，并设置了最大缓存条目数为 2000，非活跃时间为 30 秒，验证缓存的时间间隔为 60 秒，以及一个文件必须被访问至少 2 次才被缓存。 - 启用了
open_file_cache_errors，意味着文件操作中的错误会被缓存。 - 对于
/static/路径下的资源：- 启用了
sendfile以优化大文件传输。 - 设置了允许的最大请求体大小为 50MB。
- 启用了
- 对于
/dynamic/路径下的资源，禁用了open_file_cache_errors，并启用了open_file_cache，设置了最大缓存条目数为 500，非活跃时间为 10 秒。
注意事项
- 缓存策略：合理设置
open_file_cache和open_file_cache_errors可以显著提高文件操作的性能，特别是在处理大量静态文件时。确保根据实际应用场景设置合适的缓存参数。 - 文件系统变化检测：禁用
open_file_cache_errors可以帮助更快地检测到文件系统的变更，但可能会增加文件系统的访问频率，影响性能。 - 安全性与稳定性：确保合理的缓存策略不会导致安全问题或系统不稳定。例如，频繁的文件系统访问可能导致高负载，尤其是在高并发场景下。
- 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的文件操作错误，可以通过日志分析找到问题根源。
open_file_cache_min_uses
open_file_cache_min_uses 指令用于设置在 open_file_cache 中缓存文件或目录信息所需的最小使用次数。只有当文件或目录在指定的时间段内被访问的次数达到这个最小值时，才会被缓存。默认情况下，该值为1，这意味着只要文件或目录被访问一次就会被缓存。
Syntax: open_file_cache_min_uses number;
Default: open_file_cache_min_uses 1;
Context: http, server, location
number：指定文件或目录在缓存中保留所需的最小使用次数。
案例
基本用法
最简单的 open_file_cache_min_uses 用法是指定一个最小使用次数：
server {
listen 80;
server_name example.com;
# 启用 open_file_cache 并设置最小使用次数为2
open_file_cache max=1000 inactive=60s;
open_file_cache_min_uses 2;
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中：
- 设置了
open_file_cache_min_uses 2，这意味着只有当文件或目录在60秒内被访问至少两次时，才会被缓存。
结合其他配置
你可以在不同的上下文中设置不同的最小使用次数，以满足不同的需求：
server {
listen 80;
server_name example.com;
# 启用 open_file_cache 并设置最大缓存条目数和失效时间
open_file_cache max=1000 inactive=60s;
open_file_cache_min_uses 2;
open_file_cache_valid 1m;
location /static/ {
root /var/www/static;
}
location /dynamic/ {
# 不启用 open_file_cache，动态内容不缓存
root /var/www/dynamic;
}
}
在这个例子中：
-
结合了
open_file_cache、open_file_cache_min_uses和open_file_cache_valid指令，确保静态文件路径下的文件在60秒内被访问至少两次，并且每隔1分钟验证一次缓存的有效性。 -
调试和监控：如果你遇到缓存相关的问题，可以考虑调整
open_file_cache_min_uses的值，并结合日志进行进一步分析。
注意事项
- 性能优化：合理设置
open_file_cache_min_uses可以提高服务器性能，特别是在频繁访问某些文件的情况下。较高的值可以减少缓存中的无效条目，但可能会导致一些常用的文件未能及时缓存。 - 资源管理：较低的
open_file_cache_min_uses值会增加缓存中的条目数量，可能导致内存占用增加。因此，应根据实际负载情况调整该值。 - 结合其他指令：通常与
open_file_cache和open_file_cache_valid等指令结合使用，以实现更高效的文件缓存策略。
open_file_cache_valid
open_file_cache_valid 指令用于设置文件和目录信息在Nginx的打开文件缓存（open file cache）中的有效时间。这有助于优化文件元数据（如文件大小、修改时间等）的访问效率，减少频繁查询文件系统带来的开销。
Syntax: open_file_cache_valid time;
Default: open_file_cache_valid 60s;
Context: http, server, location
time：指定文件和目录信息在缓存中的有效时间。可以使用秒（s）、分钟（m）、小时（h）等单位。例如，60s表示60秒，默认值为60秒。
案例
基本用法
最简单的open_file_cache_valid用法是指定文件和目录信息在缓存中的有效时间：
server {
listen 80;
server_name example.com;
open_file_cache_valid 60s; # 设置文件和目录信息在缓存中的有效时间为60秒
}
在这个例子中，Nginx会将文件和目录信息缓存60秒，在此期间不会重新查询文件系统。
不同
server配置
根据需要为不同的server或location块设置不同的open_file_cache_valid配置：
http {
include mime.types;
default_type application/octet-stream;
# 全局设置，缓存有效期为60秒
open_file_cache_valid 60s;
server {
listen 80;
server_name public.example.com;
location /static/ {
root /var/www/static;
open_file_cache_valid 30s; # 对于/static/路径下的请求，缓存有效期为30秒
}
location /dynamic/ {
root /var/www/dynamic;
open_file_cache_valid 120s; # 对于/dynamic/路径下的请求，缓存有效期为120秒
}
}
server {
listen 80;
server_name secure.example.com;
open_file_cache_valid 180s; # 对于secure.example.com，缓存有效期为180秒
}
}
在这个例子中：
/static/路径下的请求，文件和目录信息在缓存中的有效时间为30秒。/dynamic/路径下的请求，文件和目录信息在缓存中的有效时间为120秒。secure.example.com服务器块中，文件和目录信息在缓存中的有效时间为180秒。
注意事项
-
缓存策略：合理设置
open_file_cache_valid值可以平衡缓存命中率和文件系统的实时性。较短的有效期可以更快地反映文件系统的变化，但可能会增加查询文件系统的频率；较长的有效期可以减少文件系统查询次数，但可能会导致文件变化不能及时反映到客户端。 -
性能优化：结合其他相关指令（如
open_file_cache和open_file_cache_min_uses），可以进一步优化文件元数据的访问效率。例如，启用打开文件缓存并设置最小使用次数，可以避免频繁更新缓存内容。 -
日志记录：启用适当的日志记录可以帮助你监控和调试缓存相关的性能问题。你可以通过Nginx的日志配置记录缓存命中和未命中的情况，以便快速定位和解决问题。
output_buffers
output_buffers 指令在Nginx中用于设置将响应数据发送到客户端时使用的缓冲区数量和每个缓冲区的大小。通过调整这些参数，您可以优化服务器在处理和发送响应时的性能。
Syntax: output_buffers number size;
Default: output_buffers 2 32k;
Context: http, server, location
number：指定用于输出的缓冲区数量。size：指定每个缓冲区的大小。
案例
基本用法
最简单的 output_buffers 使用方法是指定一个适合您应用场景的缓冲区数量和大小：
server {
listen 80;
server_name example.com;
output_buffers 2 32k; # 设置2个32KB大小的输出缓冲区
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx使用2个32KB大小的缓冲区来处理响应数据的输出。
调整缓冲区数量和大小
根据您的具体需求，可以调整缓冲区的数量和大小：
server {
listen 80;
server_name example.com;
output_buffers 4 64k; # 设置4个64KB大小的输出缓冲区
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx使用4个64KB大小的缓冲区来处理响应数据的输出。这适用于需要处理较大响应数据的情况。
根据不同位置配置不同的设置
您可以根据不同的location块配置不同的 output_buffers 设置，以适应不同的需求：
server {
listen 80;
server_name example.com;
location /api {
proxy_pass http://backend-api;
output_buffers 2 16k; # 对于API请求，使用2个16KB大小的输出缓冲区
}
location /downloads {
alias /var/www/downloads;
output_buffers 4 128k; # 对于下载路径，使用4个128KB大小的输出缓冲区
}
}
在这个例子中：
/api路径下的请求，使用2个16KB大小的输出缓冲区，并代理到后台API服务器。/downloads路径下的请求，使用4个128KB大小的输出缓冲区，以适应大文件下载的需求。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 output_buffers：
http {
client_body_buffer_size 16k; # 客户端请求体缓冲区大小为16KB
send_timeout 30s; # 发送响应的超时时间为30秒
output_buffers 2 32k; # 全局设置2个32KB大小的输出缓冲区
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /large_files {
alias /var/www/large_files;
output_buffers 8 256k; # 对于大文件路径，使用8个256KB大小的输出缓冲区
}
}
}
在这个例子中：
- 全局配置中设置了客户端请求体缓冲区大小、发送响应的超时时间以及默认的输出缓冲区设置。
- 对于
/large_files路径，使用8个256KB大小的输出缓冲区，以适应大文件传输的需求。
注意事项
- 资源管理：增加缓冲区的数量和大小可以提高处理大响应数据的能力，但也会占用更多的内存资源。请根据服务器的实际内存情况合理配置。
- 性能优化：对于大多数应用，默认的
output_buffers 2 32k已经足够。如果您的应用需要处理大量大文件或高并发请求，可以根据实际情况适当增加缓冲区的数量和大小。 - 调试与监控：定期监控服务器的性能指标，确保配置的缓冲区设置不会导致内存耗尽或其他性能问题。
- 测试与验证：在生产环境中应用之前，务必在开发或测试环境中充分测试所有配置项，确保它们按预期工作。
port_in_redirect
port_in_redirect 指令用于控制在重定向响应中是否包含端口号。默认情况下，Nginx 在生成重定向 URL 时会包含请求的端口号。通过该指令，您可以选择在重定向 URL 中是否包含端口号。
Syntax: port_in_redirect on | off;
Default: port_in_redirect on;
Context: http, server, location
on | off：决定是否在重定向 URL 中包含端口号。on（默认值）：启用在重定向 URL 中包含端口号。off：禁用在重定向 URL 中包含端口号。
案例
基本用法
最简单的 port_in_redirect 用法是指定是否在重定向 URL 中包含端口号：
server {
listen 8080;
server_name example.com;
# 启用在重定向 URL 中包含端口号
port_in_redirect on;
location /old-location {
return 301 /new-location;
}
}
在这个例子中：
- 当用户访问
http://example.com:8080/old-location时，Nginx 将返回一个重定向响应，URL 为http://example.com:8080/new-location，其中包含了端口号8080。
禁用在重定向 URL 中包含端口号
如果你希望在重定向 URL 中不包含端口号，可以将 port_in_redirect 设置为 off：
server {
listen 8080;
server_name example.com;
# 禁用在重定向 URL 中包含端口号
port_in_redirect off;
location /old-location {
return 301 /new-location;
}
}
在这个例子中：
- 当用户访问
http://example.com:8080/old-location时，Nginx 将返回一个重定向响应，URL 为http://example.com/new-location，其中不包含端口号8080。
注意事项
-
标准端口处理：对于标准端口（HTTP 的 80 端口和 HTTPS 的 443 端口），即使启用了
port_in_redirect on，Nginx 也不会在重定向 URL 中包含这些端口号。因此，通常不需要特别担心标准端口的问题。 -
非标准端口：如果你的应用运行在非标准端口上（如 8080 或 8443），并且你希望生成的重定向 URL 中不包含这些端口号，可以将
port_in_redirect设置为off。这有助于简化 URL 并提高用户体验。 -
反向代理场景：在使用反向代理时，确保前后端服务器之间的端口号配置一致。否则，可能会导致重定向 URL 不正确或无法访问。
postpone_output
postpone_output 指令在 Nginx 中用于控制何时开始向客户端发送响应数据。具体来说，它定义了在开始发送响应之前，Nginx 应该缓冲多少字节的数据。通过设置这个指令，可以优化响应的传输效率，减少网络往返次数，并提高整体性能。
Syntax: postpone_output size;
Default: postpone_output 1460;
Context: http, server, location
size：指定在开始发送响应之前，Nginx 应该缓冲的最大字节数。默认值是1460字节，这通常对应于一个典型的以太网 MTU（最大传输单元）大小。
案例
基本用法
最简单的 postpone_output 用法是指定一个适合你应用需求的缓冲大小：
server {
listen 80;
server_name example.com;
postpone_output 4096; # 设置缓冲大小为4KB
location / {
root /var/www/html;
index index.html index.htm;
}
}
在这个例子中：
- 在开始发送响应之前，Nginx 将缓冲最多 4KB 的数据。这意味着如果响应内容小于 4KB，Nginx 会等待直到收集到足够的数据后再一次性发送给客户端，从而减少网络往返次数。
根据上下文调整缓冲大小
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 postpone_output 的值：
http {
postpone_output 2048; # 全局设置为2KB
server {
listen 80;
server_name example.com;
location /small-responses/ {
postpone_output 1024; # 特定位置设置为1KB
root /var/www/small-responses;
}
location /large-responses/ {
postpone_output 8192; # 特定位置设置为8KB
root /var/www/large-responses;
}
}
}
在这个例子中：
- 全局配置下，默认缓冲大小被设置为 2KB。
- 对于
/small-responses/路径下的请求，缓冲大小被设置为 1KB。 - 对于
/large-responses/路径下的请求，缓冲大小被设置为 8KB。
注意事项
- 性能优化：合理设置
postpone_output可以减少网络往返次数，提高传输效率。特别是对于较大的响应内容，适当增加缓冲大小可以显著提升性能。 - 内存使用：较大的缓冲大小可能会增加内存占用，特别是在处理大量并发请求时。应根据实际应用场景和服务器资源进行调整。
- 延迟问题：过大的缓冲大小可能导致首次响应延迟增加，因为需要等待更多的数据才能开始发送响应。对于实时性要求较高的应用，应谨慎设置缓冲大小。
- 兼容性：确保客户端和中间设备（如代理服务器、CDN等）支持并正确处理你所设置的缓冲策略。某些旧客户端或中间设备可能不完全支持这些优化策略。
read_ahead
read_ahead 指令用于设置预读取数据的大小（以字节为单位）。通过预读取，Nginx可以在处理大文件传输时提前读取更多的数据到缓存中，从而提高性能。默认情况下，该值为0，表示不启用预读取功能。
Syntax: read_ahead size;
Default: read_ahead 0;
Context: http, server, location
size：指定预读取数据的大小，单位为字节。例如，4k表示4KB，1m表示1MB。
案例
基本用法
最简单的 read_ahead 用法是指定一个预读取大小：
server {
listen 80;
server_name example.com;
location /videos/ {
# 设置预读取大小为512KB
read_ahead 512k;
root /var/www/videos;
}
}
在这个例子中：
- 设置了
read_ahead 512k，这意味着在处理/videos/路径下的请求时，Nginx会预读取512KB的数据到缓存中，以提高大文件传输的性能。
结合其他配置
你可以结合其他配置：
server {
listen 80;
server_name example.com;
location /videos/ {
# 设置预读取大小为512KB
read_ahead 512k;
# 启用 sendfile 以减少数据拷贝次数
sendfile on;
# 启用 tcp_nopush 以减少TCP包的数量
tcp_nopush on;
root /var/www/videos;
}
}
在这个例子中：
-
结合了
read_ahead、sendfile和tcp_nopush指令，确保在处理视频文件传输时，尽可能高效地利用系统资源，减少不必要的I/O和网络开销。 -
调试和监控：如果你遇到文件传输性能问题，可以考虑调整
read_ahead的值，并结合日志进行进一步分析。同时，可以使用工具（如iotop或iostat）监控磁盘I/O性能。
注意事项
- 性能优化：合理设置
read_ahead可以显著提高大文件传输的性能，特别是在高延迟或高负载环境中。较大的预读取值可以减少磁盘I/O操作次数，但也会占用更多内存资源。 - 资源管理：较大的
read_ahead值会增加内存占用，可能导致系统资源紧张。因此，应根据实际负载情况和可用内存调整该值。 - 适用场景：预读取特别适用于大文件传输场景，如视频流、大文件下载等。对于小文件或频繁访问的静态资源，预读取的效果可能不明显，甚至可能带来额外的开销。
- 结合其他指令：通常与
sendfile和tcp_nopush等指令结合使用，以实现更高效的文件传输策略。
recursive_error_pages
recursive_error_pages 指令用于控制Nginx是否允许在错误页面处理过程中递归地处理错误。默认情况下，该指令是关闭的（off），这意味着Nginx不会递归地尝试加载错误页面。启用此选项可以提供更灵活的错误处理机制，但需要谨慎使用以避免潜在的循环错误。
Syntax: recursive_error_pages on | off;
Default: recursive_error_pages off;
Context: http, server, location
on：允许递归地处理错误页面。off：不允许递归地处理错误页面（默认行为）。
案例
基本用法
最简单的recursive_error_pages用法是指定是否允许递归地处理错误页面：
server {
listen 80;
server_name example.com;
recursive_error_pages off; # 禁止递归地处理错误页面（默认行为）
}
在这个例子中，当发生错误时，Nginx将不会递归地尝试加载错误页面，从而避免了潜在的循环错误。
启用
启用递归错误页面处理的例子如下：
server {
listen 80;
server_name example.com;
recursive_error_pages on; # 允许递归地处理错误页面
error_page 404 /custom_404.html;
location = /custom_404.html {
root /usr/share/nginx/html;
internal;
}
error_page 500 502 503 504 /custom_50x.html;
location = /custom_50x.html {
root /usr/share/nginx/html;
internal;
}
}
在这个例子中，Nginx允许递归地处理错误页面。如果自定义的错误页面（如/custom_404.html或/custom_50x.html）本身也发生错误，Nginx将继续尝试处理这些错误，而不是直接返回原始错误代码。
注意事项
-
循环错误：启用
recursive_error_pages可能会导致循环错误。例如，如果自定义的错误页面本身也触发了错误，Nginx会继续尝试处理这些错误，可能导致无限循环。为了避免这种情况，确保自定义错误页面尽可能简单，并且不会触发其他错误。 -
性能影响：虽然递归处理错误页面提供了更大的灵活性，但它也可能增加处理开销。因此，在不需要的情况下应保持禁用状态，以减少不必要的复杂性和潜在的性能问题。
-
日志记录：启用适当的日志记录可以帮助你监控和调试与错误页面相关的处理问题。你可以通过Nginx的日志配置记录相关事件，以便快速定位和解决问题。
-
内部指令：使用
internal指令可以防止直接访问自定义错误页面，确保它们仅在发生错误时被内部调用。这有助于避免用户直接访问错误页面带来的安全风险。
request_pool_size
request_pool_size 指令在Nginx中用于设置每个请求的内存池大小。这个内存池是Nginx为每个请求分配的基础内存块，用于处理请求期间的各种操作和数据存储。通过调整这个值，您可以优化服务器在处理请求时的内存使用和性能。
Syntax: request_pool_size size;
Default: request_pool_size 4k;
Context: http, server
size：指定每个请求的内存池大小，默认值为4KB（即4k）。
案例
基本用法
最简单的 request_pool_size 使用方法是指定一个适合您应用场景的内存池大小：
server {
listen 80;
server_name example.com;
request_pool_size 4k; # 设置每个请求的内存池大小为4KB
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx为每个请求分配4KB的内存池。
根据不同服务器配置不同的设置
您可以根据不同的服务器配置不同的 request_pool_size 设置，以适应不同的需求：
http {
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
request_pool_size 4k; # 对于默认服务器，设置每个请求的内存池大小为4KB
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
server {
listen 8080;
server_name large-app.example.com;
request_pool_size 16k; # 对于大型应用服务器，设置每个请求的内存池大小为16KB
location / {
proxy_pass http://large-backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
在这个例子中：
- 默认服务器（监听端口80）为每个请求分配4KB的内存池。
- 大型应用服务器（监听端口8080）为每个请求分配16KB的内存池，以适应更复杂的请求处理需求。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 request_pool_size：
http {
client_body_buffer_size 16k; # 客户端请求体缓冲区大小为16KB
client_max_body_size 10m; # 客户端请求的最大主体大小为10MB
request_pool_size 8k; # 全局设置每个请求的内存池大小为8KB
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /heavy_processing {
request_pool_size 32k; # 对于需要大量内存处理的路径，设置每个请求的内存池大小为32KB
alias /var/www/heavy_processing;
}
}
}
在这个例子中：
- 全局配置中设置了客户端请求体缓冲区大小、客户端请求的最大主体大小以及默认的每个请求的内存池大小。
- 对于
/heavy_processing路径，使用32KB的内存池，以适应需要大量内存处理的需求。
注意事项
- 资源管理：增加内存池的大小可以提高处理复杂请求的能力，但也会占用更多的内存资源。请根据服务器的实际内存情况合理配置。
- 性能优化：对于大多数应用，默认的
request_pool_size 4k已经足够。如果您的应用需要处理大量大文件或高并发请求，可以根据实际情况适当增加内存池的大小。 - 调试与监控：定期监控服务器的内存使用情况，确保配置的内存池大小不会导致内存耗尽或其他性能问题。
- 测试与验证：在生产环境中应用之前，务必在开发或测试环境中充分测试所有配置项，确保它们按预期工作。
reset_timedout_connection
reset_timedout_connection 指令用于控制当客户端连接超时时，Nginx 是否发送 RST（复位）包立即关闭连接。默认情况下，该指令是关闭的，这意味着 Nginx 会等待客户端主动关闭连接。
Syntax: reset_timedout_connection on | off;
Default: reset_timedout_connection off;
Context: http, server, location
on | off：决定是否在连接超时时发送 RST 包立即关闭连接。on：启用在连接超时时发送 RST 包立即关闭连接。off（默认值）：禁用在连接超时时发送 RST 包，Nginx 将等待客户端主动关闭连接。
案例
基本用法
最简单的 reset_timedout_connection 用法是指定是否启用在连接超时时发送 RST 包：
server {
listen 80;
server_name example.com;
# 启用在连接超时时发送 RST 包立即关闭连接
reset_timedout_connection on;
location / {
root /var/www/html;
client_body_timeout 10s; # 设置客户端请求体超时时间为 10 秒
}
}
在这个例子中：
- 如果客户端在 10 秒内没有发送完请求体，Nginx 将发送 RST 包立即关闭连接，而不是等待客户端主动关闭连接。
禁用在连接超时时发送 RST 包
如果你希望禁用在连接超时时发送 RST 包，可以将 reset_timedout_connection 设置为 off：
server {
listen 80;
server_name example.com;
# 禁用在连接超时时发送 RST 包
reset_timedout_connection off;
location / {
root /var/www/html;
client_body_timeout 10s; # 设置客户端请求体超时时间为 10 秒
}
}
在这个例子中：
- 如果客户端在 10 秒内没有发送完请求体，Nginx 将不会发送 RST 包，而是等待客户端主动关闭连接。
在特定的
location块中设置不同的reset_timedout_connection配置
你可以根据需要为每个 location 块设置不同的 reset_timedout_connection 配置：
server {
listen 80;
server_name example.com;
location /quick-response {
# 启用在连接超时时发送 RST 包立即关闭连接
reset_timedout_connection on;
client_body_timeout 5s; # 设置客户端请求体超时时间为 5 秒
root /var/www/quick-response;
}
location /long-response {
# 禁用在连接超时时发送 RST 包
reset_timedout_connection off;
client_body_timeout 20s; # 设置客户端请求体超时时间为 20 秒
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/quick-response时，如果客户端在 5 秒内没有发送完请求体，Nginx 将发送 RST 包立即关闭连接。 - 访问
/long-response时，如果客户端在 20 秒内没有发送完请求体，Nginx 将不会发送 RST 包，而是等待客户端主动关闭连接。
注意事项
-
资源管理：启用
reset_timedout_connection可以更快地释放服务器资源，尤其是在高并发场景下，防止慢速或无响应的客户端长时间占用连接。然而，这可能会导致一些合法但速度较慢的客户端请求被中断，影响用户体验。 -
兼容性：某些客户端可能不正确处理 RST 包，导致异常行为或错误提示。确保测试不同类型的客户端以验证其兼容性。
-
性能优化：通过合理设置
client_body_timeout和reset_timedout_connection，可以在性能和用户体验之间找到平衡点。例如，在高负载环境下，启用reset_timedout_connection可以帮助减少不必要的资源占用。
resolver
resolver 指令在 Nginx 中用于指定 DNS 服务器的地址，以便 Nginx 能够解析域名。这对于反向代理、负载均衡和其他需要域名解析的功能非常重要。通过配置 resolver，你可以确保 Nginx 使用特定的 DNS 服务器来解析域名，并且可以设置其他选项如缓存时间、IP 版本偏好等。
Syntax: resolver address ... [valid=time] [ipv4=on|off] [ipv6=on|off] [status_zone=zone];
Default: —
Context: http, server, location
address：指定一个或多个 DNS 服务器的 IP 地址。valid=time：指定 DNS 缓存的有效时间，默认单位是秒（例如valid=300s表示缓存有效时间为 5 分钟）。ipv4=on|off：启用或禁用 IPv4 解析（默认为on）。ipv6=on|off：启用或禁用 IPv6 解析（默认为on）。status_zone=zone：启用状态统计信息收集，并将其存储在指定的状态区域中。
案例
基本用法
最简单的 resolver 用法是指定一个或多个 DNS 服务器的 IP 地址：
server {
listen 80;
server_name example.com;
resolver 8.8.8.8; # 使用 Google 的公共 DNS 服务器
location / {
proxy_pass http://backend.example.com; # 反向代理到后端服务器
}
}
在这个例子中：
- Nginx 将使用 Google 的公共 DNS 服务器（IP 地址为
8.8.8.8）来解析backend.example.com的域名。
设置 DNS 缓存有效期
你可以设置 DNS 缓存的有效时间，以减少频繁的 DNS 查询：
server {
listen 80;
server_name example.com;
resolver 8.8.8.8 valid=300s; # 使用 Google 的公共 DNS 服务器，缓存有效时间为5分钟
location / {
proxy_pass http://backend.example.com; # 反向代理到后端服务器
}
}
在这个例子中：
- DNS 缓存的有效时间被设置为 300 秒（即 5 分钟），这意味着 Nginx 在这期间将不会再次查询相同的域名。
用 IPv6 解析
如果你希望仅使用 IPv4 进行域名解析，可以禁用 IPv6 解析：
server {
listen 80;
server_name example.com;
resolver 8.8.8.8 ipv6=off; # 使用 Google 的公共 DNS 服务器，禁用 IPv6 解析
location / {
proxy_pass http://backend.example.com; # 反向代理到后端服务器
}
}
在这个例子中：
- 禁用了 IPv6 解析，Nginx 将只使用 IPv4 进行域名解析。
根据上下文调整配置
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 resolver 的值：
http {
resolver 8.8.8.8 valid=600s ipv4=on ipv6=on; # 全局设置，使用 Google 的公共 DNS 服务器，缓存有效时间为10分钟
server {
listen 80;
server_name example.com;
location /api/ {
resolver 1.1.1.1 valid=300s ipv6=off; # 特定位置使用 Cloudflare 的公共 DNS 服务器，禁用 IPv6 解析
proxy_pass http://api.backend.com;
}
location /static/ {
resolver 8.8.8.8 valid=900s; # 特定位置使用 Google 的公共 DNS 服务器，缓存有效时间为15分钟
root /var/www/static;
}
}
}
在这个例子中：
- 全局配置下，默认使用 Google 的公共 DNS 服务器，DNS 缓存有效时间为 10 分钟，并同时启用 IPv4 和 IPv6 解析。
- 对于
/api/路径下的请求，使用 Cloudflare 的公共 DNS 服务器（IP 地址为1.1.1.1），缓存有效时间为 5 分钟，并禁用 IPv6 解析。 - 对于
/static/路径下的请求，使用 Google 的公共 DNS 服务器，缓存有效时间为 15 分钟。
启用状态统计信息收集
你可以启用状态统计信息收集，并将其存储在指定的状态区域中：
server {
listen 80;
server_name example.com;
resolver 8.8.8.8 status_zone=example_resolver; # 使用 Google 的公共 DNS 服务器，并启用状态统计信息收集
location / {
proxy_pass http://backend.example.com; # 反向代理到后端服务器
}
}
在这个例子中：
- 启用了状态统计信息收集，并将其存储在名为
example_resolver的状态区域中。这些统计信息可以帮助你监控和分析 DNS 解析的性能。
注意事项
- DNS 缓存：合理设置
valid参数可以减少频繁的 DNS 查询，提高性能。但过长的缓存时间可能导致无法及时响应 DNS 记录的变化，因此应根据实际需求进行调整。 - IP 版本选择：根据你的网络环境和应用需求，决定是否启用或禁用 IPv4 或 IPv6 解析。某些旧客户端可能不支持 IPv6，或者你的网络环境中可能没有 IPv6 支持。
- 可靠性：确保所使用的 DNS 服务器具有高可用性和低延迟。如果主 DNS 服务器不可用，考虑配置多个 DNS 服务器作为备份。
- 安全性：确保 DNS 配置的安全性，避免使用不受信任的 DNS 服务器，防止潜在的安全风险。
- 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的 DNS 解析错误，可以通过日志分析找到问题根源。
resolver_timeout
resolver_timeout 指令用于设置DNS解析的超时时间。当Nginx需要进行域名解析时（例如在反向代理或重定向中），此指令控制等待DNS服务器响应的最大时间。默认情况下，该值为30秒。
Syntax: resolver_timeout time;
Default: resolver_timeout 30s;
Context: http, server, location
time：指定DNS解析的超时时间，单位可以是秒（如10s）或毫秒（如500ms）。
案例：
基本用法
最简单的 resolver_timeout 用法是指定一个超时时间：
server {
listen 80;
server_name example.com;
# 设置DNS解析超时时间为10秒
resolver_timeout 10s;
location / {
proxy_pass http://backend.example.com;
}
}
在这个例子中：
- 设置了
resolver_timeout 10s，这意味着Nginx在进行DNS解析时最多等待10秒以获取响应。如果超过这个时间，将返回解析失败的错误。
在多个上下文中设置不同的超时时间
你可以在不同的上下文中设置不同的超时时间，以满足不同的需求：
http {
# 全局设置DNS解析超时时间为20秒
resolver_timeout 20s;
server {
listen 80;
server_name example.com;
# 特定服务器块设置DNS解析超时时间为10秒
resolver_timeout 10s;
location /fast/ {
proxy_pass http://fast-backend.example.com;
}
location /slow/ {
# 继承全局设置的DNS解析超时时间（20秒）
proxy_pass http://slow-backend.example.com;
}
}
server {
listen 80;
server_name another-example.com;
# 启用全局设置的DNS解析超时时间（20秒）
location / {
proxy_pass http://another-backend.example.com;
}
}
}
在这个例子中：
- 在全局
http块中设置了resolver_timeout 20s。 - 对于
example.com，将resolver_timeout设置为10s。 - 对于
/slow/路径，继承全局设置的20s。 - 对于
another-example.com，使用全局设置的20s。
注意事项
- 性能优化：合理设置
resolver_timeout可以避免长时间等待DNS解析结果，从而提高请求处理效率。较短的超时时间可以更快地检测到解析失败，并采取相应的措施（如重试或返回错误）。 - 网络延迟和可靠性：如果你的DNS服务器响应速度较慢或不可靠，过短的超时时间可能导致频繁的解析失败。在这种情况下，适当增加超时时间可能更合适。
- 结合其他指令：通常与
resolver指令结合使用，以指定使用的DNS服务器。
root
root 指令用于定义文件系统中的根目录，Nginx会根据这个路径来查找请求的文件。它是一个非常基础且重要的指令，用于指定静态资源（如HTML、CSS、JavaScript文件等）的位置。
Syntax: root path;
Default: root html;
Context: http, server, location, if in location
path：指定文件系统中的根目录路径。例如，/var/www/html表示Nginx将从该目录开始查找请求的文件。
案例
基本用法
最简单的root用法是指定文件系统中的根目录：
server {
listen 80;
server_name example.com;
root /var/www/html; # 设置根目录为/var/www/html
}
在这个例子中，当用户访问example.com/index.html时，Nginx会在/var/www/html目录下查找index.html文件。
为不同的
server配置
根据需要为不同的server或location块设置不同的root配置：
http {
include mime.types;
default_type application/octet-stream;
# 全局设置，根目录为默认的html目录
root html;
server {
listen 80;
server_name public.example.com;
location /static/ {
root /var/www/public; # 对于/static/路径下的请求，根目录为/var/www/public
}
location /dynamic/ {
root /var/www/dynamic; # 对于/dynamic/路径下的请求，根目录为/var/www/dynamic
}
}
server {
listen 80;
server_name secure.example.com;
root /var/www/secure; # 对于secure.example.com，根目录为/var/www/secure
}
}
在这个例子中：
/static/路径下的请求，根目录为/var/www/public。/dynamic/路径下的请求，根目录为/var/www/dynamic。secure.example.com服务器块的根目录为/var/www/secure。
注意事项
-
路径拼接规则：Nginx在处理请求时，会将
location块中的URI部分与root指令指定的路径拼接起来，形成最终的文件路径。例如，对于location /static/ { root /var/www/public; }，当请求/static/image.jpg时，Nginx会尝试从/var/www/public/static/image.jpg读取文件。 -
性能优化：确保根目录设置正确，并尽量避免不必要的目录层级嵌套，以提高文件查找效率。如果可能，使用符号链接（symlink）来简化复杂的目录结构。
-
安全性：确保根目录及其子目录具有适当的权限设置，防止未经授权的访问。特别是当根目录包含敏感数据时，应采取额外的安全措施（如访问控制列表ACL）。
-
日志记录：启用适当的日志记录可以帮助你监控和调试文件查找相关的问题。你可以通过Nginx的日志配置记录文件查找失败的情况，以便快速定位和解决问题。
satisfy
satisfy 指令在Nginx中用于控制如何处理访问控制指令（如 allow 和 deny）与基于HTTP基本认证或其他认证机制的访问限制。通过设置 satisfy all 或 satisfy any，您可以定义这些访问控制规则是否需要同时满足（AND逻辑）还是只需满足其中一个（OR逻辑）。
Syntax: satisfy all | any;
Default: satisfy all;
Context: http, server, location
all（默认）：所有访问控制条件都必须满足。例如，如果同时配置了IP白名单和HTTP基本认证，则客户端必须来自允许的IP地址并且提供正确的认证凭据。any：只需满足其中一个访问控制条件。例如，如果同时配置了IP白名单和HTTP基本认证，则客户端只需要来自允许的IP地址或提供正确的认证凭据中的一个即可。
案例
基本用法
最简单的 satisfy 使用方法是指定一个适合您应用场景的选项：
server {
listen 80;
server_name example.com;
satisfy all; # 所有访问控制条件都必须满足
location /protected {
allow 192.168.1.1; # 只允许来自IP地址192.168.1.1的请求
deny all; # 拒绝其他所有请求
auth_basic "Restricted Area"; # 启用HTTP基本认证
auth_basic_user_file /etc/nginx/.htpasswd; # 指定用户文件路径
}
}
在这个例子中，只有来自IP地址 192.168.1.1 的请求且提供了正确的HTTP基本认证凭据才能访问 /protected 路径。
使用
satisfy any
如果您希望客户端只需满足其中一个访问控制条件，可以使用 satisfy any：
server {
listen 80;
server_name example.com;
satisfy any; # 只需满足其中一个访问控制条件
location /protected {
allow 192.168.1.1; # 允许来自IP地址192.168.1.1的请求
deny all; # 拒绝其他所有请求
auth_basic "Restricted Area"; # 启用HTTP基本认证
auth_basic_user_file /etc/nginx/.htpasswd; # 指定用户文件路径
}
}
在这个例子中，来自IP地址 192.168.1.1 的请求或者提供了正确HTTP基本认证凭据的请求都可以访问 /protected 路径。
根据不同位置配置不同的设置
您可以根据不同的location块配置不同的 satisfy 设置，以适应不同的需求：
server {
listen 80;
server_name example.com;
location /api {
satisfy all; # 对于API请求，所有访问控制条件都必须满足
allow 10.0.0.0/8; # 允许来自10.0.0.0/8子网的请求
deny all; # 拒绝其他所有请求
auth_basic "Protected API"; # 启用HTTP基本认证
auth_basic_user_file /etc/nginx/.htpasswd-api; # 指定用户文件路径
}
location /downloads {
satisfy any; # 对于下载路径，只需满足其中一个访问控制条件
allow 192.168.1.0/24; # 允许来自192.168.1.0/24子网的请求
deny all; # 拒绝其他所有请求
auth_basic "Download Area"; # 启用HTTP基本认证
auth_basic_user_file /etc/nginx/.htpasswd-downloads; # 指定用户文件路径
}
}
在这个例子中：
/api路径下的请求，要求客户端必须来自允许的IP地址并且提供正确的HTTP基本认证凭据。/downloads路径下的请求，客户端只需来自允许的IP地址或提供正确的HTTP基本认证凭据中的一个即可。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 satisfy：
http {
limit_conn_zone $binary_remote_addr zone=addr:10m; # 定义连接限制区
limit_req_zone $binary_remote_addr zone=req:10m rate=5r/s; # 定义请求速率限制区
server {
listen 80;
server_name example.com;
location /secure {
satisfy all; # 所有访问控制条件都必须满足
allow 192.168.1.1; # 允许来自IP地址192.168.1.1的请求
deny all; # 拒绝其他所有请求
auth_basic "Secure Area"; # 启用HTTP基本认证
auth_basic_user_file /etc/nginx/.htpasswd-secure; # 指定用户文件路径
limit_conn addr 10; # 限制每个IP地址最多10个并发连接
limit_req zone=req burst=5 nodelay; # 限制请求速率
}
location /public {
satisfy any; # 只需满足其中一个访问控制条件
allow 192.168.1.0/24; # 允许来自192.168.1.0/24子网的请求
deny all; # 拒绝其他所有请求
auth_basic "Public Area"; # 启用HTTP基本认证
auth_basic_user_file /etc/nginx/.htpasswd-public; # 指定用户文件路径
}
}
}
在这个例子中：
/secure路径下的请求，要求客户端必须来自允许的IP地址并且提供正确的HTTP基本认证凭据，并且还设置了连接和请求速率限制。/public路径下的请求，客户端只需来自允许的IP地址或提供正确的HTTP基本认证凭据中的一个即可。
注意事项
- 安全性：使用
satisfy all可以提高安全性，因为它确保所有访问控制条件都必须满足。然而，在某些情况下，这可能会过于严格。在这种情况下，可以考虑使用satisfy any来放松限制。 - 灵活性：
satisfy any提供了更大的灵活性，允许客户端通过多种方式之一获得访问权限。但是，请注意这可能会降低安全性，因此应谨慎使用。 - 调试与监控：定期检查访问日志和错误日志，确保关键问题能够被及时发现和处理。特别是在调整访问控制策略时，务必进行充分测试。
- 性能优化：结合其他访问控制和限流措施（如
limit_conn和limit_req），可以进一步优化服务器的安全性和性能。
send_lowat
send_lowat 指令用于设置发送缓冲区的低水位标记（low water mark）。这个值决定了在发送操作后剩余数据量低于多少时，系统会认为该套接字准备好进行下一次写操作。默认情况下，该值为 0，表示不使用低水位标记。
Syntax: send_lowat size;
Default: send_lowat 0;
Context: http, server, location
size：指定发送缓冲区的低水位标记大小。单位可以是字节（B），例如1k表示 1024 字节。如果设置为0，则禁用低水位标记功能。
案例
基本用法
最简单的 send_lowat 用法是指定发送缓冲区的低水位标记大小：
server {
listen 80;
server_name example.com;
# 设置发送缓冲区的低水位标记为 4KB
send_lowat 4k;
location / {
root /var/www/html;
}
}
在这个例子中：
- Nginx 将使用 4KB 作为发送缓冲区的低水位标记。当发送缓冲区中的数据量低于 4KB 时，系统将认为该套接字准备好进行下一次写操作。
在特定的
location块中设置不同的send_lowat配置
你可以根据需要为每个 location 块设置不同的 send_lowat 配置：
server {
listen 80;
server_name example.com;
location /high-priority {
# 设置发送缓冲区的低水位标记为 2KB
send_lowat 2k;
root /var/www/high-priority;
}
location /low-priority {
# 禁用低水位标记
send_lowat 0;
root /var/www/low-priority;
}
}
在这个例子中：
- 访问
/high-priority时，Nginx 将使用 2KB 作为发送缓冲区的低水位标记。 - 访问
/low-priority时，Nginx 将禁用低水位标记，每次发送操作完成后，系统会立即尝试下一次写操作。
注意事项
-
性能优化：低水位标记可以帮助控制网络传输的效率和响应时间。较低的低水位标记可能会导致更频繁的写操作，从而提高响应速度，但也可能增加 CPU 和网络负载。较高的低水位标记可以减少写操作的频率，降低 CPU 负载，但可能会增加延迟。
-
系统兼容性：并非所有操作系统都支持低水位标记的功能。在某些系统上，即使设置了
send_lowat，也可能不会生效。确保测试您的具体环境以验证其行为。 -
调试与监控：通过监控网络流量和服务器性能，可以根据实际需求调整
send_lowat的值，找到最佳的配置参数。
send_timeout
send_timeout 指令在 Nginx 中用于设置将响应发送给客户端的超时时间。具体来说，它定义了两次写操作之间的最大允许间隔时间。如果在这个时间内没有完成数据传输，连接将会被关闭。这个指令对于控制服务器资源使用和提高响应效率非常重要。
Syntax: send_timeout time;
Default: send_timeout 60s;
Context: http, server, location
time：指定两次写操作之间的最大允许间隔时间，默认值是60s（即 60 秒）。
案例
基本用法
最简单的 send_timeout 用法是指定一个适合你应用需求的超时时间：
server {
listen 80;
server_name example.com;
send_timeout 30s; # 设置发送超时时间为30秒
location / {
root /var/www/html;
index index.html index.htm;
}
}
在这个例子中：
- 发送响应的超时时间被设置为 30 秒。如果在这段时间内没有完成数据传输，Nginx 将会关闭连接。
根据上下文调整超时时间
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 send_timeout 的值：
http {
send_timeout 45s; # 全局设置为45秒
server {
listen 80;
server_name example.com;
location /fast-responses/ {
send_timeout 20s; # 特定位置设置为20秒
root /var/www/fast-responses;
}
location /slow-responses/ {
send_timeout 120s; # 特定位置设置为120秒
root /var/www/slow-responses;
}
}
}
在这个例子中：
- 全局配置下，默认发送超时时间为 45 秒。
- 对于
/fast-responses/路径下的请求，发送超时时间被设置为 20 秒。 - 对于
/slow-responses/路径下的请求，发送超时时间被设置为 120 秒。
结合其他相关配置项
为了进一步优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 send_timeout：
server {
listen 80;
server_name example.com;
send_timeout 60s; # 设置发送超时时间为60秒
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
client_header_timeout 60s; # 设置读取请求头超时时间为60秒
keepalive_timeout 60s; # 设置长连接超时时间为60秒
location /static/ {
root /var/www/static;
sendfile on; # 启用sendfile以优化文件传输
tcp_nopush on; # 启用TCP_NOPUSH选项，优化大文件传输
gzip on; # 启用Gzip压缩
gzip_min_length 1000; # 只压缩大于1000字节的响应
}
location /dynamic/ {
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
send_timeout 90s; # 设置发送超时时间为90秒
}
}
在这个例子中：
- 设置了
send_timeout为 60 秒，确保在开始发送响应之前有足够的时间进行数据传输。 - 设置了读取请求体、请求头和长连接的超时时间，均为 60 秒，确保长时间没有活动的连接能及时关闭，释放资源。
- 对于
/static/路径下的请求：- 启用了
sendfile和tcp_nopush来优化大文件传输。 - 启用了 Gzip 压缩，并设置了最小压缩长度为 1000 字节。
- 启用了
- 对于
/dynamic/路径下的请求：- 通过反向代理转发请求到后端服务器，并设置了代理连接和读取响应的超时时间，均为 60 秒。
- 设置了
send_timeout为 90 秒，允许更长的响应发送时间。
注意事项
- 超时设置：合理设置
send_timeout可以防止长时间未完成的数据传输占用服务器资源，特别是在处理大文件或慢速网络环境时尤为重要。过短的超时时间可能导致正常但较慢的连接被错误关闭，而过长的超时时间可能导致资源浪费。 - 性能与资源平衡：虽然较长的超时时间可以减少因网络延迟导致的连接中断，但也可能导致更多的空闲连接占用服务器资源。应根据实际应用场景和服务器负载情况进行调整。
- 用户体验：确保合理的超时设置不会影响用户体验。例如，在处理大文件下载或视频流等场景时，适当增加超时时间可以避免不必要的中断。
- 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的超时错误，可以通过日志分析找到问题根源。
sendfile
sendfile 指令用于启用或禁用Nginx使用操作系统内核提供的 sendfile() 系统调用来传输文件。sendfile() 可以减少数据在用户空间和内核空间之间的拷贝次数，从而提高大文件传输的效率。默认情况下，该选项是关闭的。
Syntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location
on：启用sendfile()功能。off：禁用sendfile()功能。
案例
基本用法
最简单的 sendfile 用法是指定一个开关状态：
server {
listen 80;
server_name example.com;
# 启用 sendfile 功能
sendfile on;
location /downloads/ {
root /var/www/downloads;
}
}
在这个例子中：
- 设置了
sendfile on，这意味着Nginx将使用sendfile()系统调用来传输/downloads/路径下的文件，从而提高大文件传输的性能。
禁用 sendfile 功能
你可以根据需要禁用 sendfile 功能：
server {
listen 80;
server_name example.com;
# 禁用 sendfile 功能
sendfile off;
location /static/ {
root /var/www/static;
}
}
在这个例子中：
- 设置了
sendfile off，这意味着Nginx不会使用sendfile()系统调用来传输文件，而是采用传统的数据拷贝方式。
结合其他配置
你可以结合其他配置指令，以满足不同的需求：
server {
listen 80;
server_name example.com;
# 启用 sendfile 和 tcp_nopush
sendfile on;
tcp_nopush on;
location /videos/ {
root /var/www/videos;
}
location /images/ {
# 禁用 sendfile 和 tcp_nopush
sendfile off;
tcp_nopush off;
root /var/www/images;
}
}
在这个例子中：
-
结合了
sendfile和tcp_nopush指令，确保在处理视频文件传输时，尽可能高效地利用系统资源，减少不必要的I/O和网络开销。 -
对于图片文件，禁用了
sendfile和tcp_nopush，因为这些文件较小且频繁访问，传统的传输方式可能更合适。 -
调试和监控：如果你遇到文件传输性能问题，可以考虑调整
sendfile的值，并结合日志进行进一步分析。同时，可以使用工具（如iftop或nload）监控网络流量。 -
兼容性：某些操作系统或文件系统可能不完全支持
sendfile()，在这种情况下，禁用sendfile是必要的。可以通过查看Nginx错误日志确认是否有与此相关的警告或错误信息。
注意事项
- 性能优化：启用
sendfile可以显著提高大文件传输的性能，特别是在高负载环境中。通过减少数据在用户空间和内核空间之间的拷贝次数，可以降低CPU使用率并提高传输速度。 - 适用场景：
sendfile特别适用于大文件传输场景，如视频流、大文件下载等。对于小文件或频繁访问的静态资源，sendfile的效果可能不明显，甚至可能带来额外的开销。 - 结合其他指令：通常与
tcp_nopush和tcp_nodelay结合
sendfile_max_chunk
sendfile_max_chunk 指令用于控制在使用 sendfile 机制传输文件时，每次传输的最大数据块大小。这有助于优化大文件传输的性能，并防止单次传输的数据量过大导致系统资源耗尽或其他问题。
Syntax: sendfile_max_chunk size;
Default: sendfile_max_chunk 2m;
Context: http, server, location
size：指定每次传输的最大数据块大小。可以使用字节（B）、KB（K）、MB（M）、GB（G）等单位。例如，2m表示2 MB，默认值为2 MB。
案例
基本用法
最简单的sendfile_max_chunk用法是指定每次传输的最大数据块大小：
server {
listen 80;
server_name example.com;
sendfile_max_chunk 2m; # 设置每次传输的最大数据块大小为2MB（默认值）
}
在这个例子中，当使用 sendfile 机制传输文件时，Nginx每次最多传输2 MB的数据块。
结合其他配置
结合其他相关指令使用sendfile_max_chunk来优化文件传输机制：
http {
include mime.types;
default_type application/octet-stream;
# 启用打开文件缓存，并设置最大缓存数量和不活跃时间
open_file_cache max=1000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
# 设置全局默认的sendfile_max_chunk大小
sendfile_max_chunk 2m;
log_format custom '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log custom;
server {
listen 80;
server_name public.example.com;
location /small-files/ {
root /var/www/public;
sendfile_max_chunk 1m; # 对于/small-files/路径下的请求，每次传输的最大数据块大小为1MB
expires 7d; # 设置静态资源的缓存时间为7天
}
location /large-files/ {
root /var/www/public;
sendfile_max_chunk 4m; # 对于/large-files/路径下的请求，每次传输的最大数据块大小为4MB
limit_rate_after 1m; # 在传输了1MB数据之后开始限制传输速率
limit_rate 50k; # 限制传输速率为50KB/s
}
}
server {
listen 80;
server_name secure.example.com;
root /var/www/secure;
sendfile_max_chunk 8m; # 对于secure.example.com，每次传输的最大数据块大小为8MB
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
error_page 404 = @custom_404;
location @custom_404 {
rewrite ^ /custom_404.html break;
root /usr/share/nginx/html;
}
error_log /var/log/nginx/error.log warn;
}
}
在这个完整示例中，我们不仅设置了不同路径和服务器块的sendfile_max_chunk配置，还结合了其他相关指令（如open_file_cache、expires、limit_rate_after和limit_rate），以进一步优化文件传输的性能，并提升系统的整体性能和健壮性。
具体解释一下各个部分的作用：
sendfile_max_chunk：设置每次传输的最大数据块大小。对于public.example.com的/small-files/路径，每次传输的最大数据块大小为1 MB；对于/large-files/路径，每次传输的最大数据块大小为4 MB；对于secure.example.com，每次传输的最大数据块大小为8 MB。expires：设置静态资源的缓存时间。对于/small-files/路径下的请求，静态资源会被客户端缓存7天，从而减少重复请求的次数。limit_rate_after和limit_rate：结合这两个指令可以控制文件传输速率。例如，在/large-files/路径下，文件传输在传输了1 MB数据之后开始限制传输速率为50 KB/s。error_page：定义自定义错误页面。例如，error_page 404 = @custom_404;表示当发生404错误时，跳转到名为@custom_404的命名位置处理。internal：确保自定义错误页面仅在内部调用时生效，防止用户直接访问这些页面。
注意事项
-
性能优化：合理设置
sendfile_max_chunk值可以平衡传输效率和系统资源占用。较小的数据块大小可以减少单次传输对系统资源的占用，但可能会增加传输次数；较大的数据块大小可以减少传输次数，但可能会占用较多的内存和CPU资源。 -
带宽管理：结合其他相关指令（如
limit_rate），可以更好地控制文件传输速率，避免大文件传输占用过多带宽，影响其他服务的正常运行。 -
日志记录：启用适当的日志记录可以帮助你监控和调试与文件传输相关的性能问题。你可以通过Nginx的日志配置记录传输速率和数据块大小，以便快速定位和解决问题。
server
server 块用于定义一个虚拟服务器（也称为虚拟主机），它包含处理特定域名或 IP 地址请求的所有配置。每个 server 块通常对应一个独立的站点或应用。Nginx 可以配置多个 server 块来处理不同的域名或端口。
Syntax: server { ... }
Default: —
Context: http
server { ... }：定义一个虚拟服务器，并在大括号{}内部包含具体的配置指令。- 包含的指令可以有监听端口、服务器名称、位置块等。
案例
基本用法
最简单的 server 块用法是指定监听端口和服务器名称：
http {
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
}
}
在这个例子中：
- Nginx 将监听 80 端口，并处理来自
example.com的请求。 - 请求
/路径时，Nginx 将从/var/www/html目录中查找并返回index.html文件。
多个
server块
你可以配置多个 server 块来处理不同的域名或端口：
http {
server {
listen 80;
server_name example1.com;
location / {
root /var/www/example1;
index index.html;
}
}
server {
listen 80;
server_name example2.com;
location / {
root /var/www/example2;
index index.html;
}
}
}
在这个例子中：
- 第一个
server块处理来自example1.com的请求，文档根目录为/var/www/example1。 - 第二个
server块处理来自example2.com的请求，文档根目录为/var/www/example2。
使用 SSL/TLS 配置 HTTPS
为了支持 HTTPS，你需要配置 SSL/TLS 证书和密钥：
http {
server {
listen 443 ssl;
server_name secure.example.com;
ssl_certificate /etc/nginx/ssl/secure.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/secure.example.com.key;
location / {
root /var/www/secure;
index index.html;
}
}
}
在这个例子中：
- Nginx 将监听 443 端口，并处理来自
secure.example.com的 HTTPS 请求。 ssl_certificate和ssl_certificate_key指令指定了 SSL 证书和密钥文件的位置。
使用默认服务器
你可以定义一个默认服务器来处理未匹配任何其他 server 块的请求：
http {
server {
listen 80 default_server;
server_name _;
return 444; # 返回一个非标准的关闭连接响应
}
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
}
}
在这个例子中：
- 第一个
server块作为默认服务器，处理所有未匹配到其他server块的请求，并返回 444 状态码（非标准状态码，表示关闭连接）。 - 第二个
server块处理来自example.com的请求。
注意事项
-
监听端口：确保正确配置
listen指令以监听所需的端口。对于 HTTP，通常是 80 端口；对于 HTTPS，则是 443 端口。 -
服务器名称：使用
server_name指令指定服务器名称，可以是一个具体的域名、通配符域名（如*.example.com），或者_表示默认服务器。 -
SSL 配置：如果需要支持 HTTPS，务必正确配置 SSL 证书和密钥文件路径。同时，建议使用强加密套件和协议版本，以确保安全性。
-
性能与安全：通过合理配置
server块中的各个指令，可以在性能和安全性之间找到平衡点。例如，使用缓存、压缩、限速等功能来优化性能，同时启用 SSL/TLS 来增强安全性。
server_name
server_name 指令在Nginx中用于定义虚拟主机的名称，即服务器块（server 块）将响应哪些域名或IP地址的请求。通过设置 server_name，您可以配置多个虚拟主机以服务于不同的域名，从而在一个物理服务器上托管多个网站。
Syntax: server_name name ...;
Default: server_name "";
Context: server
name：可以是具体的域名、通配符域名（如*.example.com或example.*），或者正则表达式（以~开头）。可以指定多个名称，用空格分隔。
案例
基本用法
最简单的 server_name 使用方法是指定一个具体的域名：
server {
listen 80;
server_name example.com; # 只响应example.com的请求
location / {
root /var/www/example;
index index.html;
}
}
在这个例子中，Nginx只会处理对 example.com 的请求。
支持多个域名
您可以为同一个虚拟主机配置多个域名：
server {
listen 80;
server_name example.com www.example.com; # 响应example.com和www.example.com的请求
location / {
root /var/www/example;
index index.html;
}
}
在这个例子中，Nginx会处理对 example.com 和 www.example.com 的请求。
使用通配符
使用通配符可以更灵活地匹配域名：
server {
listen 80;
server_name *.example.com; # 响应所有子域名的请求
location / {
root /var/www/example;
index index.html;
}
}
在这个例子中，Nginx会处理对 example.com 的所有子域名（如 blog.example.com 或 shop.example.com）的请求。
使用正则表达式
您还可以使用正则表达式来匹配域名：
server {
listen 80;
server_name ~^(?<subdomain>.+)\.example\.com$; # 使用正则表达式匹配并捕获子域名
location / {
root /var/www/$subdomain; # 根据子域名动态设置根目录
index index.html;
}
}
在这个例子中，Nginx会根据正则表达式匹配并捕获子域名，并动态设置根目录。
默认服务器
如果您希望某个虚拟主机成为默认服务器（即处理未匹配任何其他 server_name 的请求），可以使用空字符串或 _：
server {
listen 80 default_server;
server_name ""; # 或者使用 "_"
location / {
return 444; # 返回一个非标准状态码，关闭连接
}
}
在这个例子中，如果请求的域名不匹配任何其他虚拟主机的 server_name，则返回状态码 444 并关闭连接。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 server_name：
http {
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com www.example.com; # 响应example.com和www.example.com的请求
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /static {
alias /var/www/static;
}
}
server {
listen 80;
server_name api.example.com; # 响应api.example.com的请求
location / {
proxy_pass http://backend_api;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
server {
listen 80 default_server;
server_name ""; # 默认服务器，处理未匹配的请求
location / {
return 404; # 返回404错误
}
}
}
在这个例子中：
- 第一个
server块处理对example.com和www.example.com的请求，并代理到后台服务器。 - 第二个
server块处理对api.example.com的请求，并代理到后台API服务器。 - 第三个
server块作为默认服务器，处理未匹配任何其他server_name的请求，并返回404错误。
注意事项
- 精确匹配优先：Nginx会首先尝试精确匹配
server_name，然后才会考虑通配符和正则表达式。因此，建议尽量使用精确匹配。 - 性能优化：过多的通配符和正则表达式匹配可能会影响性能。请根据实际需求合理配置。
- 调试与监控：定期检查访问日志和错误日志，确保关键问题能够被及时发现和处理。特别是在调整虚拟主机配置时，务必进行充分测试。
- 安全性：确保每个虚拟主机的配置都符合安全要求，避免不必要的开放端口或路径暴露。
server_name_in_redirect
server_name_in_redirect 指令在 Nginx 中用于控制在生成重定向 URL 时是否使用 server_name 配置的值。当启用此指令时，Nginx 将在重定向响应中使用 server_name 中定义的主机名，而不是请求头中的主机名。这对于确保重定向 URL 使用正确的域名非常有用，尤其是在服务器配置了多个主机名或使用了反向代理的情况下。
Syntax: server_name_in_redirect on | off;
Default: server_name_in_redirect off;
Context: http, server, location
on：启用该功能，Nginx 在生成重定向 URL 时将使用server_name中定义的主机名。off：禁用该功能，Nginx 在生成重定向 URL 时将使用请求头中的主机名（默认行为）。
案例
基本用法
最简单的 server_name_in_redirect 用法是指定是否启用该功能：
server {
listen 80;
server_name example.com www.example.com;
server_name_in_redirect on; # 启用 server_name_in_redirect
location /old-page {
return 301 /new-page; # 重定向到新的页面
}
}
在这个例子中：
- 启用了
server_name_in_redirect，这意味着在生成重定向 URL 时，Nginx 将使用server_name中定义的主机名（例如example.com或www.example.com），而不是请求头中的主机名。
禁用
server_name_in_redirect
如果你希望在生成重定向 URL 时使用请求头中的主机名，可以将其设置为 off：
server {
listen 80;
server_name example.com www.example.com;
server_name_in_redirect off; # 禁用 server_name_in_redirect
location /old-page {
return 301 /new-page; # 重定向到新的页面
}
}
在这个例子中：
- 禁用了
server_name_in_redirect，这意味着在生成重定向 URL 时，Nginx 将使用请求头中的主机名。
根据上下文调整配置
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 server_name_in_redirect 的值：
http {
server_name_in_redirect on; # 全局启用 server_name_in_redirect
server {
listen 80;
server_name example.com;
location /redirect-example {
return 301 /new-page; # 重定向到新的页面
}
location /proxy-example {
proxy_pass http://backend.example.com;
server_name_in_redirect off; # 特定位置禁用 server_name_in_redirect
}
}
server {
listen 80;
server_name www.example.com;
location / {
root /var/www/html;
index index.html index.htm;
}
}
}
在这个例子中：
- 全局配置下，默认启用了
server_name_in_redirect。 - 对于
/redirect-example路径下的请求，重定向 URL 将使用server_name中定义的主机名（即example.com）。 - 对于
/proxy-example路径下的请求，禁用了server_name_in_redirect，因此重定向 URL 将使用请求头中的主机名。
结合其他相关配置项
为了进一步优化你的服务器配置和资源管理，可以结合其他相关配置项一起使用 server_name_in_redirect：
server {
listen 80;
server_name example.com www.example.com;
server_name_in_redirect on; # 启用 server_name_in_redirect
location / {
root /var/www/html;
index index.html index.htm;
}
location /redirects/ {
server_name_in_redirect off; # 特定位置禁用 server_name_in_redirect
return 301 /new-location; # 重定向到新的位置
}
location /proxied-content/ {
proxy_pass http://backend.example.com;
proxy_set_header Host $host; # 设置正确的主机头
proxy_set_header X-Real-IP $remote_addr; # 设置真实的客户端IP地址
}
}
在这个例子中：
- 启用了
server_name_in_redirect，意味着在大多数情况下，重定向 URL 将使用server_name中定义的主机名。 - 对于
/redirects/路径下的请求，禁用了server_name_in_redirect，因此重定向 URL 将使用请求头中的主机名。 - 对于
/proxied-content/路径下的请求，通过反向代理转发请求到后端服务器，并设置了正确的主机头和客户端 IP 地址。
注意事项
- 一致性：确保在使用
server_name_in_redirect时，所有相关的主机名和重定向规则保持一致。这有助于避免因主机名不匹配导致的问题。 - SEO 影响：在某些情况下，使用不同的主机名进行重定向可能会影响搜索引擎优化（SEO）。确保你使用的主机名是首选的并且符合 SEO 最佳实践。
- 安全性：合理配置
server_name_in_redirect可以防止潜在的安全问题，如开放重定向漏洞。确保只有可信的主机名被用于重定向。 - 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的重定向错误，可以通过日志分析找到问题根源。
server_names_hash_bucket_size
server_names_hash_bucket_size 指令用于设置服务器名称（即虚拟主机名）哈希表的桶大小。这个指令影响Nginx如何存储和查找虚拟主机名。默认情况下，Nginx会根据平台自动选择一个合适的值（通常是32、64或128字节），但你可以手动指定一个大小以优化性能。
Syntax: server_names_hash_bucket_size size;
Default: server_names_hash_bucket_size 32|64|128;
Context: http
size：指定哈希表桶的大小，单位为字节。常见的值包括32、64和128。
案例
基本用法
最简单的 server_names_hash_bucket_size 用法是指定一个桶大小：
http {
# 设置服务器名称哈希表的桶大小为64字节
server_names_hash_bucket_size 64;
server {
listen 80;
server_name example.com;
}
server {
listen 80;
server_name another-example.com;
}
}
在这个例子中：
- 设置了
server_names_hash_bucket_size 64，这意味着Nginx将使用64字节作为服务器名称哈希表的桶大小。
结合其他配置
在某些高负载环境下，可能需要调整桶大小以优化性能：
http {
# 设置较大的桶大小和最大哈希表大小
server_names_hash_bucket_size 128;
server_names_hash_max_size 2048;
server {
listen 80;
server_name example.com;
}
server {
listen 80;
server_name another-example.com;
}
# 更多的虚拟主机定义...
}
在这个例子中：
-
结合了
server_names_hash_bucket_size和server_names_hash_max_size指令，确保在处理大量虚拟主机时，哈希表的性能得到优化。 -
调试和监控：如果你遇到启动Nginx时出现“could not build the server_names_hash”的错误信息，可能是因为默认的桶大小不足以容纳所有的虚拟主机名。在这种情况下，可以尝试增加
server_names_hash_bucket_size的值，并重新启动Nginx进行测试。 -
内存占用：较大的桶大小会增加内存占用。因此，建议根据实际需求和系统资源情况来调整该值。可以通过观察系统内存使用情况和Nginx的性能表现来进行优化。
注意事项
- 性能优化：合理设置
server_names_hash_bucket_size可以减少哈希冲突，提高查找效率。如果桶大小过小，可能会导致哈希冲突增加，从而降低性能；如果桶大小过大，则可能导致内存浪费。 - 适用场景：对于拥有大量虚拟主机的Nginx实例，适当增大桶大小可以有效减少哈希冲突，提升性能。然而，在虚拟主机数量较少的情况下，使用默认值通常已经足够。
- 结合其他指令：通常与
server_names_hash_max_size结合使用，以进一步优化服务器名称哈希表的性能。
server_names_hash_max_size
server_names_hash_max_size 指令用于控制Nginx在内存中存储服务器名称（即虚拟主机名）的哈希表的最大大小。这个指令影响Nginx如何处理和存储虚拟主机配置中的域名，从而优化查找效率。如果设置得太小，可能会导致哈希冲突增加，进而降低性能。
Syntax: server_names_hash_max_size size;
Default: server_names_hash_max_size 512;
Context: http
size：指定哈希表的最大大小。默认值为512。较大的值可以减少哈希冲突，但会占用更多的内存。
案例
基本用法
最简单的server_names_hash_max_size用法是指定哈希表的最大大小：
http {
include mime.types;
default_type application/octet-stream;
server_names_hash_max_size 512; # 设置哈希表的最大大小为512（默认值）
}
在这个例子中，Nginx使用默认的哈希表最大大小512来存储服务器名称。
调整
server_names_hash_max_size
根据需要调整server_names_hash_max_size的值：
http {
include mime.types;
default_type application/octet-stream;
# 增加哈希表的最大大小以适应更多的服务器名称
server_names_hash_max_size 1024;
server {
listen 80;
server_name example1.com;
root /var/www/example1;
}
server {
listen 80;
server_name example2.com;
root /var/www/example2;
}
server {
listen 80;
server_name example3.com;
root /var/www/example3;
}
# 更多的server块...
}
在这个例子中，我们将server_names_hash_max_size设置为1024，以适应更多的服务器名称，减少哈希冲突的可能性。
注意事项
-
哈希冲突：如果哈希表的最大大小设置得太小，当服务器名称数量较多时，可能会导致哈希冲突增加，进而影响查找效率。在这种情况下，Nginx可能会发出警告或错误信息，提示你调整哈希表的最大大小。
-
内存占用：较大的哈希表最大大小会占用更多的内存。因此，在调整此参数时，需要权衡性能与资源消耗之间的关系，尤其是在内存有限的环境中。
-
日志记录：启用适当的日志记录可以帮助你监控和调试与哈希表相关的性能问题。你可以通过Nginx的日志配置记录相关事件，以便快速定位和解决问题。
server_tokens
server_tokens 指令在Nginx中用于控制是否在HTTP响应头中包含Nginx的版本号。通过调整这个设置，您可以增强服务器的安全性，避免不必要的信息泄露。
Syntax: server_tokens on | off | build | string;
Default: server_tokens on;
Context: http, server, location
on（默认）：在响应头中包含完整的Nginx版本号。off：不在响应头中包含Nginx版本号，仅显示Server: nginx。build：显示Nginx的构建信息（如果可用），而不是具体的版本号。string：允许自定义响应头中的Server字段内容。
案例
基本用法
最简单的 server_tokens 使用方法是指定一个适合您应用场景的选项：
server {
listen 80;
server_name example.com;
server_tokens off; # 不在响应头中包含Nginx版本号
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx不会在HTTP响应头中包含其版本号，只显示 Server: nginx。
显示Nginx版本号
如果您希望在响应头中显示Nginx的版本号（默认行为），可以使用 on：
server {
listen 80;
server_name example.com;
server_tokens on; # 在响应头中包含Nginx版本号
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在HTTP响应头中显示其版本号，例如 Server: nginx/1.21.3。
显示构建信息
如果您希望显示Nginx的构建信息而不是具体的版本号，可以使用 build：
server {
listen 80;
server_name example.com;
server_tokens build; # 显示Nginx的构建信息
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在HTTP响应头中显示其构建信息（如果可用）。
自定义响应头内容
您还可以自定义响应头中的 Server 字段内容：
server {
listen 80;
server_name example.com;
server_tokens "MyCustomServer"; # 自定义响应头中的Server字段内容
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会在HTTP响应头中显示 Server: MyCustomServer。
根据不同位置配置不同的设置
您可以根据不同的location块配置不同的 server_tokens 设置，以适应不同的需求：
server {
listen 80;
server_name example.com;
location /api {
proxy_pass http://backend-api;
server_tokens off; # 对于API请求，不在响应头中包含Nginx版本号
}
location /static {
root /var/www/static;
server_tokens on; # 对于静态文件请求，显示Nginx版本号
}
}
在这个例子中：
/api路径下的请求，不在响应头中包含Nginx版本号，并代理到后台API服务器。/static路径下的请求，显示Nginx版本号，并直接从静态文件目录提供服务。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 server_tokens：
http {
server_tokens off; # 全局禁用Nginx版本号显示
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /downloads {
alias /var/www/downloads;
server_tokens "SecureDownloads"; # 对于下载路径，自定义响应头中的Server字段内容
}
}
}
在这个例子中：
- 全局配置中禁用了Nginx版本号显示。
- 对于
/downloads路径，自定义响应头中的Server字段内容为SecureDownloads。
注意事项
- 安全性：关闭
server_tokens可以减少潜在的安全风险，因为攻击者无法轻易获取到服务器软件的具体版本号，从而难以针对特定版本的漏洞进行攻击。 - 调试与监控：虽然关闭
server_tokens提高了安全性，但在调试和故障排除时，有时需要查看Nginx的版本信息。在这种情况下，可以在开发或测试环境中启用该选项。 - 性能影响：禁用或修改
server_tokens的设置对性能几乎没有影响，因此可以根据实际需求自由调整。 - 兼容性：确保所有相关的应用和服务能够适应更改后的
Server头字段内容，特别是在生产环境中应用之前进行充分测试。
subrequest_output_buffer_size
subrequest_output_buffer_size 指令用于设置子请求输出缓冲区的大小。子请求是指在一个主请求处理过程中由 Nginx 内部生成的额外请求（例如通过 include、rewrite 或 proxy_pass 等指令触发的请求）。该指令控制了这些子请求的输出缓冲区大小。
Syntax: subrequest_output_buffer_size size;
Default: subrequest_output_buffer_size 4k|8k;
Context: http, server, location
This directive appeared in version 1.13.10.
size：指定子请求输出缓冲区的大小。通常以字节为单位（如4k表示 4KB），默认值是 4KB 或 8KB，具体取决于平台。
案例
基本用法
最简单的 subrequest_output_buffer_size 用法是指定子请求输出缓冲区的大小：
server {
listen 80;
server_name example.com;
# 设置子请求输出缓冲区大小为 8KB
subrequest_output_buffer_size 8k;
location /main {
# 主请求处理逻辑
root /var/www/html;
# 使用子请求加载其他资源
include /etc/nginx/snippets/subrequest.conf;
}
}
在这个例子中：
- Nginx 将使用 8KB 的缓冲区来存储子请求的输出数据。
在特定的
location块中设置不同的缓冲区大小
你可以根据需要为每个 location 块设置不同的 subrequest_output_buffer_size 配置：
server {
listen 80;
server_name example.com;
location /small-output {
# 设置较小的子请求输出缓冲区大小
subrequest_output_buffer_size 4k;
# 主请求处理逻辑
root /var/www/small-output;
# 使用子请求加载其他资源
include /etc/nginx/snippets/subrequest-small.conf;
}
location /large-output {
# 设置较大的子请求输出缓冲区大小
subrequest_output_buffer_size 16k;
# 主请求处理逻辑
proxy_pass http://backend_server;
}
}
在这个例子中：
- 访问
/small-output时，Nginx 将使用 4KB 的缓冲区来存储子请求的输出数据。 - 访问
/large-output时，Nginx 将使用 16KB 的缓冲区来存储子请求的输出数据。
注意事项
-
性能优化：合理的缓冲区大小可以提高子请求的处理效率。较小的缓冲区可能导致频繁的 I/O 操作，增加系统开销；而过大的缓冲区则可能浪费内存资源。因此，应根据实际应用场景调整缓冲区大小。
-
内存管理：子请求输出缓冲区会占用服务器内存，尤其是在高并发场景下，多个子请求同时运行时，内存消耗可能会迅速增加。确保根据服务器的实际内存容量合理配置缓冲区大小。
-
调试与监控：在调试阶段，可以通过日志和监控工具观察子请求的性能表现，根据实际情况调整缓冲区大小。例如，如果发现子请求处理较慢或频繁发生 I/O 等待，可以尝试增加缓冲区大小。
-
版本兼容性：
subrequest_output_buffer_size指令从 Nginx 版本 1.13.10 开始引入。请确保您的 Nginx 版本支持该指令，否则配置将无效。
tcp_nodelay
tcp_nodelay 指令在 Nginx 中用于控制是否启用 TCP_NODELAY 选项，即 Nagle 算法。Nagle 算法通过减少小数据包的发送次数来优化网络流量，但它可能会导致延迟增加，特别是在需要快速传输小数据块的应用场景中。通过设置 tcp_nodelay on，可以禁用 Nagle 算法，从而确保数据能够尽快发送，减少延迟。
Syntax: tcp_nodelay on | off;
Default: tcp_nodelay on;
Context: http, server, location
on：禁用 Nagle 算法（默认行为），确保数据尽快发送。off：启用 Nagle 算法，减少小数据包的发送次数，但可能增加延迟。
案例
基本用法
最简单的 tcp_nodelay 用法是指定是否启用该功能：
server {
listen 80;
server_name example.com;
tcp_nodelay on; # 启用 tcp_nodelay，禁用 Nagle 算法
location / {
root /var/www/html;
index index.html index.htm;
}
}
在这个例子中：
- 启用了
tcp_nodelay，这意味着禁用了 Nagle 算法，确保数据能够尽快发送，减少延迟。
禁用
tcp_nodelay
如果你希望启用 Nagle 算法以减少小数据包的发送次数，可以将其设置为 off：
server {
listen 80;
server_name example.com;
tcp_nodelay off; # 禁用 tcp_nodelay，启用 Nagle 算法
location / {
root /var/www/html;
index index.html index.htm;
}
}
在这个例子中：
- 禁用了
tcp_nodelay，这意味着启用了 Nagle 算法，减少小数据包的发送次数，但可能增加延迟。
根据上下文调整配置
你可以根据不同的上下文（如 http, server, 或 location）灵活地调整 tcp_nodelay 的值：
http {
tcp_nodelay on; # 全局启用 tcp_nodelay
server {
listen 80;
server_name example.com;
location /interactive/ {
tcp_nodelay off; # 特定位置禁用 tcp_nodelay，启用 Nagle 算法
proxy_pass http://backend.interactive.com;
}
location /streaming/ {
tcp_nodelay on; # 特定位置启用 tcp_nodelay，禁用 Nagle 算法
proxy_pass http://backend.streaming.com;
}
}
server {
listen 80;
server_name www.example.com;
location / {
root /var/www/html;
index index.html index.htm;
}
}
}
在这个例子中：
- 全局配置下，默认启用了
tcp_nodelay。 - 对于
/interactive/路径下的请求，禁用了tcp_nodelay，这意味着启用了 Nagle 算法，减少小数据包的发送次数。 - 对于
/streaming/路径下的请求，启用了tcp_nodelay，这意味着禁用了 Nagle 算法，确保数据能够尽快发送，减少延迟。
结合其他相关配置项
为了进一步优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 tcp_nodelay：
server {
listen 80;
server_name example.com;
tcp_nodelay on; # 启用 tcp_nodelay，禁用 Nagle 算法
sendfile on; # 启用 sendfile 以优化文件传输
tcp_nopush on; # 启用 TCP_NOPUSH 选项，优化大文件传输
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
client_header_timeout 60s; # 设置读取请求头超时时间为60秒
location /static/ {
root /var/www/static;
gzip on; # 启用 Gzip 压缩
gzip_min_length 1000; # 只压缩大于1000字节的响应
}
location /dynamic/ {
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
tcp_nodelay off; # 特定位置禁用 tcp_nodelay，启用 Nagle 算法
}
}
在这个例子中：
- 启用了
tcp_nodelay，确保数据能够尽快发送，减少延迟。 - 启用了
sendfile和tcp_nopush来优化大文件传输。 - 设置了读取请求体和请求头的超时时间，确保长时间没有活动的连接能及时关闭，释放资源。
- 对于
/static/路径下的请求，启用了 Gzip 压缩，并设置了最小压缩长度为 1000 字节。 - 对于
/dynamic/路径下的请求，禁用了tcp_nodelay，这意味着启用了 Nagle 算法，减少小数据包的发送次数。
注意事项
- 延迟与吞吐量平衡：合理设置
tcp_nodelay可以在延迟和吞吐量之间找到平衡。对于需要低延迟的应用（如实时通信、游戏等），建议启用tcp_nodelay。而对于需要高吞吐量的应用（如大数据传输），可以考虑启用 Nagle 算法。 - 应用场景：在处理大量小数据包或需要实时响应的场景中，启用
tcp_nodelay可以显著减少延迟。但在传输大文件或批量数据时，启用 Nagle 算法可以减少网络拥塞和提高整体传输效率。 - 兼容性：确保客户端和中间设备（如代理服务器、CDN等）支持并正确处理你所设置的 TCP 配置。某些旧客户端或中间设备可能不完全支持这些优化策略。
- 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的延迟问题，可以通过日志分析找到问题根源。
tcp_nopush
tcp_nopush 指令用于控制Nginx是否使用TCP_CORK选项来优化数据包的发送。启用该选项可以确保在发送大文件时，数据不会被立即发送，而是等待更多的数据累积在一起，以减少网络传输中的小数据包数量，从而提高传输效率。默认情况下，该选项是关闭的。
Syntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location
on：启用TCP_CORK选项，延迟发送数据直到有足够的数据填充一个完整的TCP包。off：禁用TCP_CORK选项，允许数据立即发送。
案例
基本用法
最简单的 tcp_nopush 用法是指定一个开关状态：
server {
listen 80;
server_name example.com;
# 启用 tcp_nopush 功能
tcp_nopush on;
location /downloads/ {
root /var/www/downloads;
}
}
在这个例子中：
- 设置了
tcp_nopush on，这意味着Nginx将使用TCP_CORK选项，在发送/downloads/路径下的文件时，会等待更多的数据累积在一起再发送，从而减少小数据包的数量。
禁用 tcp_nopush 功能
你可以根据需要禁用 tcp_nopush 功能：
server {
listen 80;
server_name example.com;
# 禁用 tcp_nopush 功能
tcp_nopush off;
location /static/ {
root /var/www/static;
}
}
在这个例子中：
- 设置了
tcp_nopush off，这意味着Nginx不会使用TCP_CORK选项，数据会被立即发送，适用于对实时性要求较高的场景。
在多个上下文中设置不同的状态
你可以在不同的上下文中设置不同的状态，以满足不同的需求：
http {
# 全局禁用 tcp_nopush 功能
tcp_nopush off;
server {
listen 80;
server_name example.com;
# 特定服务器块启用 tcp_nopush 功能
tcp_nopush on;
location /videos/ {
root /var/www/videos;
}
location /images/ {
# 继承全局设置（tcp_nopush off）
root /var/www/images;
}
}
server {
listen 80;
server_name another-example.com;
# 启用全局设置（tcp_nopush off）
location / {
root /var/www/another-html;
}
}
}
在这个例子中：
- 在全局
http块中设置了tcp_nopush off。 - 对于
example.com，将tcp_nopush设置为on。 - 对于
/images/路径，继承全局设置的off。 - 对于
another-example.com，使用全局设置的off。
注意事项
- 性能优化：启用
tcp_nopush可以显著提高大文件传输的性能，特别是在高负载环境中。通过减少小数据包的数量，可以降低网络开销并提高传输效率。 - 适用场景：
tcp_nopush特别适用于大文件传输场景，如视频流、大文件下载等。对于小文件或频繁访问的静态资源，tcp_nopush的效果可能不明显，甚至可能带来额外的延迟。 - 结合其他指令：通常与
sendfile和tcp_nodelay等指令结合使用，以实现更高效的文件传输策略。
try_files
try_files 指令用于按顺序检查指定的文件或目录是否存在，并根据第一个匹配项进行处理。如果所有指定的文件或目录都不存在，则可以重定向到指定的URI或返回特定的状态码。这个指令非常适用于处理静态文件和动态请求的混合场景。
Syntax: try_files file ... uri;
try_files file ... =code;
Default: —
Context: server, location
file ...：一系列文件路径或变量，Nginx会依次检查这些路径是否存在。uri：如果所有指定的文件或目录都不存在，则重定向到该URI。=code：如果所有指定的文件或目录都不存在，则返回指定的状态码（如404、500等）。
案例
基本用法
最简单的try_files用法是指定一系列文件路径并提供一个默认的URI：
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
try_files $uri $uri/ /index.html; # 首先查找请求的文件，然后查找目录，最后返回/index.html
}
}
在这个例子中，当用户访问example.com/somepage时，Nginx首先尝试查找/var/www/html/somepage，如果没有找到，则尝试查找/var/www/html/somepage/，如果仍然没有找到，则返回/var/www/html/index.html。
状态码
另一种常见的用法是返回特定的状态码：
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
try_files $uri $uri/ =404; # 如果找不到任何文件或目录，则返回404状态码
}
}
在这个例子中，如果找不到请求的文件或目录，Nginx将直接返回404状态码。
不同的
location配置
根据需要为不同的location块设置不同的try_files配置：
http {
include mime.types;
default_type application/octet-stream;
server {
listen 80;
server_name public.example.com;
location /static/ {
root /var/www/public;
try_files $uri $uri/ =404; # 对于/static/路径下的请求，找不到文件则返回404状态码
}
location /dynamic/ {
root /var/www/dynamic;
try_files $uri $uri/ /fallback.php?$query_string; # 对于/dynamic/路径下的请求，找不到文件则重定向到/fallback.php
}
}
server {
listen 80;
server_name secure.example.com;
root /var/www/secure;
try_files $uri $uri/ /custom_404.html; # 找不到文件则返回/custom_404.html页面
}
}
在这个例子中：
/static/路径下的请求，如果找不到文件则返回404状态码。/dynamic/路径下的请求，如果找不到文件则重定向到/fallback.php，并传递查询字符串。secure.example.com服务器块中，找不到文件则返回/custom_404.html页面。
注意事项
-
性能优化：合理使用
try_files可以简化配置并提高性能。尽量减少不必要的文件查找，避免复杂的嵌套逻辑。 -
安全性：确保
try_files指向的文件和目录具有适当的权限设置，防止未经授权的访问。特别是当涉及到动态脚本（如PHP）时，应采取额外的安全措施。 -
日志记录：启用适当的日志记录可以帮助你监控和调试文件查找相关的问题。你可以通过Nginx的日志配置记录文件查找失败的情况，以便快速定位和解决问题。
以下是一个更完整的示例，展示了如何结合其他相关指令使用try_files来优化静态文件和动态请求的处理机制，并提升系统的整体性能和健壮性：
http {
include mime.types;
default_type application/octet-stream;
# 启用打开文件缓存，并设置最大缓存数量和不活跃时间
open_file_cache max=1000 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
log_format custom '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log custom;
server {
listen 80;
server_name public.example.com;
location /static/ {
root /var/www/public;
try_files $uri $uri/ =404; # 对于/static/路径下的请求，找不到文件则返回404状态码
expires 7d; # 设置静态资源的缓存时间为7天
}
location /dynamic/ {
root /var/www/dynamic;
try_files $uri $uri/ /fallback.php?$query_string; # 对于/dynamic/路径下的请求，找不到文件则重定向到/fallback.php
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # 将请求转发给PHP-FPM处理
include fastcgi_params;
}
}
server {
listen 80;
server_name secure.example.com;
root /var/www/secure;
try_files $uri $uri/ /custom_404.html; # 找不到文件则返回/custom_404.html页面
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
error_page 404 = @custom_404;
location @custom_404 {
rewrite ^ /custom_404.html break;
root /usr/share/nginx/html;
}
error_log /var/log/nginx/error.log warn;
}
}
在这个完整示例中，我们不仅设置了不同路径的try_files配置，还结合了其他相关指令（如open_file_cache、expires、fastcgi_pass和error_page），以进一步优化静态文件和动态请求的处理效率，并提升系统的整体性能和健壮性。
具体解释一下各个部分的作用：
try_files：按顺序检查指定的文件或目录是否存在，并根据第一个匹配项进行处理。例如，在/static/路径下，找不到文件则返回404状态码；在/dynamic/路径下，找不到文件则重定向到/fallback.php。expires：设置静态资源的缓存时间。对于/static/路径下的请求，静态资源会被客户端缓存7天，从而减少重复请求的次数。fastcgi_pass：将请求转发给PHP-FPM处理。这使得Nginx可以处理动态PHP脚本。include fastcgi_params：包含FastCGI参数配置文件，确保PHP脚本能够正确接收请求参数。error_page：定义自定义错误页面。例如，error_page 404 = @custom_404;表示当发生404错误时，跳转到名为@custom_404的命名位置处理。internal：确保自定义错误页面仅在内部调用时生效，防止用户直接访问这些页面。
types
types 块在Nginx中用于定义MIME类型与文件扩展名之间的映射关系。通过配置 types，您可以指定当客户端请求特定类型的文件时，服务器应返回的正确MIME类型。这有助于确保浏览器和其他客户端能够正确解析和显示内容。
Syntax: types { ... }
Default:
types {
text/html html;
image/gif gif;
image/jpeg jpg;
}
Context: http, server, location
text/html html;：表示.html文件的MIME类型是text/html。image/gif gif;：表示.gif文件的MIME类型是image/gif。image/jpeg jpg;：表示.jpg文件的MIME类型是image/jpeg。
案例
基本用法
最简单的 types 使用方法是指定一个适合您应用场景的MIME类型和文件扩展名映射：
server {
listen 80;
server_name example.com;
types {
text/html html;
image/gif gif;
image/jpeg jpg;
}
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx会根据文件扩展名设置相应的 Content-Type 响应头。
扩展默认的MIME类型映射
如果您需要添加更多的MIME类型映射，可以在现有的基础上进行扩展：
server {
listen 80;
server_name example.com;
types {
text/html html;
image/gif gif;
image/jpeg jpg;
application/pdf pdf; # 添加PDF文件的MIME类型映射
application/json json; # 添加JSON文件的MIME类型映射
}
location / {
root /var/www/html;
index index.html;
}
}
在这个例子中，Nginx不仅处理HTML、GIF和JPEG文件，还会处理PDF和JSON文件，并为其设置正确的MIME类型。
覆盖默认的MIME类型映射
如果您希望覆盖某些默认的MIME类型映射，可以重新定义它们：
server {
listen 80;
server_name example.com;
types {
text/plain html; # 将HTML文件的MIME类型改为text/plain
image/png gif; # 将GIF文件的MIME类型改为image/png
}
location / {
root /var/www/html;
index index.html;
}
}
请注意，这种做法不常见且通常不推荐，因为它可能导致客户端无法正确解析文件。
根据不同位置配置不同的MIME类型映射
您可以根据不同的location块配置不同的MIME类型映射，以适应不同的需求：
server {
listen 80;
server_name example.com;
location /static {
alias /var/www/static;
types {
text/html html;
image/gif gif;
image/jpeg jpg;
}
}
location /downloads {
alias /var/www/downloads;
types {
application/octet-stream *; # 对于下载路径，所有文件都作为二进制流处理
}
}
}
在这个例子中：
/static路径下的请求，使用标准的MIME类型映射。/downloads路径下的请求，所有文件都作为二进制流处理（application/octet-stream），以便用户下载而不是直接在浏览器中打开。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 types：
http {
include mime.types; # 包含默认的MIME类型映射文件
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
location /api {
proxy_pass http://backend-api;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /custom-mime {
alias /var/www/custom-mime;
types {
application/vnd.api+json json; # 自定义JSON API的MIME类型
application/xml xml; # 添加XML文件的MIME类型映射
}
}
}
}
在这个例子中：
- 全局配置中包含了默认的MIME类型映射文件（通常是
mime.types）。 /custom-mime路径下的请求，自定义了一些特殊的MIME类型映射，如application/vnd.api+json和application/xml。
注意事项
- 兼容性：确保所有相关的应用和服务能够正确识别和处理您配置的MIME类型。特别是对于自定义的MIME类型，务必确认客户端支持并能正确处理。
- 性能优化：过多的MIME类型映射不会显著影响性能，但在大型配置文件中保持清晰和有序的映射有助于维护和调试。
- 调试与监控：定期检查访问日志和错误日志，确保关键问题能够被及时发现和处理。特别是在调整MIME类型映射时，务必进行充分测试。
- 安全性：避免不必要的MIME类型映射，防止潜在的安全风险。例如，不要将可执行文件的MIME类型设置为文本类型，以免导致意外执行。
types_hash_bucket_size
types_hash_bucket_size 指令用于设置 MIME 类型哈希表中每个桶（bucket）的大小。这个指令影响 Nginx 处理文件扩展名到 MIME 类型映射的效率。通过调整桶的大小，可以优化哈希表的性能和内存使用。
Syntax: types_hash_bucket_size size;
Default: types_hash_bucket_size 64;
Context: http, server, location
size：指定哈希表中每个桶的大小。通常以字节为单位，默认值是 64 字节。这个值可以根据系统的具体情况和性能需求进行调整。
案例
基本用法
最简单的 types_hash_bucket_size 用法是指定哈希表中每个桶的大小：
http {
types_hash_bucket_size 128;
types {
text/html html;
application/javascript js;
text/css css;
}
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
}
}
在这个例子中：
- Nginx 将使用 128 字节作为 MIME 类型哈希表中每个桶的大小。
在特定的
server或location块中设置不同的桶大小
虽然 types_hash_bucket_size 主要用于 http 上下文，但在某些高级配置场景中，你也可以在 server 或 location 块中覆盖它（尽管这并不常见）：
http {
types_hash_bucket_size 64;
server {
listen 80;
server_name example1.com;
# 覆盖全局设置，使用 128 字节的桶大小
types_hash_bucket_size 128;
location / {
root /var/www/example1;
index index.html;
}
}
server {
listen 80;
server_name example2.com;
location / {
root /var/www/example2;
index index.html;
}
}
}
在这个例子中：
- 对于
example1.com，Nginx 将使用 128 字节作为 MIME 类型哈希表中每个桶的大小。 - 对于
example2.com，Nginx 将使用默认的桶大小（64 字节）。
注意事项
-
性能优化：合理的桶大小可以提高哈希表查找的效率。较小的桶可能导致更多的冲突，增加查找时间；而过大的桶则可能浪费内存资源。因此，应根据实际应用场景调整桶大小。
-
内存管理：哈希表桶的大小直接影响内存消耗。较大的桶可能会导致更高的内存占用，尤其是在处理大量不同 MIME 类型的场景中。确保根据服务器的实际内存容量合理配置桶大小。
-
调试与监控：可以通过日志和监控工具观察哈希表的性能表现，根据实际情况调整桶大小。例如，如果发现频繁的哈希冲突或较高的内存占用，可以尝试调整桶大小。
-
系统依赖性：桶大小的选择还应考虑操作系统的内存页面大小和处理器架构。一般来说，选择一个与系统内存页面大小相匹配的桶大小可以获得更好的性能。
types_hash_max_size
types_hash_max_size 指令在 Nginx 中用于设置 MIME 类型哈希表的最大大小。这个哈希表用于存储和快速查找文件扩展名与 MIME 类型之间的映射关系。通过调整这个值，可以优化哈希表的性能，减少查找时间，尤其是在处理大量不同类型的文件时。
Syntax: types_hash_max_size size;
Default: types_hash_max_size 1024;
Context: http, server, location
size：指定哈希表的最大大小，默认值是1024。较大的哈希表可以减少冲突并提高查找效率，但也会占用更多的内存。
案例
基本用法
最简单的 types_hash_max_size 用法是指定一个适合你应用需求的哈希表大小：
http {
types_hash_max_size 2048; # 设置哈希表的最大大小为2048
include mime.types;
default_type application/octet-stream;
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html index.htm;
}
}
}
在这个例子中：
- 将
types_hash_max_size设置为2048，这比默认的1024更大，有助于减少哈希冲突，提高查找效率。
根据上下文调整配置
虽然 types_hash_max_size 主要在 http 块中使用，但在某些情况下，你可能希望根据不同的上下文（如 server 或 location）进行更细致的调整：
http {
types_hash_max_size 1024; # 全局设置为1024
server {
listen 80;
server_name example.com;
types_hash_max_size 2048; # 特定服务器块设置为2048
location /static/ {
root /var/www/static;
types_hash_max_size 4096; # 特定位置块设置为4096
}
location /dynamic/ {
proxy_pass http://backend;
}
}
server {
listen 80;
server_name www.example.com;
location / {
root /var/www/html;
index index.html index.htm;
}
}
}
在这个例子中：
- 全局配置下，默认
types_hash_max_size设置为1024。 - 对于
example.com的服务器块，将types_hash_max_size设置为2048。 - 对于
/static/路径下的请求，进一步将types_hash_max_size设置为4096，以应对更多种类的静态文件类型。
结合其他相关配置项
为了进一步优化你的服务器性能和资源管理，可以结合其他相关配置项一起使用 types_hash_max_size：
http {
types_hash_max_size 2048; # 设置哈希表的最大大小为2048
include mime.types; # 包含 MIME 类型定义文件
default_type application/octet-stream; # 设置默认的 MIME 类型
sendfile on; # 启用 sendfile 以优化文件传输
tcp_nopush on; # 启用 TCP_NOPUSH 选项，优化大文件传输
client_body_timeout 60s; # 设置读取请求体超时时间为60秒
client_header_timeout 60s; # 设置读取请求头超时时间为60秒
server {
listen 80;
server_name example.com;
location /static/ {
root /var/www/static;
gzip on; # 启用 Gzip 压缩
gzip_min_length 1000; # 只压缩大于1000字节的响应
types_hash_max_size 4096; # 设置哈希表的最大大小为4096
}
location /dynamic/ {
proxy_pass http://backend;
proxy_connect_timeout 60s; # 设置代理连接超时时间为60秒
proxy_read_timeout 60s; # 设置从代理服务器读取响应的超时时间为60秒
}
}
}
在这个例子中：
- 设置了
types_hash_max_size为2048，并在/static/路径下将其增加到4096，以应对更多种类的静态文件类型。 - 启用了
sendfile和tcp_nopush来优化大文件传输。 - 设置了读取请求体和请求头的超时时间，确保长时间没有活动的连接能及时关闭，释放资源。
- 对于
/static/路径下的请求，启用了 Gzip 压缩，并设置了最小压缩长度为 1000 字节。 - 对于
/dynamic/路径下的请求，通过反向代理转发请求到后端服务器，并设置了代理连接和读取响应的超时时间。
注意事项
- 哈希表大小的选择：合理设置
types_hash_max_size可以减少哈希冲突，提高查找效率。然而，过大的哈希表会占用更多的内存资源。应根据实际应用场景和服务器负载情况进行调整。 - 内存使用：较大的哈希表会增加内存占用，特别是在处理大量不同类型文件时。需要权衡性能和内存使用之间的平衡。
- 性能优化：对于大多数普通应用，默认的
1024大小通常已经足够。如果你的应用处理大量的不同文件类型（如多种格式的静态资源），可以适当增大哈希表大小以提高性能。 - 日志记录与监控：建议配置适当的访问日志和错误日志路径，便于后续的问题排查和性能监控。特别是对于频繁出现的 MIME 类型查找问题，可以通过日志分析找到问题根源。
underscores_in_headers
underscores_in_headers 指令用于控制是否允许HTTP请求头中包含下划线字符（_）。默认情况下，Nginx会忽略包含下划线的请求头字段，以避免与某些代理服务器或后端应用的兼容性问题。如果启用该选项，则允许请求头中包含下划线。
Syntax: underscores_in_headers on | off;
Default: underscores_in_headers off;
Context: http, server
on：允许HTTP请求头中包含下划线字符。off：禁止HTTP请求头中包含下划线字符（默认行为）。
案例
基本用法
最简单的 underscores_in_headers 用法是指定一个开关状态：
server {
listen 80;
server_name example.com;
# 启用 underscores_in_headers 功能
underscores_in_headers on;
location / {
proxy_pass http://backend.example.com;
}
}
在这个例子中：
- 设置了
underscores_in_headers on，这意味着Nginx将允许处理包含下划线的HTTP请求头字段。
禁用 underscores_in_headers 功能
你可以根据需要禁用 underscores_in_headers 功能：
server {
listen 80;
server_name example.com;
# 禁用 underscores_in_headers 功能
underscores_in_headers off;
location / {
proxy_pass http://backend.example.com;
}
}
在这个例子中：
- 设置了
underscores_in_headers off，这意味着Nginx将忽略包含下划线的HTTP请求头字段。
在多个上下文中设置不同的状态
你可以在不同的上下文中设置不同的状态，以满足不同的需求：
http {
# 全局禁用 underscores_in_headers 功能
underscores_in_headers off;
server {
listen 80;
server_name example.com;
# 特定服务器块启用 underscores_in_headers 功能
underscores_in_headers on;
location /api/ {
proxy_pass http://api-backend.example.com;
}
location /static/ {
# 继承全局设置（underscores_in_headers off）
root /var/www/static;
}
}
server {
listen 80;
server_name another-example.com;
# 启用全局设置（underscores_in_headers off）
location / {
proxy_pass http://another-backend.example.com;
}
}
}
在这个例子中：
- 在全局
http块中设置了underscores_in_headers off。 - 对于
example.com，将underscores_in_headers设置为on。 - 对于
/static/路径，继承全局设置的off。 - 对于
another-example.com，使用全局设置的off。
注意事项
-
兼容性：默认情况下，Nginx会忽略包含下划线的HTTP请求头字段，这是为了与某些代理服务器或后端应用保持兼容。例如，某些旧版本的Apache HTTP Server可能会将下划线视为非法字符并拒绝处理这些请求头字段。
-
安全性：在某些情况下，允许包含下划线的请求头字段可能会带来安全风险。例如，攻击者可以利用这种特性绕过某些安全检查或混淆请求头字段。因此，在启用
underscores_in_headers时，请确保对输入进行充分验证和过滤。 -
适用场景：如果你的应用程序依赖于包含下划线的请求头字段，并且确认不会引发兼容性或安全性问题，可以考虑启用
underscores_in_headers。否则，建议保持默认设置（off）。 -
结合其他指令：通常与
proxy_set_header或add_header等指令结合使用，以实现更灵活的请求头管理。例如：
variables_hash_bucket_size
variables_hash_bucket_size 指令用于控制Nginx在内存中存储变量哈希表的桶大小。这个指令影响Nginx如何存储和查找内部变量，从而优化配置文件中使用的变量的查找效率。如果设置得不合适，可能会导致性能下降或内存使用不当。
Syntax: variables_hash_bucket_size size;
Default: variables_hash_bucket_size 64;
Context: http
size：指定哈希表的桶大小，默认值为64字节。较大的桶大小可以减少哈希冲突，但会占用更多的内存。
案例
基本用法
最简单的variables_hash_bucket_size用法是指定哈希表的桶大小：
http {
include mime.types;
default_type application/octet-stream;
variables_hash_bucket_size 64; # 设置哈希表的桶大小为64字节（默认值）
}
在这个例子中，Nginx使用默认的哈希表桶大小64字节来存储变量。
根据需要调整variables_hash_bucket_size的值：
http {
include mime.types;
default_type application/octet-stream;
# 增加哈希表的桶大小以适应更多或更复杂的变量
variables_hash_bucket_size 128;
server {
listen 80;
server_name example.com;
location / {
set $my_var "Hello, World!";
return 200 $my_var;
}
}
server {
listen 80;
server_name another.example.com;
location / {
set $another_var "Goodbye, World!";
return 200 $another_var;
}
}
}
在这个例子中，我们将variables_hash_bucket_size设置为128字节，以适应更多或更复杂的变量，减少哈希冲突的可能性。
注意事项
-
哈希冲突：如果哈希表的桶大小设置得太小，当变量数量较多或变量名称较长时，可能会导致哈希冲突增加，进而影响查找效率。在这种情况下，Nginx可能会发出警告或错误信息，提示你调整哈希表的桶大小。
-
内存占用：较大的桶大小会占用更多的内存。因此，在调整此参数时，需要权衡性能与资源消耗之间的关系，尤其是在内存有限的环境中。
-
日志记录：启用适当的日志记录可以帮助你监控和调试与哈希表相关的性能问题。你可以通过Nginx的日志配置记录相关事件，以便快速定位和解决问题。
variables_hash_max_size
variables_hash_max_size 指令在Nginx中用于设置存储Nginx变量的哈希表的最大大小。这个哈希表用于加速变量查找过程，从而提高服务器性能。通过调整 variables_hash_max_size 的值，您可以优化Nginx在处理大量变量时的性能。
Syntax: variables_hash_max_size size;
Default: variables_hash_max_size 1024;
Context: http
size：指定哈希表的最大大小，默认值为1024。增加这个值可以减少哈希冲突，但会占用更多的内存。
案例
基本用法
最简单的 variables_hash_max_size 使用方法是指定一个适合您应用场景的哈希表大小：
http {
variables_hash_max_size 1024; # 设置哈希表最大大小为1024
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
}
}
在这个例子中，Nginx将使用默认的哈希表大小（1024）来存储变量。
调整哈希表大小
根据您的具体需求，可以调整哈希表的大小：
http {
variables_hash_max_size 2048; # 增加哈希表最大大小到2048
server {
listen 80;
server_name example.com;
location / {
root /var/www/html;
index index.html;
}
}
}
在这个例子中，哈希表的最大大小被增加到2048，以适应更多或更复杂的变量。
结合其他配置项
为了更好地管理您的Nginx服务器，您可以结合其他相关配置项使用 variables_hash_max_size：
http {
include mime.types;
default_type application/octet-stream;
variables_hash_max_size 4096; # 进一步增加哈希表最大大小到4096
client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;
upstream backend_servers {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /custom_vars {
set $custom_var "example_value"; # 定义自定义变量
echo $custom_var; # 输出自定义变量
}
}
}
在这个例子中：
- 全局配置中设置了较大的
variables_hash_max_size（4096），以便更好地处理大量或复杂的变量。 - 配置了多个与客户端请求相关的缓冲区大小，以优化性能。
- 在
/custom_vars路径下定义了一个自定义变量，并输出其值。
注意事项
- 资源管理：增加哈希表的最大大小可以减少哈希冲突，提高查找效率，但也会占用更多的内存。请根据服务器的实际内存情况合理配置。
- 性能优化：对于大多数应用，默认的
variables_hash_max_size 1024已经足够。如果您的应用需要处理大量或复杂的变量，可以根据实际情况适当增加该值。 - 调试与监控：定期监控服务器的内存使用情况，确保配置的哈希表大小不会导致内存耗尽或其他性能问题。
- 测试与验证：在生产环境中应用之前，务必在开发或测试环境中充分测试所有配置项，确保它们按预期工作。
扫一扫
2384
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
