nginx面试题

nginx 返回状态码413

Nginx 状态码 413 表示“请求实体过大”（Request Entity Too Large），意味着客户端发送的请求体大小超过了服务器允许的限制。
解决方法
修改 Nginx 配置文件：
找到 Nginx 配置文件，通常位于 /etc/nginx/nginx.conf。
在 http、server 或 location 块中添加或修改 client_max_body_size 指令来设置允许的最大请求体大小。例如：

http {client_max_body_size 20M;  # 设置为 20MB
}server {client_max_body_size 20M;  # 设置为 20MB
}location /upload {client_max_body_size 20M;  # 设置为 20MB
}

重载 Nginx 配置：

sudo nginx -s reload
sudo systemctl restart nginx

nginx返回状态码499

可能原因
客户端主动关闭连接 ：客户端在 Nginx 完成请求处理之前主动断开了连接，如用户关闭浏览器标签页、导航到其他页面或在网络不稳定的情况下移动设备切换网络等。

服务端响应过慢 ：后端服务处理请求时间过长，导致客户端在等待响应的过程中超时，进而主动关闭连接。

网络问题 ：在传输过程中，网络波动可能造成连接中断，使客户端无法及时收到服务端的响应，客户端在超时等待后会关闭连接。

客户端或中间代理设置问题 ：负载均衡器或代理服务器设置了过于严格的超时限制，导致客户端请求未完成就被中断。

客户端发送 FIN 报文 ：客户端先发送 FIN 报文，之后才发送 POST body，或者服务端还没回复数据而客户端已经发送 FIN 报文试图关闭连接。

解决方法：
调整客户端和 Nginx 的超时设置
增加客户端超时时间 ：在客户端代码中设置更长的超时时间，以便服务器有足够的时间处理请求。
调整 Nginx 超时参数 ：在 Nginx 配置文件中，使用 proxy_read_timeout 和 proxy_send_timeout 指令来设置更长的超时时间。例如：

proxy_read_timeout 300s;  # 设置读取超时时间为 300 秒
proxy_send_timeout 300s;   # 设置发送超时时间为 300 秒

启用 keepalive
在 Nginx 配置中启用 keepalive ：允许同一连接处理多个请求，减少创建和关闭连接的开销。例如：

keepalive_timeout 75s;  # 设置 keepalive 超时时间为 75 秒
keepalive_requests 100;  # 设置每个连接允许处理的请求数量为 100

使用 proxy_ignore_client_abort 参数
设置 proxy_ignore_client_abort 为 on ：在客户端主动关闭连接后，Nginx 与分发服务器的连接是否保持连接。如果设置为 on，后端服务器正常返回 200 状态码时，Nginx 将记录为 200；若后端返回 5XX 错误，Nginx 将记录为 5XX。例如：

location =/api {proxy_ignore_client_abort on;proxy_pass http://service_backends;
}

优化服务端响应速度
升级硬件设备 ：提升服务器的 CPU、内存等性能，以更好地应对高并发请求。
优化代码和数据库查询 ：对后端应用进行性能分析和优化，减少不必要的计算和数据库查询，提高代码执行效率。对数据库查询进行优化，如添加索引、减少查询次数等。
启用缓存机制 ：使用缓存技术，如 Redis、Memcached 等，存储频繁访问的数据，减少对数据库的访问次数，加快响应速度。
检查客户端代码
确保请求正确性 ：检查客户端发送的请求是否符合 HTTP 规范，包括正确的请求头和请求体格式。
避免过早关闭连接 ：确保客户端代码在处理请求和响应过程中不会意外关闭连接。
优化网络环境
确保网络稳定 ：检查网络连接，确保网络环境稳定，避免连接中断。
检查防火墙和安全组设置 ：确保防火墙和安全组的设置不会阻止 Nginx 和后端服务器之间的通信。

nginx反向代理，后端服务健康检测怎么配置

Nginx 可以通过主动健康检查和被动健康检查来监控后端服务的健康状态。
主动健康检查
主动健康检查通过定期向后端服务器发送请求来检查其健康状态。以下是一个配置示例：

