Nginx是一个高性能的HTTP和反向代理服务器，同时支持IMAP/POP3/SMTP/TCP（1.9或更高版本）代理服务。Nginx的功能强大且多样，这主要得益于其丰富的模块系统。以下是对Nginx的一些主要功能和模块的详细展开：核心模块ngx_http_core_module：Nginx的核心模块，提供了HTTP服务的基本功能。它负责处理HTTP请求和响应，并包含丰富的配置指令。例如，可以定义HTTP服务器的监听端口、访问日志、错误日志等，配置请求的解析和响应的处理，如请求头和响应头的处理，还可以设置客户端请求的限速和连接超时等。代理模块ngx_http_proxy_module：Nginx的代理模块，用于将客户端请求转发到后端服务器。它实现了反向代理功能，支持HTTP、HTTPS和WebSocket协议。通过配置代理缓存，可以减少后端服务器的负载。此外，它还可以将客户端请求分发到多个后端服务器，实现负载均衡。重写模块ngx_http_rewrite_module：Nginx的重写模块，用于修改客户端请求的URL。它可以根据特定的规则对请求进行重写或重定向，支持正则表达式的使用，实现灵活的URL重写规则。URL重写功能可以将旧的URL重写为新的URL，实现网站的伪静态化。路径重定向功能则可以根据不同的请求条件，将请求重定向到不同的页面或服务器。SSL模块ngx_http_ssl_module：Nginx的SSL模块，用于支持HTTPS协议，提供加密传输和安全认证功能。它支持SSL证书的管理，对客户端和服务器之间的数据进行加密处理，提供安全的HTTPS连接，保障数据的安全性和完整性。在需要加密传输和安全认证的场景中，如电子商务、银行等，可以使用HTTPS协议保护客户端和服务器之间的通信。压缩模块ngx_http_gzip_module：Nginx的压缩模块，用于对HTTP响应数据进行压缩，减少数据传输量，提高访问速度。它支持多种压缩算法和级别，可以根据需要调整压缩效果。在带宽有限或网络延迟较高的场景中，使用压缩模块可以减少数据传输时间，提高用户体验。在提供大量静态资源的场景中，压缩文件大小可以减少服务器带宽消耗。流模块ngx_stream_core_module：Nginx的流模块，用于处理TCP和UDP协议的流量，实现四层负载均衡功能。它提供了高性能和可扩展的解决方案，适用于游戏服务器、实时通信等场景。例如，在游戏服务器场景中，可以使用流模块处理玩家与服务器之间的TCP和UDP流量，实现游戏的稳定运行。在实时通信场景中，可以使用流模块处理音视频流的传输，保证通信的质量和稳定性。负载均衡模块ngx_http_upstream_module：Nginx的负载均衡模块，用于配置后端服务器列表和负载均衡策略。它可以配置后端服务器列表，定义服务器的地址和权重等。同时，它支持多种负载均衡算法，如轮询、IP哈希等。在高并发场景中，使用负载均衡模块可以将请求分发到多个后端服务器，提高系统的并发处理能力。在多服务器部署场景中，使用负载均衡模块可以实现故障转移和故障恢复，提高系统的可用性。其他常用模块http_cache_purge_module：用于清除缓存。http_auth_basic_module：用于基本认证。http_limit_req_module：用于限制请求速率，防止恶意请求或过载。http_limit_conn_module：用于限制连接数，保护服务器资源。http_log_module：用于日志记录，可以记录访问日志和错误日志，帮助管理员监控和分析服务器的运行状况。http_geo_module：用于基于IP地址的地理位置信息，可以根据客户端的IP地址判断其地理位置，并基于地理位置进行访问控制或内容分发等。综上所述，Nginx凭借其丰富的功能模块和强大的性能，在企业级应用中发挥着重要的作用。在实际应用中，可以根据业务需求选择合适的模块和配置，以达到最佳性能。

Nginx不仅可以作为Web服务器，还可以作为缓存服务器使用。通过Nginx缓存，可以对一些静态资源或者数据更新频率较低的后端服务做缓存，降低静态资源或后端服务的响应时间，同时也会降低后端的负载。以下将介绍Nginx配置缓存和清除缓存的方法。Nginx配置缓存要配置Nginx缓存，可以按照以下步骤进行：修改Nginx配置文件：在http上下文中使用proxy_cache_path指令创建keys zone，即创建一块共享内存空间，用于存储缓存数据的active key。同时，指定一个目录，用于存储缓存的数据。在http、server、location上下文中，使用proxy_cache指令，指定要使用的keys zone。在http、server、location上下文中，使用proxy_cache_valid指令，指定针对哪些返回码的响应做缓存，以及缓存多长时间。示例配置：假设要对一个6081端口的后端服务做缓存，Nginx配置示例如下：# 创建keys zone——test-cache，并设置1MB的共享内存空间 # 指定缓存数据保存在/tmp/nginx-cache目录下 proxy_cache_path /tmp/nginx-cache keys_zone=test-cache:1m use_temp_path=off; server { listen 12345; location / { proxy_cache test-cache; # 使用test-cache缓存zone # 只缓存状态码是200的响应，缓存时间为10分钟 proxy_cache_valid 200 10m; proxy_pass http://localhost:6081; # 代理后端服务 } }此外，如果需要缓存POST请求的响应，可以在http、server、location上下文中使用proxy_cache_methods指令指定POST参数，并使用proxy_cache_key指令在参数中添加$request_body变量。应用配置：将上述Nginx配置文件放到/etc/nginx/conf.d/目录下，并重新加载nginx服务使配置生效。清除Nginx缓存要清除Nginx的缓存，可以采取以下几种方法：手动删除缓存文件：Nginx默认的缓存路径是在/var/cache/nginx目录下（路径可能因安装方式或配置不同而有所差异）。可以通过命令sudo rm -rf /var/cache/nginx/*来删除所有缓存文件。但请注意，这种方法会删除所有缓存，可能会影响到正在被缓存的内容的访问。使用Nginx的proxy_cache_purge模块：如果Nginx配置了proxy_cache模块来进行缓存，可以使用proxy_cache_purge模块来清除指定URL的缓存。需要在Nginx配置文件中添加相应的配置，然后使用curl命令来发起清除缓存的请求。配置示例如下：location ~ /purge(/.*) { allow 127.0.0.1; # 只允许本地访问 deny all; proxy_cache_purge cache_zone_name $1; # 替换cache_zone_name为实际的缓存zone名称 }然后使用curl命令来清除缓存：curl -X PURGE http://example.com/purge/url_to_purge其中url_to_purge是要清除缓存的URL路径。重新加载Nginx配置：重新加载Nginx配置也会导致所有缓存文件被删除。但这种方法比较粗暴，通常不建议作为常规操作来使用。可以在需要完全清除缓存时考虑使用。重新加载Nginx配置的命令如下：sudo systemctl reload nginx使用缓存管理工具：有些Nginx的缓存管理工具可以帮助管理和清除缓存，例如ngx_cache_purge模块等。这些工具通常提供更丰富的功能和更灵活的操作方式，但需要根据具体需求进行选择和配置。注意事项在清除Nginx缓存之前，请确保已经备份了重要的数据或缓存内容，以防止误操作导致数据丢失。清除缓存可能会影响到正在被缓存的内容的访问速度和性能，因此请在进行清除操作之前评估其对业务的影响。在配置和使用Nginx缓存时，请务必根据实际需求进行合理的配置和优化，以提升系统的性能和可靠性。综上所述，Nginx配置缓存和清除缓存的方法相对简单且灵活，可以根据实际需求进行选择和配置。通过合理的配置和优化，可以充分利用Nginx的缓存功能来提升系统的性能和用户体验。