http {upstream backend {server backend1.example.com;server backend2.example.com;zone backend 64k;health_check interval=3s fails=3 passes=2;health_check uri=/health;}server {location / {proxy_pass http://backend;}}
}

health_check 指令启用主动健康检查。默认情况下，每 5 秒发送一次请求到后端服务器的根路径 /。
可以通过 interval 参数指定检查间隔，默认为 5 秒。
fails 参数表示连续失败的检查次数，默认为 1。如果服务器连续失败指定次数的检查，则标记为不健康。
passes 参数表示连续成功的检查次数，默认为 1。服务器连续成功指定次数的检查后，会重新标记为健康。
uri 参数可以指定健康检查请求的 URL，默认为 /。
NGINX Plus 还支持更高级的健康检查配置，如自定义健康检查请求、超时时间等。
被动健康检查
被动健康检查通过监控后端服务器对实际请求的响应来判断其健康状态。配置示例如下：

http {upstream backend {server backend1.example.com max_fails=3 fail_timeout=30s;server backend2.example.com max_fails=3 fail_timeout=30s;}server {location / {proxy_pass http://backend;proxy_next_upstream error timeout http_500 http_502 http_503 http_504;}}
}

max_fails 指令设置连续失败的请求数量，默认为 1。当达到该值时，服务器会被标记为不健康。
fail_timeout 指定在标记服务器为不健康后，需要等待的时间（秒）才能再次尝试将其标记为健康，默认为 10 秒。
proxy_next_upstream 指令定义了在哪些情况下 Nginx 应该将请求转发到另一个服务器。例如，当后端服务器返回错误或请求超时时，Nginx 会尝试将请求发送到其他健康的服务器。
注意事项
确保后端服务提供了健康检查的接口，通常是一个返回 HTTP 200 状态码的 URL。
主动健康检查需要 NGINX Plus 的支持，而被动健康检查是 NGINX 社区版就支持的功能。
合理配置健康检查的参数，避免频繁的健康检查对后端服务造成不必要的负载。
监控 Nginx 的日志，以便及时发现和解决健康检查过程中出现的问题。

nginx缓存优化

以下是一些 Nginx 缓存优化的措施：
静态资源缓存
设置较长的缓存时间 ：对于静态资源如图片、CSS、JavaScript 等文件，可以通过设置较长的 expires 时间和 Cache-Control 头来强制浏览器缓存，减少对服务器的请求。
例如：

location ~* \.(js|css|png|webp)$ { expires 365d; add_header Cache-Control "public, immutable"; access_log off; }

其中 expires 365d 表示缓存 1 年，
add_header Cache-Control “public, immutable” 表示将资源标记为不可变，浏览器可以直接从缓存加载而无需检查更新。

关闭日志记录 ：对静态资源请求关闭日志记录，可以减少磁盘 IO 操作，提高性能。使用 access_log off; 来关闭静态资源的日志记录。

代理缓存
合理配置代理缓存路径 ：使用 proxy_cache_path 指令配置代理缓存的存储路径、缓存键的存储区域大小、缓存数据的最大存储空间以及缓存的有效期等参数。例如：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=dynamic_cache:100m max_size=10g inactive=24h use_temp_path=off;

其中 keys_zone=dynamic_cache:100m 表示创建一个名为 dynamic_cache 的共享内存区域，大小为 100MB，用于存储缓存键；max_size=10g 表示缓存数据的最大存储空间为 10GB；inactive=24h 表示缓存数据在 24 小时内未被访问则会被删除。

启用缓存锁 ：通过 proxy_cache_lock on; 启用缓存锁，防止多个请求同时更新同一个缓存对象，避免缓存击穿。

设置缓存有效性 ：使用 proxy_cache_valid 指令根据不同的 HTTP 状态码设置缓存的有效时间。例如 proxy_cache_valid 200 302 10m;
表示将 HTTP 状态码为 200 和 302 的响应缓存 10 分钟。

使用旧缓存响应错误 ：在后端服务器出现故障时，可以通过 proxy_cache_use_stale error timeout updating; 使 Nginx 返回旧的缓存内容，提高系统的可用性。

文件描述符缓存
启用 OpenFileCache ：通过 open_file_cache 指令启用文件描述符缓存，可以加速静态文件的访问。例如：

open_file_cache max=10000 inactive=30s; 

表示缓存最多 10000 个文件的元数据，文件描述符在 30 秒内未被访问则会被关闭。
open_file_cache_valid 60s; 表示缓存的文件元数据的有效期为 60 秒。
open_file_cache_min_uses 2; 表示文件至少被访问 2 次才会被缓存。

配合 Gzip 压缩
启用 Gzip 压缩 ：开启 gzip on; ，对响应内容进行压缩，减少传输的数据量，缓解网络拥塞，提高用户体验。例如：

gzip on; 
gzip_min_length 1k; 
gzip_comp_level 6; 
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; 
gzip_vary on; 

其中 gzip_min_length 1k 表示只有当响应内容大于等于 1KB 时才进行压缩；
gzip_comp_level 6 表示设置压缩级别为 6，兼顾了压缩效率和压缩率；gzip_types 指定了需要压缩的 MIME 类型。

其他优化
调整缓冲区大小 ：根据实际情况调整 Nginx 的缓冲区大小，避免频繁的磁盘 IO 操作。例如：
client_body_buffer_size 10K; 设置客户端请求体缓冲区大小为 10KB 。
client_header_buffer_size 1k; 设置客户端请求头缓冲区大小为 1KB 。
large_client_header_buffers 48k; 设置用于存储大型请求头的缓冲区数量和大小。

启用 keepalive 连接 ：通过 keepalive_timeout 和 keepalive_requests 指令启用 HTTP 的 keepalive 机制，减少 TCP 连接的建立和关闭开销。例如：
keepalive_timeout 65; 设置客户端与服务器保持连接的超时时间为 65 秒 。
keepalive_requests 100; 设置单个连接上允许的最大请求数为 100。

限制请求速率 ：使用 limit_req 模块限制请求速率，防止恶意请求或突发流量导致服务器过载。例如：

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; 

定义限流区域，根据客户端 IP 地址进行限流，每秒允许 1 个请求。
limit_req zone=one burst=5; 在指定的位置应用限流，允许突发 5 个请求。

优化日志记录 ：降低日志级别，减少日志输出量，提高性能。
例如

access_log /var/log/nginx/access.log main buffer=16k; error_log /var/log/nginx/error.log warn;

表示将访问日志的缓冲区大小设置为 16KB，并将错误日志级别设置为 warn。
监控与压测 ：通过 Nginx Status 模块、Prometheus + Grafana 等工具进行实时监控，收集 QPS、延迟、缓存命中率等指标。同时，使用 wrk、JMeter 等压测工具模拟高并发场景，验证优化效果。

nginx 热加载和硬加载原理

Nginx的热加载（热更新）和硬加载（硬更新或重启）是两种不同的重新加载配置或更新服务的方式。它们的原理如下：
1.热加载（热更新）
原理
Nginx使用多进程架构，包括一个主进程（master process）和多个工作进程（worker processes）。主进程主要负责管理和协调工作进程，如读取配置文件、启动和停止工作进程等，而工作进程负责处理实际的客户端请求。
当进行热加载时，主进程会先读取新的配置文件来检查语法是否正确。如果语法正确，主进程会创建新的工作进程来应用新的配置。同时，旧的工作进程会继续处理请求，直到它们完成当前正在处理的请求后才退出。新工作进程根据新的配置开始接收新的请求，从而实现了服务的平滑更新，整个过程对客户端是透明的，不会出现服务中断的情况。
例如，在更新Nginx配置后，执行 nginx -s reload 命令，主进程会向工作进程发送信号，通知它们重新加载配置。工作进程在完成当前正在处理的请求后，会终止运行，而新的工作进程会根据新的配置启动并开始处理新的请求。

优点
服务不中断 ：用户在访问网站或服务时不会察觉到配置更新操作，不会有请求被拒绝或延迟的情况。
高可用性 ：在高流量的网站或服务中，热加载能够确保服务的连续性，避免因配置更新导致的业务中断。

2.硬加载（硬更新或重启）
原理
硬加载通常是指直接重启Nginx服务。这会导致所有当前正在处理的请求被终止或等待服务重启完成后才能继续处理。如果使用简单的重启命令（如 systemctl restart nginx 或直接停止后再启动），旧的工作进程会被强制终止，新的工作进程根据新的配置启动。在重启过程中，会有短暂的时间窗口（通常很短，但取决于系统的负载和复杂性）内服务不可用，客户端的请求可能会收到连接被重置或超时等错误。
例如，如果在更新Nginx配置后，直接使用 systemctl restart nginx 命令，系统会先停止Nginx服务，包括终止所有工作进程，然后重新启动服务，新的工作进程根据新的配置开始运行。这过程中，新的请求无法被处理，直到服务完全重启完成。
优点
简单直接 ：在某些情况下，如配置文件发生重大变化或需要重新初始化资源时，硬加载可以快速使新的配置生效，无需考虑复杂的热加载逻辑。

nginx反向代理，第三方代理cookie
在 Nginx 反向代理中处理第三方代理 cookie 主要注意以下方面：
1.传递客户端的 cookie
在 Nginx 配置中，如果需要将客户端请求中的 cookie 传递给后端服务，需要使用 proxy_set_header Cookie $http_cookie; 指令。例如，在 location 块中添加如下配置：

location /api {rewrite /api/(.*) /$1 break;proxy_pass http://backend;proxy_set_header Host $BACKEND_URL;proxy_set_header Cookie $http_cookie;
}

这样可以确保客户端的 cookie 正确传递给后端服务。
2.配置后端服务信任代理
在后端服务中，需要配置其信任 Nginx 代理。例如，在 Node.js 应用中，可以通过 app.set(“trust proxy”, true); 来信任代理服务器。这样后端服务才能正确处理来自 Nginx 的请求和 cookie。
3.设置 cookie 的 SameSite 属性
如果后端服务设置的 cookie 需要在不同的域之间共享（如 Nginx 和后端服务不在同一域名下），需要考虑 cookie 的 SameSite 属性。可以通过在 Nginx 中使用 proxy_cookie_flags 指令来设置 cookie 的属性：

proxy_cookie_flags ~ secure samesite=none;

这会将所有 cookie 的 Secure 属性设置为 secure，并将 SameSite 属性设置为 none，确保 cookie 能够跨域传递。

4.根据 cookie 值动态选择后端
如果需要根据客户端的 cookie 值动态选择不同的后端服务，可以通过 Nginx 的条件判断和重写规则来实现。例如：

location /original-request {if ($http_cookie ~ "proxy-target-A") {rewrite . http://backend-a/some-application break;}if ($http_cookie ~ "proxy-target-B") {rewrite . http://backend-b/another-application break;}proxy_pass http://primary-backend/original-application;
}

负载均衡算法中 cookie和ip_hash的区别

在 Nginx 负载均衡中，基于 cookie 和 ip_hash 的负载均衡算法都可用于实现会话保持，但它们在实现原理、适用场景和特点上有显著区别。
基于 Cookie 的负载均衡
原理：基于 cookie 的负载均衡通过在客户端的请求中插入一个特殊的 cookie 来识别客户端的身份。当客户端首次访问时，负载均衡器会为其分配一个后端服务器，并在响应中设置一个 cookie。后续请求中，客户端会携带这个 cookie，负载均衡器根据 cookie 中的信息确定将请求转发到相同的后端服务器。
优点：
精确的会话保持：能更准确地识别客户端，即使客户端的 IP 发生变化（如移动设备切换网络），只要 cookie 未丢失或过期，仍可保持会话。
灵活性高：可以自定义 cookie 的名称、过期时间等参数，适用于多种复杂场景。
缺点：
依赖客户端支持：如果客户端禁用 cookie 或清除 cookie，会话保持将失效。
配置复杂度高：需要在 Nginx 配置中手动设置 cookie 的相关参数，如 cookie 名称、路径、域等。
适用场景：适用于需要高精度会话保持的场景，如电商网站的购物车、在线支付等。

ip_hash 负载均衡
原理：ip_hash 算法根据客户端的 IP 地址进行哈希运算，然后将哈希值对后端服务器的数量取模，确定请求应转发到哪一台服务器。同一客户端的 IP 地址始终会被映射到同一台后端服务器。
优点：
简单易用：Nginx 内置了 ip_hash 算法，无需额外安装插件，配置简单，只需在 upstream 模块中添加 ip_hash 指令即可。
会话保持：能保证来自同一 IP 地址的请求始终转发到同一台服务器，从而实现会话保持。
缺点：
对 IP 变化敏感：如果客户端的 IP 地址发生变化（如移动设备切换网络），会话将无法保持。
局域网问题：同一局域网内用户可能因 IP 前三位相同而被分配到同一台后端服务器，导致负载不均衡。
动态扩容困难：当后端服务器动态增减时，可能导致部分请求无法均匀分发。
适用场景：适用于客户端 IP 相对固定且对会话保持要求较高，同时服务器数量相对稳定的场景，如企业内部应用。

nginx负载均衡算法有哪些？

nginx轮询算法有：轮询、加权轮询、hash、ip_hash、最少连接数、url_hash、Fair（基于响应时间）、cookie

轮询（Round Robin）
默认算法 ：这是 Nginx 负载均衡最常用的算法，也是默认的算法。它自动将请求按顺序轮流分配到不同的后端服务器上。

upstream backend_servers {server backend1.example.com;server backend2.example.com;server backend3.example.com;
}server {listen 80;location / {proxy_pass http://backend_servers;}
}

权重轮询（Weighted Round Robin）
特点 ：与轮询算法类似，但为每个服务器指定了权重，具有较高权重的服务器将接收更多的请求。

upstream backend_servers {server backend1.example.com weight=3;server backend2.example.com weight=1;server backend3.example.com weight=2;
}

工作原理 ：在这个例子中，backend1.example.com 的权重是 3，它会比 backend2.example.com（权重是 1）多接收请求，具体来说，权重越大，服务器在一定时间内接收到的请求数量的比例就越高。

hash 算法
通过制定关键字作为 hash key ，基于 hash 算法映射到特定的上游服务器中。关键字可以包含有变量、字符串。

upstream demo_server {hash $request_uri consistent;server 121.42.11.34:8020;server 121.42.11.34:8030;server 121.42.11.34:8040;
}server {listen 80;server_name balance.lion.club;location /balance/ {proxy_pass http://demo_server;}
}

hash $request_uri 表示使用 request_uri 变量作为 hash 的 key 值，只要访问的 URI 保持不变，就会一直分发给同一台服务器。consistent 关键字表示使用一致性哈希算法，当服务器增加或减少时，可以尽量减少请求重新分配到其他服务器的情况。

ip_hash
根据客户端的请求 ip 进行判断，只要 ip 地址不变就永远分配到同一台主机。它可以有效解决后台服务器 session 保持的问题。

upstream demo_server {ip_hash;server 121.42.11.34:8020;server 121.42.11.34:8030;server 121.42.11.34:8040;
}server {listen 80;server_name balance.lion.club;location /balance/ {proxy_pass http://demo_server;}
}

最少连接数算法
各个 worker 子进程通过读取共享内存的数据，来获取后端服务器的信息。来挑选一台当前已建立连接数最少的服务器进行分配请求。

upstream demo_server {zone test 10M; # zone可以设置共享内存空间的名字和大小least_conn;server 121.42.11.34:8020;server 121.42.11.34:8030;server 121.42.11.34:8040;
}server {listen 80;server_name balance.lion.club;location /balance/ {proxy_pass http://demo_server;}
}

原理：Nginx 会实时监控每个后端服务器的连接数，把新的请求分配给连接数最少的服务器。例如，假设 backend1.example.com 当前有 5 个连接，backend2.example.com 有 3 个连接，那么新的请求会优先分配给 backend2.example.com。

公平（Fair）
特点 ：根据服务器的响应时间来分配请求，响应时间短的服务器会优先接收请求。这可以确保请求可以被更快地处理。

upstream backend_servers {fair;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

原理：Nginx 会统计每个服务器响应请求的时间，优先将新的请求分配给响应时间较短的服务器。例如，如果 backend1.example.com 响应一个请求平均需要 100ms，而 backend2.example.com 平均需要 200ms，那么新的请求会优先分配给 backend1.example.com。

URL 哈希（URL Hash）
与哈希算法类似，但哈希键值是固定的 URL。这样可以确保具有相同 URL 的请求被发送到同一个服务器上。

upstream backend_servers {hash $request_uri;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

工作原理 ：Nginx 根据请求的 URL 计算哈希值，将具有相同 URL 的请求分配到同一个后端服务器。

hash、ip_hash、url_hash三者的区别

算法	哈希键值	会话持久性	适用场景	配置复杂性	性能影响
hash	可自定义（如 URL、客户端 IP 等）	取决于键值稳定性	灵活的负载均衡需求，基于特定属性分配请求	中等	取决于键值计算复杂度
ip_hash	客户端 IP 地址	是（基于 IP）	需要保持会话持久性的场景	简单	较小
url_hash	请求的 URL	是（基于 URL）	对特定 URL 请求进行负载均衡和缓存一致性	中等	取决于 URL 复杂度

nginx性能优化有哪些？

nginx性能优化

什么是正向代理，什么是反向代理？两者的区别

正向代理
定义 ：
正向代理（Forward Proxy）是一种代理服务器，它位于客户端和目标服务器之间。客户端将请求发送给正向代理服务器，正向代理服务器再根据客户端的请求向目标服务器转发请求，并将目标服务器的响应返回给客户端。正向代理就像是客户端的一个 “代言人”，客户端通过它来访问外部资源。
工作原理 ：
例如，公司内部网络中的员工需要访问互联网。公司的网络管理员设置了正向代理服务器。当员工在浏览器中输入一个外部网页的 URL 时，浏览器会将请求发送到正向代理服务器。正向代理服务器会检查这个请求是否符合公司规定的访问策略，如是否允许访问该网站。如果符合，正向代理服务器会代替员工的计算机向外部网站服务器发送请求，获取网页内容后，再将内容返回给员工的浏览器。

反向代理
定义 ：
反向代理（Reverse Proxy）是位于服务器端的代理服务器。它接受来自客户端的请求，然后将请求转发给后端的多个服务器，并将后端服务器的响应返回给客户端。对于客户端来说，它并不知道反向代理服务器后面还有多个服务器，就好像反向代理服务器就是最终提供服务的目标服务器。
工作原理 ：
以一个大型电商网站为例，该网站有多个后端服务器来处理不同的业务，如商品展示服务器、订单处理服务器、用户信息服务器等。反向代理服务器位于这些后端服务器前面。当用户在浏览器中输入电商网站的 URL 时，请求会先发送到反向代理服务器。反向代理服务器根据请求的内容（如 URL 路径）来决定将请求转发给相应的后端服务器。例如，如果请求是关于商品的详细信息，就转发给商品展示服务器；如果是关于下单的请求，就转发给订单处理服务器。后端服务器处理完请求后，将响应返回给反向代理服务器，反向代理服务器再将响应发送给用户。

两者的区别
服务对象不同 ：
正向代理主要服务于客户端，帮助客户端访问外部资源。它关注的是客户端的需求，如代理客户端去获取被限制访问的内容或者提高客户端的访问效率。
反向代理主要服务于服务器端，帮助后端服务器更好地处理客户端请求。它关注的是如何优化后端服务器的性能、安全性等方面。
请求方向不同 ：
正向代理的请求流程是客户端 → 正向代理服务器 → 目标服务器，客户端主动将请求交给正向代理服务器来处理外部请求。
反向代理的请求流程是客户端 → 反向代理服务器 → 后端服务器，客户端直接向反向代理服务器发起请求，反向代理服务器再将请求转发给后端服务器。
配置方式和位置不同 ：
正向代理通常需要在客户端进行配置，让客户端知道请求要先经过正向代理服务器。它一般位于客户端的网络环境中，比如企业内部网络的出口位置。
反向代理一般不需要客户端进行特殊配置，客户端直接访问反向代理服务器的地址即可。反向代理服务器通常位于服务器端的网络环境中，在后端服务器的前端，作为服务器群的前置设备。
功能侧重点不同 ：
正向代理侧重于客户端的隐私保护（匿名访问）、突破访问限制（访问被封锁的网站）和缓存加速等功能。
反向代理侧重于服务器的负载均衡、安全防护（如隐藏后端服务器 IP、防御 DDoS 攻击等）和统一入口管理等功能。

解释 Nginx 中的 Location 指令。

location 指令用于定义 Nginx 如何响应特定的请求 URI。location 指令可以匹配请求的 URI，并根据不同的匹配结果，应用不同的配置，如代理设置、重写规则或返回不同的内容。

Nginx 配置文件的结构是什么样的？

Nginx 的配置文件通常以 nginx.conf 为主配置文件，它的结构包括 events 块、http 块以及可选的 mail 块。events 块配置与连接处理相关的参数；http 块配置与 HTTP 服务相关的参数，包括服务器列表、负载均衡配置、MIME 类型定义、日志定义等；mail 块用于邮件代理服务器。

如何在 Nginx 中启用 HTTPS？

在 Nginx 中启用 HTTPS 需要配置 SSL 证书和私钥，并在 server 块中设置监听 443 端口并启用 SSL。需要指定 ssl_certificate 和 ssl_certificate_key 指令来指定证书文件和私钥文件的路径。

Nginx 是如何处理请求的？

Nginx 使用基于事件的模型和非阻塞的方式来处理请求。客户端的请求首先由 master 进程接收，然后 master 进程根据配置分配给一个或多个 worker 进程。worker 进程监听端口并接受新的请求，处理请求，并将结果返回给客户端。

解释 Nginx 的 Master-Worker 架构。

Nginx 采用了 Master-Worker 的架构模式。Master 进程负责读取和验证配置文件、管理 worker 进程；而 Worker 进程则负责处理实际的客户端请求。这种架构模式利用了多核 CPU 的优势，提高了并发处理能力和稳定性。

如何在 Nginx 中实现 IP 黑名单？

在 Nginx 中实现 IP 黑名单可以通过配置 allow 和 deny 指令来完成。在需要限制的 location 或 server 块中，使用 deny 指令来指定不允许访问的 IP 地址，然后使用 allow 指令来指定允许访问的 IP 地址。

Nginx 如何实现防止 DDOS 攻击。

Nginx 可以通过配置限制来抵抗 DDOS 攻击，例如：
限制连接速率（limit_req 模块）
限制并发连接数（limit_conn 模块）
配置防火墙规则来拦截异常流量
使用第三方模块如 ngx_http_limit_req_module 来限制请求频率
启用 fail2ban 等工具来动态地添加攻击源 IP 到防火墙黑名单

如何定义错误提示页面？

通过在 Nginx 配置文件中使用 error_page 指令来定义错误提示页面。例如：

error_page 500 502 503 504 /50x.html;
location = /50x.html {root /root;
}

如何精准匹配路径？

在 Nginx 中，使用 location = 开头来表示精准匹配。例如：

location = /get {# 规则 A
}

nginx路径匹配优先级

= 精确匹配；

正则匹配，区分大小写；
~* 正则匹配，不区分大小写；
^~ 匹配到即停止搜索；
匹配优先级： = > ^~ > ~ > ~* > 不带任何字符。
多个 location 配置的情况下匹配顺序为：首先匹配 =，其次匹配 ^~，其次是按文件中顺序的正则匹配，最后是交给 / 通用匹配。当有匹配成功时，停止匹配，按当前匹配规则处理请求。

如何根据文件类型设置过期时间？

可以使用如下配置根据文件类型设置过期时间：

location ~* \.(js|css|jpg|jpeg|gif|png|swf)$ {if (-f $request_filename) {expires 1h;break;}
}

禁止访问某个目录的配置方法是什么？

通过在 location 块中配置 deny 指令来禁止访问某个目录。例如：

location ^~/path/ {deny all;
}

Nginx 有几种进程模型？

分为 master-worker 模式和单进程模式。在 master-worker 模式下，有一个 master 进程和至少一个的 worker 进程，单进程模式顾名思义只有一个进程。

如何在 Nginx 中启用 Gzip 压缩？

在 Nginx 中启用 Gzip 压缩需要在 http 块或 server 块中添加相关的 Gzip 模块指令。例如：

gzip on;
gzip_min_length 1k;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_vary on;

Nginx 的 upstream 模块的作用是什么？

ngx_http_upstream_module 用于定义可通过 fastcgi 传递、proxy 传递、uwsgi 传递、memcached 传递和 scgi 传递指令来引用的服务器组。

什么是 C10K 问题？Nginx 是如何解决 C10K 问题的？

C10K 问题是无法同时处理大量客户端（10,000）的网络套接字。
Nginx 解决 C10K 问题的方法
事件驱动模型 ：Nginx 采用基于事件驱动的非阻塞 I/O 模型，使用少量的线程或进程处理多个并发连接。当某个连接有数据可读或可写时，系统会通知相应的进程或线程进行处理，而不是像传统模型那样让进程或线程主动去轮询连接的状态，这使得它能够高效地处理大量连接请求，而不会因为每个连接都需要独立的线程或进程而导致资源消耗过大。
多路复用技术 ：Nginx 利用操作系统提供的多路复用机制，如 Linux 下的 epoll、FreeBSD 下的 kqueue 等。在一个线程或进程中可以监听多个文件描述符，当有事件发生时进行处理。epoll 会告知哪些连接有事件待处理，Nginx 只需对这些连接进行操作，无需像 select 或 poll 那样轮询所有连接，极大地提高了并发处理能力，减少了对系统资源（如 CPU 和内存）的占用。
高效内存管理 ：Nginx 采用自己设计的内存池机制，预先分配一块连续的内存空间作为内存池，并按需从该内存池中分配给请求处理程序使用，避免了频繁的内存分配和释放操作，从而避免了频繁调用 malloc 和 free 函数带来的开销。
工作进程模型 ：Nginx 采用主进程加多个 worker 子进程的工作模型。主进程负责初始化套接字并管理子进程的生命周期，worker 进程负责实际的请求处理。worker 进程的数量可以根据 CPU 核心数等因素灵活配置，使每个进程能够绑定到特定的 CPU 核心上，减少进程间的上下文切换，充分利用多核 CPU 的优势，提高系统的吞吐能力。
连接处理优化 ：Nginx 在处理连接时，会将连接分配给不同的 worker 进程，每个 worker 进程可以同时处理多个连接。由于其非阻塞的特性，worker 进程在等待某个连接的 I/O 操作完成期间，可以继续处理其他连接的请求，从而提高了连接的处理效率。
模块化设计 ：Nginx 的模块化设计使其能够按需加载功能，避免了不必要的内存占用和性能开销。不同的模块可以独立开发、加载和升级，使得 Nginx 能够灵活地适应各种应用场景，同时保持高性能。

Nginx 是否支持将请求压缩到上游？

可以使用 Nginx 模块 gunzip 将请求压缩到上游。gunzip 模块是一个过滤器，它可以对不支持 “gzip” 编码方法的客户机或服务器使用 “内容编码：gzip” 来解压缩响应。

如何在 Nginx 中获得当前的时间？

要获得 Nginx 的当前时间，可以使用 SSI 模块、$date_gmt 和 $date_local 的变量。例如：

Proxy_set_header THE-TIME $date_gmt;

用 Nginx 服务器解释 -s 的目的是什么？

s 选项用于运行 Nginx 可执行文件时指定信号，例如用于发送特定的信号给 master 进程以控制 Nginx 的行为，如重新加载配置、优雅地关闭等。

生产中如何设置 worker 进程的数量？

在有多个 CPU 的情况下，可以设置多个 worker 进程，worker 进程的数量可以设置到和 CPU 的核心数一样多。如果在单个 CPU 上起多个 worker 进程，那么操作系统会在多个 worker 之间进行调度，这种情况会降低系统性能，所以如果只有一个 CPU，那么只启动一个 worker 进程就可以了。

如何限制访问？

可以通过配置 allow 和 deny 指令来限制访问。例如，限制特定 IP 地址访问：

if ($remote_addr = 192.168.9.115) {return 403;
}

如何设置安全的 HTTP 头部？

可以通过在 Nginx 配置文件中添加相关的 HTTP 头部来增强安全性。例如：

add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header Content-Security-Policy "default-src 'self'";

如何在 Nginx 中监控性能？

可以使用 Nginx 的 stub_status 模块来监控性能。通过配置 location 块来启用 stub_status，然后可以访问相应的 URL 来查看性能指标，如活跃连接数、接受的连接数、处理的请求数等。

如何在 Nginx 中设置日志格式？

可以通过 log_format 指令来设置日志格式。例如：

log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';

Nginx 如何实现后端服务的健康检查？

可利用 Nginx 自带模块或 nginx_upstream_check_module 模块对后端节点进行健康检查

upstream backend {server 192.168.0.1;server 192.168.0.2;check interval=3000 rise=2 fall=5;
}

如何实现 Nginx 动态限流？

使用 limit_req_zone 限制请求速率：

http {limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;server {location /api/ {limit_req zone=api_limit burst=200 nodelay;proxy_pass http://backend;}}
}

如何通过 Nginx 实现零拷贝（Zero-Copy）传输？

启用 sendfile 指令，绕过用户空间直接在内核完成文件传输：

http {sendfile on;          # 启用零拷贝tcp_nopush on;       # 合并数据包减少网络开销tcp_nodelay on;      # 禁用 Nagle 算法
}

如何定位 Nginx 内存泄漏问题？

诊断工具链：使用 Valgrind 检测内存非法访问、gdb + Python 脚本分析 Worker 进程堆栈、jemalloc 替换默认内存分配器监控碎片率。

如何在 Nginx 中配置多个虚拟主机？

示例配置：

server {listen 80;server_name www.example1.com;location / {root /var/www/example1;index index.html;}
}server {listen 80;server_name www.example2.com;location / {root /var/www/example2;index index.html;}
}

如何在 Nginx 中实现 URL 重写？
示例配置：

server {listen 80;server_name example.com;location /old-path/ {rewrite ^/old-path/(.*)$ /new-path/$1 permanent;}
}

如何在 Nginx 中配置反向代理？

示例配置：

server {listen 80;server_name example.com;location / {proxy_pass http://backend;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}
}

如何在 Nginx 中配置 SSL 证书？

示例配置：

server {listen 443 ssl;server_name example.com;ssl_certificate /path/to/certificate.crt;ssl_certificate_key /path/to/private.key;location / {proxy_pass http://backend;}
}

如何在 Nginx 中配置负载均衡？

示例配置：

upstream backend {server backend1.example.com;server backend2.example.com;server backend3.example.com;
}server {location / {proxy_pass http://backend;}
}

如何在 Nginx 中实现 URL 重写？

示例配置：

server {listen 80;server_name example.com;location /old-path/ {rewrite ^/old-path/(.*)$ /new-path/$1 permanent;}
}

如何配置 Nginx 的高可用性？

当上游服务器出现故障或未及时响应时，应直接轮询到下一台服务器，保证服务器的高可用：

server {listen 80;server_name www.lijie.com;location / {proxy_pass http://backServer;proxy_connect_timeout 1s;proxy_send_timeout 1s;proxy_read_timeout 1s;index index.html index.htm;}
}

如何通过 Nginx 限制特定浏览器访问？

示例配置：

# 不允许谷歌浏览器访问，如果是谷歌浏览器返回 500
if ($http_user_agent ~ Chrome) {return 500;
}

如何通过 Nginx 限制 IP 访问？

示例配置：

# 如果访问的 ip 地址为 192.168.9.115，则返回 403
if ($remote_addr = 192.168.9.115) {return 403;
}

如何处理 Nginx 的惊群效应（Thundering Herd）？

优化方案：Linux 内核≥3.9 时启用 reuseport ：
listen 80 reuseport;
调整 accept_mutex 与 worker_processes auto;。

502 Bad Gateway 错误的完整排查流程？

六步定位法：
检查上游服务状态（curl -v http://upstream），
查看 Nginx 错误日志（error.log 中 upstream timed out），
确认防火墙规则（iptables -L -n），
验证 DNS 解析（dig upstream.domain），
测试反向代理配置（nginx -T）。

nginx四层代理怎么做？

Nginx 四层代理主要基于传输层（TCP/UDP）进行工作，利用目标 IP 地址和端口号将请求分发到后端服务器，性能高、延迟低、吞吐量大。其配置主要是通过 Nginx 的 stream 模块实现的。以下是一个基本的 Nginx 四层代理配置示例：

worker_processes auto;
events {multi_accept on;worker_connections 1024;
}
stream {upstream app_server {server 172.16.0.248:9511;server 172.22.0.45:30028;}server {listen 9501;proxy_pass app_server;}
}

工作原理
四层代理工作在传输层，基于连接进行转发，根据目标 IP 地址和端口号将请求分发到后端服务器。Nginx 通过 stream 模块实现了四层代理功能，该模块允许配置监听 TCP 或 UDP 端口，并通过 proxy_pass 指令将流量转发给后端服务器组。这种方式不解析应用层内容，直接转发原始数据流，因此具有高性能、低延迟的特点。

应用场景
数据库代理：对外暴露统一端口，内部转发至 MySQL、Redis 等数据库集群。
游戏服务器代理：代理 UDP 协议，实现实时数据包负载均衡。
SSH 跳板机代理：通过端口映射安全访问内网服务器。
高可用服务：适用于 TCP 服务（如 MQTT）的主备切换与健康检查。

nginx如何实现高并发

Nginx 实现高并发主要通过以下几种方式：
采用多进程单线程模型
Nginx 采用多进程单线程模型，其 Master 进程负责管理 Worker 进程，Worker 进程处理客户端请求。Worker 进程的数目可以设置为与 CPU 核心数相同，以充分使用 CPU，避免多线程带来的线程切换和锁竞争问题，从而高效地处理并发请求。
使用高效的 I/O 多路复用技术
Nginx 在 Linux 平台下默认采用 epoll I/O 多路复用技术，在 FreeBSD 下使用 kqueue 等。这些技术可以同时监听多个文件描述符上的事件，当有事件发生时才进行处理，使得 Nginx 能够高效地处理大量的并发连接，而不会像传统模型那样在等待 I/O 时浪费大量时间。
优化连接处理机制
增加连接数限制 ：通过设置 worker_processes 和 worker_connections 参数来增大 Nginx 的并发连接数。例如，若 worker_processes 设置为 4，worker_connections 设置为 1024，则理论上最大并发连接数可达 4×1024=4096。
开启多路复用 ：在 Nginx 配置文件中添加 multi_accept on;，让一个 Worker 进程尽可能多地接受新的连接，提高连接建立的效率。
优化连接超时时间 ：合理设置客户端连接超时时间，如 keepalive_timeout，对于高并发场景，可适当减小该值，以便及时释放闲置连接，避免资源浪费。同时，还可以设置客户端请求头、请求主体等的超时时间，如 client_header_timeout、client_body_timeout 等。
启用高效的文件传输机制
开启 sendfile 系统调用，实现文件数据的零拷贝传输，减少数据在内核态和用户态之间的来回拷贝，从而提高文件传输效率，降低系统资源消耗。同时，可配合 tcp_nopush 参数，将小包数据合并后发送，减少网络传输中的数据包数量，提高传输效率。
启用压缩功能
在 Nginx 中启用 gzip 压缩功能，可以减小响应数据的大小，降低网络传输带宽的需求，从而加快数据传输速度，提高用户体验，尤其适用于传输大量文本数据的场景，如 HTML、CSS、JavaScript 等文件。
采用反向代理和负载均衡
将 Nginx 作为反向代理服务器，将多个后端服务器组合成一个高性能的服务器集群，将客户端请求分发到不同的后端服务器上，实现负载均衡。同时，Nginx 可以缓存后端服务器的响应数据，对于频繁访问的静态资源，直接从 Nginx 缓存中返回，减轻后端服务器的负载，提高系统的整体性能和并发处理能力。
缓存机制优化
Nginx 可以设置缓存策略，对后端服务器的响应进行缓存，当后续有相同的请求时，直接返回缓存中的数据，减少对后端服务器的请求次数，降低后端服务器的负载，同时提高响应速度。
系统层面优化
调整文件描述符限制 ：增加系统对每个进程可打开文件数量的限制，以满足 Nginx 高并发时对文件描述符的需求。可通过修改 /etc/security/limits.conf 文件，设置 nofile 参数来实现。
优化 TCP 协议栈参数 ：调整内核参数，如增大 TCP 后备队列长度 net.core.somaxconn、减少 TIME_WAIT 状态的连接数、增大文件句柄数等，以提高系统的网络性能和并发处理能力。

简述nginx目录结构

Nginx 的目录结构主要包括以下几个关键部分：
安装目录
这是 Nginx 软件安装后的主要存放位置，例如在使用编译安装时默认可能是 /usr/local/nginx。该目录下包含了 Nginx 的可执行文件 nginx，位于 /usr/local/nginx/sbin/nginx，用于启动和管理 Nginx 服务。
还包含了配置文件目录 /usr/local/nginx/conf，其中最重要的就是主配置文件 nginx.conf，用于定义 Nginx 的各种运行参数、虚拟主机配置、服务器块等内容，同时还可能有一些其他相关的配置文件，如 mime.types（定义了文件扩展名与媒体类型之间的映射关系）等。
日志目录
默认位置通常是 /usr/local/nginx/logs，用于存储 Nginx 的日志文件。其中包括访问日志 access.log，记录了客户端访问 Nginx 的详细信息，如访问时间、客户端 IP、请求的 URI、HTTP 状态码、响应时间等；还有错误日志 error.log，用于记录 Nginx 在运行过程中出现的错误信息，如配置文件语法错误、模块加载失败、无法打开文件等错误情况，方便管理员进行问题排查和故障诊断。
HTML 文件存放目录（站点根目录）
默认为 /usr/local/nginx/html，这是 Nginx 处理 HTTP 请求时默认的网页文件存放位置。当用户访问 Nginx 服务器时，如果没有指定具体的文件路径，Nginx 会从这个目录下查找默认的首页文件（通常是 index.html 或 index.htm 等），并将其返回给客户端浏览器显示。当然，这个目录可以通过配置文件中的 root 指令进行修改，以满足不同网站的实际需求，将网页文件放在其他指定的目录中。
模块目录
在安装 Nginx 时，会根据编译时的选择和配置，将相关的模块文件存放在指定的模块目录中，例如 /usr/local/nginx/modules。这些模块扩展了 Nginx 的功能，如处理不同类型的请求（如 FastCGI、uWSGI、SCGI 等）、进行负载均衡、提供缓存功能等。在编译安装时，可以通过 --add-module 参数来添加第三方模块，以满足特定的应用场景需求。