location ~* ^/(api|/files|v1|test)(.*)$ { proxy_pass http://10.111.111.1111:8080; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off; client_max_body_size 600M; client_body_buffer_size 600M; uwsgi_send_timeout 1800; uwsgi_connect_timeout 1800; uwsgi_read_timeout 1800; proxy_read_timeout 1800; proxy_connect_timeout 1800; proxy_send_timeout 1800; }

当前在我们项目的cce环境中，为了实现pod之间的通信，采用ingress维护了一个pod的路由配置，想询问是否可以替换成ASM实现一样的能力。找了一圈也没看到有开发的指导，这个ASM是否只可用于pod之间通信的监控，并不能进行路由信息的配置呢？

一个网站项目，肯定是避免不了404页面的，通常使用Nginx作为Web服务器时，有以下集中配置方式，一起来看看。第一种：Nginx自己的错误页面Nginx访问一个静态的html 页面，当这个页面没有的时候，Nginx抛出404，那么如何返回给客户端404呢？看下面的配置，这种情况下不需要修改任何参数，就能实现这个功能。123456789server {    listen      80;    server_name  www.example.com;    root   /html;    index  index.html index.htm;    location / {    }}定义错误页面码，如果出现相应的错误页面码，转发到那里。1error_page  404 403 500 502 503 504  /404.html;承接上面的location。1location = /404.html {放错误页面的目录路径。1root   /usr/share/nginx/html;第二种：反向代理的错误页面如果后台Tomcat处理报错抛出404，想把这个状态叫Nginx反馈给客户端或者重定向到某个连接，配置如下：123456789101112131415upstream www {    server 192.168.1.201:7777  weight=20 max_fails=2 fail_timeout=30s;    ip_hash;}server {    listen       80;    server_name www.example.com;    root   /html;    index  index.html index.htm;    location / {        if ($request_uri ~* ‘^/$') {            rewrite .*   http://www.example.com/index.html redirect        }    }}关键参数：这个变量开启后，我们才能自定义错误页面，当后端返回404，nginx拦截错误定义错误页面123456789proxy_intercept_errors on;proxy_pass      http://www;proxy_set_header HOST   $host;proxy_set_header X-Real-IP      $remote_addr;proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for;error_page    404  /404.html;location = /404.html {    root   /usr/share/nginx/html;}AI专家指定一个url地址：12error_page 404  /404.html;error_page 404 = http://www.example.com/404.html;

 一、什么是nginx？ Nginx是一款轻量级的HTTP服务器，采用事件驱动的异步非阻塞处理方式框架，这让其具有极好的IO性能，时常用于服务端的反向代理和负载均衡。 优点：  支持海量高并发：采用IO多路复用epoll。官方测试Nginx能够支持5万并发链接，实际生产环境中可以支撑2-4万并发连接数。 内存消耗少 可商业化 配置文件简单 除了这些优点还有很多，比如反向代理功能，灰度发布，负载均衡功能等 二、nginx 部署前端vue项目步骤 2.1 安装nginx 2.1.1 windows环境安装 到nginx官方下载系统相关的nginx版本安装  启动命令：  cd F:\nginx-1.19.4 start nginx 2.1.2 linux环境安装 通常情况下很少使用windows来作为nginx的服务器，一般使用linux。对于linux安装nginx有两种方式，一种是使用官方已经编译好的包来安装，一种是使用源码构建安装。  第一种方式参考官方地址https://nginx.org/en/linux_packages.html#stable  第二种方式参考官方地址https://nginx.org/en/docs/install.html中的Building from Sources片段，这种实际上就是下一个tar.gz包仍到linux服务去自己编译。  在linux服务上和window环境上使用nginx部署vue项目并没有太大差异，把构建好的vue项目dist上传到linux服务上，通用修改nginx服务器中的root来指向dist就ok了，然后使用  # centos 7 systemctl restart nginx.service # centos 6 service nginx restart # 或者是平滑重启 service nginx reload 2.2 打包vue项目 执行命令  npm run build 1  2.3 配置nginx 修改nginx配置文件，配置文件为conf下的nginx.conf,修改nginx.conf中的server配置片段  server {         listen       80;#默认端口是80，如果端口没被占用可以不用修改         server_name  localhost;         root        E:/vue_project/my_project/dist;#vue项目的打包后的dist          location / {             try_files $uri $uri/ @router;#需要指向下面的@router否则会出现vue的路由在nginx中刷新出现404             index  index.html index.htm;         }         #对应上面的@router，主要原因是路由的路径资源并不是一个真实的路径，所以无法找到具体的文件         #因此需要rewrite到index.html中，然后交给路由在处理请求资源         location @router {             rewrite ^.*$ /index.html last;         }         #.......其他部分省略   }  完成nginx配置后重新加载配置文件  nginx -s reload 1 nginx -s reload 浏览器中访问：http://localhost 测试是否部署成功 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/qq_28419035/article/details/141822578 

前端通过const ws = new WebSocket('ws://websocket'); 访问后端，返回失败，直接进入onerrorusted: truebubbles: falsecancelBubble: falsecancelable: falsecomposed: falsecurrentTarget: WebSocket {url: 'ws://websocket', readyState: 3, bufferedAmount: 0, onopen: ƒ, onerror: ƒ, …}defaultPrevented: falseeventPhase: 0returnValue: truesrcElement: WebSocket {url: 'ws://websocket', readyState: 3, bufferedAmount: 0, onopen: ƒ, onerror: ƒ, …}target: WebSocket {url: 'ws://websocket', readyState: 3, bufferedAmount: 0, onopen: ƒ, onerror: ƒ, …}timeStamp: 203.5type: "error"

一、什么是灰度发布想象一下，你有一家生意火爆的餐厅，想要尝试推出一道新的招牌菜。但你又担心这道菜万一不受欢迎，会影响整个餐厅的声誉和生意。于是，你决定先只在一部分餐桌上提供这道新菜，观察顾客的反应。如果反响不错，再逐步推广到所有餐桌；如果反响不佳，就有时间对菜品进行调整和改进。在软件开发中，灰度发布的概念与此类似。它是一种逐步将新版本的应用或功能推送给部分用户，在收集反馈和验证稳定性后，再决定是否全面推广的策略。通过灰度发布，可以降低新版本上线带来的风险，及时发现并解决可能出现的问题，保障用户体验和业务的连续性。二、Nginx 在灰度发布中的角色Nginx 就像是一个智能的交通指挥员，它位于用户请求和后端服务之间，负责对请求进行分发和管理。在灰度发布中，Nginx 可以根据我们设定的规则，将请求有针对性地路由到不同的版本的服务上，从而实现对灰度流量的精确控制。三、Nginx 实现灰度发布的常见方法（一）基于权重的灰度发布这就好比是在一个水果摊上，苹果和香蕉的受欢迎程度不同，摊主会根据经验给它们分配不同的摆放面积（权重）。在 Nginx 中，我们可以为不同版本的服务设置不同的权重，来控制请求被分配到各个版本的比例。假设我们有两个版本的服务，旧版本（V1）和新版本（V2）。我们希望先将 20%的请求分配到新版本进行测试，那么可以在 Nginx 的配置中进行如下设置： upstream backend {     server v1.example.com weight=80;     server v2.example.com weight=20; }  server {     listen 80;     location / {         proxy_pass http://backend;     } } 在上述配置中，Nginx 会按照 80:20 的比例将请求分发到旧版本（V1）和新版本（V2）的服务上。随着新版本的表现越来越稳定，我们可以逐步增加新版本的权重，直到最终将所有请求都切换到新版本。（二）基于 Cookie 的灰度发布这就像是给用户发放了一张特殊的“入场券”，只有持有特定“入场券”的用户才能体验到新的服务。在 Nginx 中，我们可以通过读取用户请求中的 Cookie 信息，来决定将请求路由到哪个版本的服务。首先，在应用端设置一个标识用户是否参与灰度测试的 Cookie，例如 is_gray=1 表示参与，is_gray=0 表示不参与。然后在 Nginx 中进行如下配置： upstream backend {     server v1.example.com;     server v2.example.com; }  map $http_cookie $backend_version {     default v1.example.com;     "~*is_gray=1" v2.example.com; }  server {     listen 80;     location / {         proxy_pass http://$backend_version;         proxy_cookie_path / /;     } } 当用户的请求中带有 is_gray=1 的 Cookie 时，Nginx 会将请求路由到新版本（V2）的服务；否则，请求将被路由到旧版本（V1）的服务。（三）基于请求头的灰度发布这类似于在机场安检时，工作人员根据乘客的登机牌上的特殊标记来决定其通行路线。在 Nginx 中，我们可以根据请求头中的特定字段来实现灰度发布。假设我们在应用端设置了一个请求头 X-Gray-User: 1 来标识参与灰度测试的用户。在 Nginx 中，可以这样配置： upstream backend {     server v1.example.com;     server v2.example.com; }  map $http_x_gray_user $backend_version {     default v1.example.com;     "1" v2.example.com; }  server {     listen 80;     location / {         proxy_pass http://$backend_version;     } } 如果请求头 X-Gray-User 的值为 1，Nginx 会将请求路由到新版本（V2）的服务；否则，请求将被路由到旧版本（V1）的服务。（四）基于 IP 地址的灰度发布这有点像小区门口的保安，根据居民的门牌号（IP 地址）来决定是否允许其进入特定区域。在 Nginx 中，我们可以根据用户的 IP 地址来控制请求的路由。例如，我们希望只有特定 IP 段（如 192.168.1.0/24）的用户能够访问新版本的服务，可以这样配置： upstream backend {     server v1.example.com;     server v2.example.com; }  geo $remote_addr $backend_version {     default v1.example.com;     192.168.1.0/24 v2.example.com; }  server {     listen 80;     location / {         proxy_pass http://$backend_version;     } } 当用户的 IP 地址属于 192.168.1.0/24 这个网段时，Nginx 会将请求路由到新版本（V2）的服务；否则，请求将被路由到旧版本（V1）的服务。四、灰度发布的实践案例为了让大家更直观地理解 Nginx 灰度发布的实际应用，咱们来看一个具体的案例。假设我们有一个电商网站，正在对购物车功能进行重大升级。我们决定采用基于权重的灰度发布策略来逐步推出新功能。首先，我们将新版本的购物车服务部署到 v2.example.com ，旧版本的服务仍然运行在 v1.example.com 。然后，在 Nginx 中进行如下配置： upstream cart {     server v1.example.com weight=80;     server v2.example.com weight=20; }  server {     listen 80;     location /cart/ {         proxy_pass http://cart;     } } 这样，一开始只有 20%的用户在访问购物车时会使用到新版本的服务。我们密切关注这部分用户的反馈和系统的性能指标，如响应时间、错误率等。如果在一段时间内，新版本的服务表现稳定，没有出现明显的问题，我们可以逐步增加新版本的权重，比如调整为 50:50，让更多的用户体验到新功能。upstream cart {     server v1.example.com weight=50;     server v2.example.com weight=50; } 通过这样逐步推进的方式，我们既能够及时发现并解决新功能可能带来的问题，又不会对所有用户造成太大的影响，保障了业务的平稳运行。五、灰度发布中的注意事项在实施灰度发布的过程中，就像走钢丝一样，需要小心翼翼，注意以下几个关键事项：（一）数据一致性在灰度发布期间，不同版本的服务可能会处理相同的数据。这就好比两个厨师同时烹饪一道菜，很容易出现口味不一致的情况。因此，要确保不同版本的服务对数据的处理逻辑是一致的，避免出现数据混乱的问题。（二）监控与反馈要建立完善的监控体系，实时监测灰度版本的服务性能、用户行为等指标。同时，要积极收集用户的反馈，就像倾听顾客对新菜品的评价一样，及时发现问题并进行调整。（三）回滚机制俗话说，“不怕一万，就怕万一”。万一灰度发布过程中出现了严重的问题，要有快速回滚的机制，能够在最短的时间内恢复到旧版本的服务，保障业务的正常运行。（四）沟通与协调灰度发布涉及到开发、测试、运维等多个团队，需要保持良好的沟通与协调，确保各个环节的工作能够顺利进行。六、总结灰度发布是一种在软件开发中降低风险、保障用户体验的有效策略。而 Nginx 作为强大的反向代理服务器，为我们实现灰度发布提供了多种灵活的方法。通过合理地运用这些方法，并注意实施过程中的关键事项，我们能够在不断创新和优化软件的道路上走得更加稳健，为用户提供更加优质、可靠的服务。就像建造一座高楼大厦，每一块砖头都需要精心放置，每一个步骤都需要谨慎操作。灰度发布就是我们在软件这座大厦建设过程中的精心规划和稳步推进，让我们的软件在不断进化的同时，始终保持坚固和稳定。

Nginx 模块介绍HTTP 模块： HTTP模块提供了处理HTTP请求的功能，包括反向代理、负载均衡、缓存、HTTP代理等。例如：proxy模块用于反向代理和负载均衡，fastcgi模块用于处理FastCGI请求。Stream 模块： Stream模块用于处理TCP和UDP流量，允许Nginx作为代理服务器处理非HTTP流量。例如：stream模块用于配置TCP代理和负载均衡。# 修改 nginx 主配置文件 vim /etc/nginx/nginx.conf cd /etc/nginx/conf.d/ mkdir stream && cd stream # 创建 nginx stream 配置 vim mysql_3320.conf  upstream mysql3320 {   server 192.168.0.164:3306; }  server {   listen 3320; # 如果监听3306，远程登录的时不用加-p参数   proxy_connect_timeout 500s;   proxy_timeout 500s;   proxy_pass mysql3320; } # 重新加载配置 nginx -s reload MySQL 配置文件# IP连接限制放开 bind_address=0.0.0.0 远程连接 MySQLmysql -h <域名> -P 3320 -u root -p 

在Web开发中，HTTP 413 Request Entity Too Large错误常常出现在客户端发送的请求体超过服务器允许的大小限制时。本文详细解析了这种错误的成因，包括服务器配置、应用层设置及反向代理的限制，并提供了一系列调试和解决方案。本文涵盖了如何在Nginx和Apache服务器中调整配置，修改Spring Boot和Node.js等应用的请求体限制，以及适当配置反向代理和负载均衡器。通过实际示例，读者可以学会如何应对和解决HTTP 413错误，确保系统能够稳定、高效地处理大文件上传和数据请求，从而提升用户体验和系统性能。一、什么是413 Request Entity Too Large错误？1. 当前HTTP 413错误的定义HTTP 413错误表示请求体大于服务器允许的最大大小。这个限制可以由服务器配置（如Nginx、Apache等）或应用自身（如Java、Node.js等）来控制。2. 现象与影响当HTTP 413错误发生时，客户端通常会收到一条“Request Entity Too Large”的错误信息，表示请求被拒绝并且服务器不会处理该请求。这对于用户体验和系统功能性都会带来负面影响，特别是在文件上传和数据提交这种场景。二、为什么会产生413错误？1. 服务器限制413错误大多数情况下源于服务器的配置限制。服务器通常会设置一个最大请求体大小以保护其自身免受资源消耗过度的攻击。Nginx：通过 client_max_body_size 指令进行限制。Apache：通过 LimitRequestBody 指令进行控制。2. 应用层限制在某些情况下，应用程序本身也会设置请求体的大小限制。例如，Java的Servlet、Spring Boot以及许多其他框架和库都有自己的大小限制参数。3. 反向代理/负载均衡设置在使用反向代理或负载均衡时，也可能设置了请求大小的限制。三、如何调试和解决413错误？1. 修改Nginx配置1.1 修改配置文件在Nginx中，client_max_body_size指令默认限制为1MB，可以通过配置文件进行调整： http {     client_max_body_size 10M;  # 设置为10MB }  server {     client_max_body_size 10M;  # 设置为10MB }  location /upload {     client_max_body_size 10M;  # 设置为10MB } 1.2 重载Nginx配置修改配置文件后，重载Nginx配置使之生效：sudo nginx -s reload 2. 修改Apache配置2.1 修改配置文件在Apache中，可以通过 LimitRequestBody 指令进行控制，设置为10MB：2.2 重启Apache服务器修改配置文件后，重启Apache服务器使之生效：3. 修改应用配置3.1 Spring Boot示例在Spring Boot中，修改application.properties文件，增加如下配置：spring.servlet.multipart.max-file-size=10MB spring.servlet.multipart.max-request-size=10MB 4. 配置反向代理/负载均衡器4.1 例子：Nginx反向代理如果Nginx作为反向代理服务器，你需要确保在主要服务器配置和反向代理服务器配置中都设置了 client_max_body_size： # 主服务器配置 http {     client_max_body_size 10M;  # 设置为10MB }  # 反向代理配置 server {     location / {         proxy_pass http://backend_server;         proxy_set_header X-Real-IP $remote_addr;         proxy_set_header Host $host;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         client_max_body_size 10M;  # 设置为10MB     } } 

如何完美解决 Nginx出现 404 Not Found nginx/1.23.4 解决方案摘要在Nginx配置过程中，404 Not Found错误是一个常见问题。本文将详细解析Nginx 404 Not Found的原因及解决方案，确保您能够轻松解决这一问题。通过本篇文章，您将了解Nginx配置的细节，掌握快速定位和修复404错误的方法，提升服务器的稳定性和用户体验。引言作为一名全栈工程师，Nginx是我们日常工作中不可或缺的工具。然而，在配置Nginx时，难免会遇到404 Not Found的问题，这不仅影响用户访问体验，还可能导致业务中断。今天，我们将深入探讨Nginx 404 Not Found错误的原因及其解决方案，帮助大家快速定位问题并实施修复。正文 404 Not Found错误的原因分析404 Not Found错误表示服务器无法找到请求的资源。造成这一问题的原因可能有很多，常见的包括：配置文件错误：Nginx的配置文件中路径或文件名错误。权限问题：Nginx进程对请求的资源没有适当的权限。符号链接问题：请求的资源是一个符号链接，但链接指向的目标不可用或没有权限。文件不存在：请求的文件确实不存在。配置文件检查检查Nginx配置文件首先，我们需要检查Nginx的配置文件（通常位于/etc/nginx/nginx.conf或/etc/nginx/conf.d/目录中）。确保文件路径和名称正确无误。server {     listen 80;     server_name example.com;          location / {         root /var/www/html;         index index.html index.htm;     }          error_page 404 /404.html;     location = /404.html {         internal;     } } 路径和文件名确保配置文件中的root和index指令正确指向存在的路径和文件。权限设置检查文件权限Nginx进程需要对请求的文件具有读取权限。我们可以使用以下命令检查文件权限：1ls -la /var/www/html确保文件和目录的权限设置合理，例如：12chmod 755 /var/www/htmlchmod 644 /var/www/html/index.html符号链接问题如果请求的资源是一个符号链接，确保链接指向的目标存在并且有适当的权限。1ls -l /var/www/html/symlink文件不存在如果请求的文件不存在，需要创建该文件或修改配置以指向正确的文件。1touch /var/www/html/index.htmlQA环节Q: 为什么我修改了配置文件，还是404错误？A: 确保修改后重新加载Nginx配置文件：1sudo nginx -s reloadQ: 如何检查Nginx日志来定位问题？A: Nginx的错误日志通常位于/var/log/nginx/error.log。可以使用以下命令查看日志：1tail -f /var/log/nginx/error.log小结通过以上步骤，我们可以有效地解决Nginx的404 Not Found错误。无论是配置文件错误、权限问题、符号链接问题还是文件不存在，都可以通过细致的检查和合理的调整来解决。

前言Nginx 的 socket 代理通常指的是 Nginx 通过 stream 模块来处理非 HTTP 的 TCP 流量，比如数据库连接、SSH 连接或其他 TCP 协议的流量。stream 模块允许 Nginx 作为一个反向代理来处理这些连接。简单的 Nginx stream 代理配置以下是一个简单的 Nginx stream 代理配置示例，用于代理 TCP 连接：1234567891011121314events {      worker_connections  1024;  }     stream {      server {          listen <local_port>;  # Nginx 监听的本地端口          proxy_pass <backend_server>:<backend_port>;  # 后端服务器的地址和端口             # 可选配置项          # proxy_connect_timeout 1s;  # 连接超时时间          # proxy_timeout 10m;        # 代理超时时间      }  }在这个配置中，你需要替换 <local_port> 为 Nginx 将要监听的本地端口，以及 <backend_server> 和 <backend_port> 为实际的后端服务器地址和端口。负载均衡配置stream 模块还支持负载均衡。你可以使用 upstream 块来定义一组后端服务器，然后在 server 块中引用这个 upstream 块。12345678910111213141516stream {      upstream backend_servers {          server backend1.example.com:12345;          server backend2.example.com:12345;          # 可以添加更多服务器             # 可选配置项          # hash $remote_addr;  # 根据客户端 IP 进行哈希负载均衡          # least_conn;         # 使用最少连接数的服务器      }         server {          listen <local_port>;          proxy_pass backend_servers;      }  }注意几点：stream 模块：确保你的 Nginx 版本支持 stream 模块。较新版本的 Nginx 默认包含这个模块。非 HTTP 流量：stream 模块处理的是 TCP 流量，不是 HTTP 流量。因此，它不适合代理 web 请求。安全性：当你代理敏感数据（如数据库连接）时，请确保使用加密连接（如 SSL/TLS），并在 Nginx 配置中启用相应的加密选项。负载均衡：除了简单的代理功能外，你还可以使用 stream 模块来实现 TCP 连接的负载均衡。这可以通过在 upstream 块中定义多个后端服务器来实现。日志和监控：与 HTTP 代理一样，你也可以为 stream 代理配置日志和监控功能，以便跟踪和调试连接问题。一、编译安装支持stream 模块的Nginx1.安装必要的编译工具和依赖项在 CentOS 7 上，您可以使用以下命令安装这些工具：1sudo yum install gcc-c++ pcre-devel zlib-devel make2. 下载Nginx源代码下载 Nginx 1.24.0 的源代码压缩包，并解压缩：12wget http://nginx.org/download/nginx-1.24.0.tar.gztar -zxvf nginx-1.24.0.tar.gz改名mv nginx-1.24.0 nginxSrc3. 配置编译选项进入 Nginx 源代码目录并运行configure脚本，指定所需的stream功能模块。4. 编译和安装123456789[root@td66 nginxSrc]# make && make installmake -f objs/Makefilemake[1]: 进入目录“/usr/local/nginxSrc”cc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g  -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs \    -o objs/src/core/nginx.o \    src/core/nginx.ccc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g  -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs \    -o objs/src/core/ngx_log.o \    src/core/ngx_log.c5. 启动 Nginx12cd /usr/local/nginx/sbin/./nginx6. 验证安装打开您的 Web 浏览器并访问服务器的 IP 地址或域名，您应该能够看到 Nginx 的欢迎页面。二、Nginx命令nginx 命令用于控制 Nginx 服务器的启动、停止、重新加载配置文件等操作。以下是一些常用的 nginx 命令及其说明：1. 启动 Nginx1nginx这个命令将启动 Nginx 服务器。如果配置文件（通常是 /etc/nginx/nginx.conf 或 /usr/local/nginx/conf/nginx.conf）存在且没有语法错误，Nginx 将开始监听配置的端口，并处理请求。2. 停止 Nginx1nginx -s stop或者1sudo service nginx stop或者在某些系统上1sudo systemctl stop nginx这些命令将停止正在运行的 Nginx 服务器。-s stop 选项发送一个信号给 Nginx 主进程，让它立即停止。3. 重新加载配置1nginx -s reload或者1sudo service nginx reload或者在某些系统上1sudo systemctl reload nginx这个命令将重新加载 Nginx 的配置文件。如果配置文件有变动，这个命令将应用新的配置，而不需要停止和重新启动 Nginx。重新加载配置通常不会导致正在处理的请求中断。4. 测试配置文件的语法1nginx -t这个命令将检查 Nginx 配置文件的语法是否正确，并返回结果。如果配置文件有语法错误，nginx -t 会指出错误的位置，但不会实际加载配置。5. 显示版本信息1nginx -v这个命令将显示当前安装的 Nginx 的版本信息。6. 显示编译选项1nginx -V这个命令将显示 Nginx 在编译时使用的选项和包含的模块。这对于诊断问题或了解特定模块是否已编译非常有用。7. 其他常用命令查看帮助信息：nginx -h 或 nginx --help平滑升级 Nginx：可以使用 nginx -s quit 来优雅地关闭旧版本的 Nginx，然后启动新版本。请注意，上述命令可能需要使用 sudo 来获取管理员权限，具体取决于你的系统设置和 Nginx 的安装方式。此外，不同系统或安装方式可能会使用不同的服务管理器（如 systemctl、service 或 /etc/init.d/nginx 脚本），所以停止和启动服务的命令可能有所不同。三、Nginx stream配置3.1 编辑nginx.conf文件vim nginx.conf1234567891011121314151617181920#user  nobody;worker_processes  1;#error_log  logs/error.log;#error_log  logs/error.log  notice;#error_log  logs/error.log  info;#pid        logs/nginx.pid;events {    worker_connections  1024;}stream {      server {          listen 6666;  # Nginx 监听的端口          proxy_pass 10.68.8.70:6666;  # 后端服务器的地址和端口      }  }3.2检查配置文件是否正确1nginx -t -c nginx.conf如果报如下错误说明没有成功安装stream模块1nginx: [emerg] unknown directive "stream" in /usr/local/nginx/conf/nginx.conf:163.3 使配置文件生效1nginx -s reload

nginx12345678location ^~ /task/ {      # 这样，当您访问 http://hostname:port/task/test 时，    # 请求会被转发到 proxy_pass /test，注意 /task/ 前缀在转发时被去掉了。    proxy_pass http://127.0.0.1:8080/;      proxy_set_header Host $host;      proxy_set_header X-Real-IP $remote_addr;      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  }当您希望保留原始请求的 URI 时，您应该在 proxy_pass 指令中使用 ; 来结束地址部分，然后在后面添加 proxy_set_header Host $host; 来确保请求头的 Host 字段被正确设置。请注意，我在 proxy_pass 指令的末尾添加了一个斜杠 /。这是非常重要的，因为它告诉 Nginx 在转发请求时去掉匹配的前缀（在这个例子中是 /task/）。如果省略了这个斜杠，Nginx 会将完整的原始 URI（包括 /task/ 前缀）转发到后端服务器。补充Nginx 的匹配顺序是基于配置文件中的 location 块和它们的指令前缀。下面是 Nginx 匹配顺序的详细说明：精确匹配：如果请求的 URI 与 location 块中的路径完全匹配（以 = 开头），则 Nginx 会选择该 location 块进行处理。最长前缀匹配：如果没有精确匹配，Nginx 会进行最长前缀匹配。它会选择路径最长的 location 块，其中路径可以是普通字符串（不带 ^~ 或正则表达式）或带有 ^~ 前缀的路径。如果找到以 ^~ 开头的 location 块，Nginx 会立即停止搜索并使用该块，即使存在其他更长的普通字符串路径。正则表达式匹配：如果最长前缀匹配未找到匹配的 location 块，Nginx 会检查以 ~ 或 ~* 开头的 location 块，这些块使用正则表达式来匹配请求的 URI。~ 表示区分大小写的正则表达式匹配，而 ~* 表示不区分大小写的匹配。Nginx 会按照配置文件中的顺序逐个检查这些正则表达式，直到找到第一个匹配的 location 块。默认处理：如果以上三个步骤都没有找到匹配的 location 块，Nginx 会使用默认的 location 块。默认的 location 块通常是一个以 / 开头的普通字符串路径，它会匹配所有未被其他 location 块捕获的请求。以下是一个简单的示例配置，展示了 Nginx 的匹配顺序：123456789101112131415161718192021222324server {    listen 80;    server_name example.com;    location = /exact-match {        # 处理精确匹配的请求    }    location ^~ /prefix-match {        # 处理以 "prefix-match" 开头的最长前缀请求    }    location / {        # 处理所有其他请求    }    location ~* \.php$ {        # 处理所有以 ".php" 结尾的请求，不区分大小写    }    location ~ \.jpg$ {        # 处理所有以 ".jpg" 结尾的请求，区分大小写    }}在这个示例中，如果请求是 /exact-match，Nginx 会选择第一个 location 块。如果请求是 /prefix-match/something，Nginx 会选择第二个 location 块，因为 ^~ 前缀指定了最长前缀匹配。对于所有其他请求，Nginx 会按照配置文件中的顺序继续检查正则表达式匹配，或者最终使用默认的第三个 location 块。

要通过Nginx实现多个域名和集群，你需要配置Nginx作为反向代理服务器，将来自不同域名的请求转发到集群中的相应后端服务器。下面是一个基本的配置示例，你可以根据自己的需求进行修改和扩展。首先，确保你已经安装了Nginx，并且具有适当的访问权限来编辑Nginx的配置文件。1、打开Nginx的配置文件，通常位于/etc/nginx/nginx.conf或/etc/nginx/conf.d/default.conf。2、在配置文件中，找到http块，这是Nginx处理HTTP请求的主要部分。3、在http块内，为每个域名创建一个server块。每个server块将处理来自特定域名的请求。以下是一个示例配置，其中包含两个域名（example1.com和example2.com）的server块：12345678910111213141516171819202122232425262728293031323334353637383940http {      # 第一个域名的server块      server {          listen 80;          server_name example1.com;             location / {              proxy_pass http://backend_cluster1;              proxy_set_header Host $host;              proxy_set_header X-Real-IP $remote_addr;              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;          }      }         # 第二个域名的server块      server {          listen 80;          server_name example2.com;             location / {              proxy_pass http://backend_cluster2;              proxy_set_header Host $host;              proxy_set_header X-Real-IP $remote_addr;              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;          }      }         # 配置集群的上游服务器      upstream backend_cluster1 {          server backend1_ip_address;          server backend2_ip_address;          # 可以添加更多后端服务器      }         upstream backend_cluster2 {          server backend3_ip_address;          server backend4_ip_address;          # 可以添加更多后端服务器      }  }在上面的示例中，server_name指令用于指定域名，proxy_pass指令用于将请求转发到相应的集群。upstream块用于定义集群中的后端服务器列表。确保将backend_ip_address替换为实际的后端服务器IP地址或主机名。4、保存并关闭配置文件。5、检查Nginx配置文件的语法是否正确1sudo nginx -t如果没有错误消息显示，表示配置文件语法正确。6、重新加载Nginx配置，使更改生效：1sudo nginx -s reload现在，Nginx将根据配置文件中定义的规则，将来自不同域名的请求转发到相应的集群中。

其实有很多方式，网上看到一个这个方法，给大家介绍一下。首先，开启支持-TLS SNI support什么是SNI？传统的应用场景中，一台服务器对应一个IP地址，一个域名，使用一张包含了域名信息的证书。随着云计算技术的普及，在云中的虚拟机有了一个IP，对应多个域名，使用多张证书的应用场景，SNI技术应运而生。SNI（Server Name Indication），即实现了一个服务器使用多个域名证书的TLS扩展，支持用户配置多个域名证书。SNI请求特点HTTP请求的Host字段在请求的Header中。发起HTTPS请求时，在TLS握手阶段，还无法进行HTTP数据的解析，此时TLS协议的Client Hello字段新增了一个Server Name字段，请求的客户端可以通过这个字段填充请求的Host信息，而服务端在TLS握手阶段就可以选择请求处理的证书，实现SNI的功能。支持-TLS SNI supportNginx支持单IP多域名SSL证书需要OpenSSL支持，首先需要编译安装一个高版本的openssl。Nginx支持SNI，允许在同一个TLS服务端口下，配置不同的域名，用户通过请求不同的证书域名，可返回相应的upstream响应结果。检查nginx是否支持TLS SNI support：12/usr/local/nginx/sbin/nginx -Vnginx version: nginx/1.10.2TLS SNI support disabledconfigure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_moduleTLS SNI support disabled 这样是不支持的。下面开始升级openssl：123456wget ftp://ftp.openssl.org/source/openssl-1.0.2h.tar.gztar xzvf openssl-1.0.2h.tar.gzcd openssl-1.0.2h./config --prefix=/usr/local/openssl/ enable-shared enable-tlsextmake && make install[root@localhost ~]# /usr/local/nginx/sbin/nginx -V  nginx version: nginx/1.10.2  built by gcc 4.1.2 20080704 (Red Hat 4.1.2-55)  built with OpenSSL 1.0.2h  21 Dec 2016  TLS SNI support enabled  configure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-openssl=/usr/local/openssl --with-http_stub_status_module --with-http_ssl_module --with-http_v2_module  方法1：多server配置不同证书和域名123456789101112131415161718192021server  {        listen 443;        server_name   *.www.aabb.com;        index index.html index.htm index.php;        root  /data/wwwroot/www.aabb.com/webroot;        ssl on;        ssl_certificate "/usr/local/nginx/conf/ssl/_.www.aabb.com.public.cer";        ssl_certificate_key "/usr/local/nginx/conf/ssl/_.www.aabb.com.private.key";    ......}   server  {        listen 443;        server_name   www.aabb.com;        index index.html index.htm index.php;        root  /data/wwwroot/www.aabb.com/webroot;        ssl on;        ssl_certificate "/usr/local/nginx/conf/ssl/www.aabb.com.public.cer";        ssl_certificate_key "/usr/local/nginx/conf/ssl/www.aabb.com.private.key";    ......}方法2：根据ssl_server_name判断配置ssl_server_name例子1：对于nginx多https站点通常的做法是这样：12345server 443 ssl;server_name nixops1.me;ssl_certificate     /usr/local/nginx/keys/nixops1.me.crt;ssl_certificate_key /usr/local/nginx/keys/nixops1.me.key;......如果有多个https站点，就是每个站点复制一份这个配置。如nixops2.me、nixops3.me等等，在只有几十个https站点的时候还好，如果某个站点的域名特别多，例如有几千个域名甚至上万个域名的时候，这个配置就很恐怖了，需要精简并合并配置。下面举例说明，假设应用场景为：同一站点有大量域名需要配置https证书，其它配置一样每个之证书都是泛域名证书，如let's encrypt的wildcard证书所有证书命名均为公钥domain.com.crt、私钥为domain.com.key 这样的格式所有证书保存在相同目录中，如/usr/local/nginx/conf/keys/具体做法可以用nginx的map和正则表达式，根据ssl_server_name（即https的访问域名），获取公钥和私钥的完整路径做为变量。配置证书时使用该变量即可。先来看nginx配置文件中HTTP段的map配置：123456789map $ssl_server_name $NixopsCert {    default /usr/local/nginx/conf/keys/nixops.me.crt; #指定一个默认的证书    ~*^(.+\.)*([^\.]+\.[^\.]+)$ /usr/local/nginx/conf/keys/$2.crt;}map $ssl_server_name $NixopsKey {    default /usr/local/nginx/conf/keys/nixops.me.key;    ~*^(.+\.)*([^\.]+\.[^\.]+)$ /usr/local/nginx/conf/keys/$2.key;}这样配置好后，如果通过https访问nixops1.me或*.nixops1.me，获取到的路径分别为：12$NixopsCert  --> /usr/local/nginx/conf/keys/nixops1.me.crt;$NixopsKey   --> /usr/local/nginx/conf/keys/nixops1.me.key;然后配置server段证书公钥和私钥时就不需要按传统作法复制配置，只需指定变量即可：12345678910111213141516server {    listen  80;    listen  443 ssl http2;    server_name        nixops.me        nixops1.me        nixops2.me        #......    ;    ssl_certificate     $NixopsCert;    ssl_certificate_key $NixopsKey;    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;   #其它server段配置}这样同一站点有多个证书时，就可以只在server_name里添加，不需要指定https配置了，和http站点添加域名绑定非常类似。