nginx安装12sudo apt updatesudo apt install nginxnginx配置文件/etc/nginx/nginx.conf或/etc/nginx/sites-available/default设置缓存在Nginx配置中启用缓存，这样可以缓存CDN服务器上的静态内容，以提高性能和速度。1234567891011121314151617181920212223http {    # 在http段下设置缓存路径    proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;                     # 设置缓存的过期时间    proxy_cache_valid 200 302 10m;    proxy_cache_valid 404 1m;     # 设置代理缓存使用的密钥和缓存的最大大小    proxy_cache_key "$scheme$request_method$host$request_uri";     server {        # 其他服务器设置        location / {            # 使用代理缓存            proxy_cache my_cache;//启用缓存            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;            proxy_cache_bypass $http_cache_control;//http头            proxy_ignore_headers Cache-Control;            proxy_pass http://backend_server;//后端数据源服务器        }    }}正向代理（Forward Proxy）和反向代理（Reverse Proxy）是网络通信中两种常见的代理服务器类型：方向：正向代理面向客户端，反向代理面向服务器。位置：正向代理位于客户端旁边，反向代理位于服务器旁边。作用：正向代理用于客户端访问控制和匿名访问，反向代理用于负载均衡和安全性。目的：正向代理帮助客户端“前进”访问互联网，反向代理帮助服务器“反向”处理外部请求。设置域名为你的CDN服务器配置域名并确保域名正确解析到你的服务器，你需要按照以下步骤操作：步骤1：域名注册和购买选择一个域名注册商，如GoDaddy、Namecheap、阿里云等。搜索你想要注册的域名，确保它是可用的。完成购买流程并支付相应的费用。步骤2：DNS管理登录你的域名注册商的控制面板。找到DNS管理或域名管理的部分。步骤3：设置DNS记录A记录：创建一个A记录将域名指向你的CDN服务器的公网IP地址。例如，如果你的CDN服务器IP是1.2.3.4，创建一个A记录，将yourdomain.com指向1.2.3.4。CNAME记录：如果需要将子域名重定向到CDN服务器，可以创建CNAME记录。例如，cdn.yourdomain.com可以CNAME到yourdomain.com。步骤4：在CDN服务器上配置Web服务器确保你的CDN服务器上安装了Web服务器软件，如Nginx或Apache。配置Web服务器，使其能通过你的域名来提供服务。例如，在Nginx中，你需要配置一个server块来监听80端口（HTTP）或443端口（HTTPS）：123456789server {    listen 80;    server_name www.yourdomain.com;    root /path/to/your/web/root;    index index.html index.htm;    location / {        try_files $uri $uri/ =404;     } }如果你使用了SSL/TLS证书，确保配置了HTTPS并监听443端口。步骤5：部署SSL/TLS证书（推荐）如果你想启用HTTPS，可以通过Let’s Encrypt获取免费的SSL/TLS证书。安装并配置证书，使Web服务器使用SSL/TLS加密。步骤6：测试域名解析等待DNS更改全球生效，这可能需要一些时间（通常是几分钟到48小时）。使用命令行工具如ping或nslookup来检查域名是否已经指向了正确的IP地址。步骤7：验证配置在Web浏览器中输入你的域名，看是否能够成功访问你的CDN服务器上的内容。检查Web服务器的访问日志，确认有来自不同地区的访问记录。步骤8：监控和维护定期检查域名的DNS记录和CDN服务器的状态，确保一切正常运行。完成以上步骤后，你的域名就应该正确地指向你的CDN服务器，并且用户可以通过该域名访问你的网站内容了。记得在进行任何更改时，都要仔细检查配置文件的语法，并在保存更改后重新启动Web服务器。启用Gzip压缩：启用Nginx的Gzip压缩功能，以减小传输内容的大小，提高网站的加载速度。你可以在Nginx配置文件中添加以下内容：1234http {    gzip on;    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;}设置内容源：配置Nginx以从你的源服务器(通常是你的网站服务器)获取内容。你可以使用proxy_pass指令将请求转发到源服务器。12345678910proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g;server {    ...    location / {        proxy_pass http://backend;        proxy_cache my_cache;        proxy_cache_bypass $http_cache_control;        ...    }}测试和调优：完成上述配置后，测试你的CDN服务器，确保它按预期工作。你可能需要根据实际情况对配置进行调整以优化性能。常见如何调优CDN：调优CDN（内容分发网络）通常需要综合考虑多种因素，包括缓存策略、节点选择、网络优化等。以下是一些具体的调优步骤和例子：1. 缓存策略调优：例子：如果你的网站有大量的静态资源，如图片、CSS和JavaScript文件，可以通过设置更长的`Cache-Control`头部值来提高缓存命中率。例如，可以在Nginx中设置：123location ~* \.(jpg|jpeg|png|gif|js|css)$ {        expires 30d;    }2. 节点选择优化：例子：使用CDN提供商的地理DNS或任意cast DNS功能，将用户定向到最近的服务器节点，减少延迟。例如，在阿里云CDN中，可以配置DNS解析策略，确保用户就近访问。3. 内容预热：例子：在新产品发布前，使用CDN的内容预热功能，提前将资源分发到各个边缘节点，避免在高流量时段对源站造成压力。4. 动态内容优化：例子：对于频繁变动的内容，可以配置CDN缓存为较短的过期时间或使用“no-cache”指令，以确保用户获取最新数据。5. HTTPS优化：例子：启用SSL/TLS加速功能，如使用SPDY或HTTP/2协议，减少HTTPS握手时间。同时，确保CDN支持OCSP Stapling，减少SSL证书验证时间。6. 网络连接优化：例子：如果`traceroute`显示用户到CDN节点的路由路径不理想，可以联系CDN提供商优化路由策略。7. 资源压缩：例子：启用Gzip压缩，减少传输数据的大小。在Nginx中可以设置：123location ~* \.(html|css|js|json|xml|ld\+json|ejs|svg|png|jpg|jpeg|gif|ico)$ {         gzip on;     }8. HTTP/2 启用：例子：在支持HTTP/2的CDN节点上启用该协议，利用其多路复用、服务器推送等特性提高性能。9. 图片优化：例子：使用CDN的图片处理功能，自动进行图片压缩和格式转换，如将JPG转换为WebP格式。10. 性能监控与日志分析：例子：定期检查CDN日志，分析错误码、访问模式和性能指标，使用工具如GoAccess或AWStats进行日志分析。11. 定制化配置：例子：根据网站特性，定制CDN的配置。例如，对于视频网站，可以配置CDN以支持视频流的平稳传输。12. 使用性能测试工具：例子：使用WebPageTest或阿里云的云拨测产品，定期测试CDN性能，分析不同条件下的性能表现。13. 故障排查：例子：如果发现某些资源加载缓慢，检查资源URL是否被CDN正确缓存，确认没有因为意外的查询字符串导致缓存失效。14. 用户行为分析：例子：分析用户访问模式，识别热门内容和高流量时段，据此调整CDN策略，如增加热门内容的缓存或在高峰时段增加带宽。通过上述调优步骤，可以显著提升CDN的性能，改善网站加载速度和用户体验。调优是一个持续的过程，需要定期进行性能测试和配置调整。对于视频网站，可以配置CDN以支持视频流的平稳传输。对于视频网站，确保视频内容的平稳传输是提升用户体验的关键。以下是一些具体的配置步骤和例子：1. 视频内容的缓存策略：例子：在Nginx中配置视频文件的缓存时间，使用`proxy_cache_valid`指令为不同类型的视频内容设置不同的缓存时间。12345location ~* \.(mp4|avi|mov)$ {        proxy_cache my_cache;        proxy_cache_valid 200 1h;        proxy_cache_valid 404 1m;    }2. 视频切片和分块传输：例子：使用Apple HLS(HTTP Live Streaming)或DASH(Dynamic Adaptive Streaming over HTTP)技术，将视频切分为多个小片段，允许客户端按需加载视频的不同部分。配置CDN以支持这些协议，确保客户端可以有效地从最近的节点请求视频切片。3. 自适应比特率流：例子：在视频服务器上启用自适应比特率流，允许客户端根据当前网络条件选择最合适的视频质量。这通常通过HLS或DASH实现。4. 内容预热：例子：对于即将发布的热门视频内容，使用CDN的内容预热功能，提前将视频内容分发到各个边缘节点，减少发布时的源站压力。5. 视频编码和压缩：例子：使用FFmpeg工具对视频进行压缩和转码，生成不同分辨率和比特率的视频流，以适应不同用户的带宽条件。1ffmpeg -i input.mp4 -c:v libx264 -crf 24 -preset veryfast -c:a aac -b:a 128k -movflags +faststart output.mp46. 启用HTTP/2：例子：在服务器上启用HTTP/2，利用其多路复用特性减少连接数，提高视频传输效率。1234567server {    listen 80;    listen 443 ssl http2;    server_name example.com;    ...    http2_push_preload on;}7. 负载均衡和故障转移：例子：在CDN配置中设置负载均衡策略，如轮询、最少连接或IP哈希，确保视频请求均匀分配到各个节点。同时，配置故障转移机制，以便在节点故障时自动切换。8. 视频播放器配置：例子：使用支持自适应比特率流的播放器，如Video.js或JW Player，并配置播放器以从CDN节点获取视频流。9. 监控和日志分析：例子：利用CDN提供商的监控工具，如AWS CloudFront的日志分析，监控视频流的性能，如请求量、错误率和传输速度。10. 带宽预留和QoS：例子：在CDN上为视频流预留足够的带宽，并设置优先级，确保在高流量时段也能保持视频传输的质量。11. 使用QUIC协议：例子：如果CDN支持QUIC协议，可以启用它以减少连接建立时间，并提高视频传输的稳定性。12. 客户端适配：例子：在视频播放器中实现网络条件自动检测，根据用户的带宽和设备性能自动选择最合适的视频质量。通过上述配置，可以显著提高视频网站的性能，减少缓冲和中断，提供更加流畅的视频观看体验。这些措施需要根据具体的CDN提供商和视频网站需求进行调整和优化。测试123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354测试CDN（内容分发网络）性能通常涉及以下几个步骤： 1. **选择测试工具**：   - 使用在线工具如WebPageTest、GTmetrix或Google PageSpeed Insights进行初步测试。   - 例子：访问WebPageTest网站，输入你的网站URL，并选择不同的测试位置和网络条件进行测试。 2. **性能基准测试**：   - 在实施任何CDN配置更改之前，进行性能基准测试，以便于后续比较优化效果。   - 例子：记录下初始的加载时间、TTFB（首字节时间）、缓存命中率等关键指标。 3. **全球性能测试**：   - 使用全球分布式的测试工具，如Akamai's CloudTest或Gomez，测试不同地理位置下的性能。   - 例子：使用CloudTest从北美、亚太和欧洲等多个地区测试网站的加载时间和响应时间。 4. **资源加载测试**：   - 使用工具如Apache JMeter或Siege模拟高并发请求，测试CDN对资源加载的处理能力。   - 例子：在JMeter中配置多个线程组模拟用户并发访问，测试CDN的负载均衡和响应能力。 5. **视频和流媒体测试**：   - 如果网站包含视频内容，使用视频特定的测试工具，如Wireshark或Nagios，监控视频流的稳定性和质量。   - 例子：使用Wireshark捕获视频流传输过程中的数据包，分析延迟和丢包情况。 6. **SSL/TLS测试**：   - 对于使用HTTPS的网站，使用SSL Labs的SSL Test工具测试CDN服务器的SSL/TLS配置。   - 例子：输入网站URL进行测试，获取SSL/TLS配置的评级和改进建议。 7. **缓存策略测试**：   - 检查CDN是否正确地实现了缓存策略，如验证`Cache-Control`和`Expires`头部。   - 例子：使用curl命令测试资源的HTTP头部信息：     ```bash     curl -I https://www.example.com/image.jpg     ``` 8. **DNS解析测试**：   - 使用`dig`或`nslookup`命令测试CDN的DNS解析速度和准确性。   - 例子：执行`dig example.com`查看DNS解析结果和时间。 9. **监控和日志分析**：   - 利用CDN提供商的监控系统，分析实时性能数据和日志文件。   - 例子：在AWS CloudFront中查看实时日志，分析请求量、错误率和流量模式。 10. **用户体验测试**：    - 使用Real User Monitoring (RUM) 工具收集真实用户的性能反馈。    - 例子：集成New Relic或Google Analytics的RUM功能，追踪实际用户的性能体验。 11. **故障转移测试**：    - 模拟网络故障，测试CDN的故障转移机制是否有效。    - 例子：使用网络模拟器如Clumsy中断连接，看CDN是否能够自动切换到健康节点。 12. **性能调优测试**：    - 根据测试结果调整CDN配置，如修改缓存时间、负载均衡策略等，然后重新测试以验证改进效果。    - 例子：在Nginx中调整缓存策略后，再次使用WebPageTest进行测试，比较前后性能差异。 通过上述步骤，你可以全面地测试CDN的性能，识别瓶颈，并根据测试结果进行调优。记住，CDN测试和调优是一个持续的过程，需要定期进行以适应网站流量和内容的变化。多路复用多路复用（Multiplexing）是一种通信方式，允许多个数据流共享单一的物理链路，通过不同的标识符区分不同的数据流。在网络协议中，多路复用计数通常指的是在多路复用上下文中，可以同时传输的独立数据流的数量。在HTTP/2协议中，多路复用是一个核心特性，它允许客户端和服务器在单一的TCP连接上同时发送多个请求和响应，从而减少了连接的建立和关闭的开销，提高了传输效率。多路复用计数的一些关键点：并行传输：在HTTP/2中，多路复用允许在同一个TCP连接上并行传输多个请求和响应，而不是像HTTP/1.x那样需要为每个请求/响应建立和关闭一个连接。流ID：每个HTTP/2的请求或响应流都被分配一个唯一的流ID，用于区分不同的数据流。性能提升：多路复用减少了连接的建立和关闭时间，减少了HTTP头部信息的冗余传输，从而提高了网页的加载速度。流优先级：HTTP/2支持流的优先级和权重，允许客户端和服务器控制不同流的传输顺序。头部压缩：HPACK算法用于压缩HTTP头部，进一步减少了数据传输量。流量控制：HTTP/2使用流控制窗口来控制数据的发送速率，避免网络拥塞。例子：假设一个网页需要加载多个资源，如HTML、CSS、JavaScript文件和图片。在HTTP/1.x中，这些资源可能需要通过多个TCP连接顺序加载。而在HTTP/2中，所有这些资源可以同时在单一的TCP连接上加载，每个资源分配一个流ID，客户端和服务器通过流ID来区分和管理这些并行的传输流。例如，客户端可能发送如下的HTTP/2请求：123456HEADERS (stream_id=1): :method: GET                   :scheme: https                   :path: /css/style.css                  :authority: www.example.com                 :priority: 1BLOCK (stream_id=1): [data for stream 1]123456HEADERS (stream_id=3): :method: GET                   :scheme: https                   :path: /js/script.js                  :authority: www.example.com                 :priority: 3BLOCK (stream_id=3): [data for stream 3]在这个例子中，流1和流3是两个独立的请求，它们通过不同的流ID进行区分，并且可以同时在单一的TCP连接上传输。总的来说，多路复用计数指的是在多路复用连接中可以打开的流的数量，它是衡量多路复用能力的一个指标。在HTTP/2中，多路复用允许更高效的数据传输，减少了网页加载时间，改善了用户体验。

这里需要注意的是一定要用$http_x_forwarded_for 这个变量123456789101112131415161718upstream myapp1 {  # 定义一个名为myapp1的服务器组          server backend1.example.com weight=5;  # 添加一个服务器，并设置权重为5          server backend2.example.com;  # 添加另一个服务器，权重默认为1          server backend3.example.com down;  # 将此服务器标记为down，不参与负载均衡          server backup1.example.com backup;  # 将此服务器作为备份服务器      }    location ^~ /api/ {        #10\.182\.(?!25\.|26\.)[0-9.]+       if ($http_x_forwarded_for ~ "^10\.182\.(25\.|26\.)[0-9.]+") {          # 如果是，返回403禁止访问          return 403;      }      proxy_set_header Host $host;      proxy_set_header X-Real-IP $remote_addr;      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;      proxy_pass myapp1;    }禁止指定网站来访：123if ($http_referer ~* "要拦截的域名") {    return 301 要跳转的域名;}限制指定目录扩展名后缀123456789location ~ ^/images/.*\.(php|php5|sh|pl|py)${deny all;} location ~ ^/static/.*\.(php|php5|sh|pl|py)${deny all;}禁止直接访问txt和doc文件12345678910location ~* \.(txt|doc)$ {if (-f $request_filename) {root /data/www/www;rewrite ^(.*) https://www.itbulu.com/ break;  #可以重定向到某个URL;}}location ~* \.(txt|doc)$ {root /data/www/www;deny all;}禁止访问文件和目录1234#禁止访问的文件或目录 location ~ ^/(\.user.ini|\.htaccess|\.git|\.svn|\.project|LICENSE|README.md) { return 404; }排除某个目录不受限制123location ~ \.well-known{ allow all; }禁止访问单个目录的命令1234567location ~ ^/(static)/ {deny all;} location ~ ^/static {deny all;}禁止访问多个目录的配置123location ~ ^/(static|js) {deny all;}禁止目录让外界访问12345678910111213location ~ ^/mysql_loging/ {allow 192.168.1.4;deny all;} location ~ .*\.(php|php5)?$ {fastcgi_pass 127.0.0.1:9000;fastcgi_index index.php;include fastcgi_params;fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;} 说明:该配置只允许192.168.1.4IP访问mysql_loging目录限制IP和IP段12345678location / {deny 192.168.0.4;allow 192.168.1.0/16;allow 10.0.0.0/24;deny all;} 说明：此限制是对某些IP做整个网站的限制访问。非指定域名访问跳转123if ($host !~ ^www/.itbulu/.com$) {rewrite ^(.*) http://www.baidu.com$1 permanent;} 到此这篇关于nginx 拦截指定ip访问指定url的实现示例的文章就介绍到这了,

背景：访问时不时会被暴力刷量，爬虫和恶意攻击导致数据库，服务等瘫痪需求：在Nginx上实现一个动态拦截IP的方法，具体是当某个IP在1分钟内访问超过60次时，将其加入Redis并拦截，拦截时间默认1天。技术选型：使用Nginx+Lua+Redis的方法。这种方案通过Lua脚本在Nginx处理请求时检查Redis中的黑名单，同时统计访问频率，超过阈值就封禁。这应该符合用户的需求。需要结合Lua脚本和Redis的计数功能。安装OpenResty，配置Nginx的Lua模块，编写Lua脚本统计访问次数，使用Redis存储和过期键，以及设置拦截逻辑。连接池的使用，避免频繁连接Redis影响性能。一、环境准备安装OpenRestyOpenResty集成了Nginx和Lua模块，支持直接运行Lua脚本：1234# Ubuntu/Debiansudo apt-get install openresty# CentOSyum install openresty安装Redis服务12sudo apt-get install redis-server  # Debian系sudo yum install redis             # RedHat系二、Nginx配置主配置文件（nginx.conf）在http块中添加共享内存和Lua脚本路径：1234567891011121314http {    lua_package_path "/usr/local/openresty/lualib/?.lua;;";    lua_shared_dict ip_limit 10m;  # 共享内存区     server {        listen 80;        server_name _;         location / {            access_by_lua_file /usr/local/lua/ip_block.lua;  # 核心拦截脚本            root /var/www/html;        }    }}三、Lua脚本实现动态拦截脚本路径创建Lua脚本：/usr/local/lua/ip_block.lua脚本内容1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162local redis = require "resty.redis"local red = redis:new() -- Redis连接参数local redis_host = "127.0.0.1"local redis_port = 6379local redis_timeout = 1000  -- 毫秒local redis_auth = nil       -- 无密码留空 -- 拦截参数local block_time = 86400     -- 封禁时间（1天）local time_window = 60       -- 统计窗口（1分钟）local max_requests = 60     -- 最大请求数 -- 获取客户端IPlocal function get_client_ip()    local headers = ngx.req.get_headers()    return headers["X-Real-IP"] or headers["x_forwarded_for"] or ngx.var.remote_addrend -- 连接Redislocal function connect_redis()    red:set_timeout(redis_timeout)    local ok, err = red:connect(redis_host, redis_port)    if not ok then        ngx.log(ngx.ERR, "Redis连接失败: ", err)        return nil    end    if redis_auth then        local ok, err = red:auth(redis_auth)        if not ok then ngx.log(ngx.ERR, "Redis认证失败: ", err) end    end    return okend -- 主逻辑local client_ip = get_client_ip()local counter_key = "limit:count:" .. client_iplocal block_key = "limit:block:" .. client_ip -- 检查是否已封禁local is_blocked, err = red:get(block_key)if tonumber(is_blocked) == 1 then    ngx.exit(ngx.HTTP_FORBIDDEN)  -- 直接返回403end -- 统计请求次数connect_redis()local current_count = red:incr(counter_key)if current_count == 1 then    red:expire(counter_key, time_window)  -- 首次设置过期时间end -- 触发封禁条件if current_count > max_requests then    red:setex(block_key, block_time, 1)   -- 封禁并设置1天过期    red:del(counter_key)                  -- 删除计数器    ngx.exit(ngx.HTTP_FORBIDDEN)end -- 释放Redis连接red:set_keepalive(10000, 100)四、性能优化Redis连接池通过set_keepalive复用连接，避免频繁建立TCP连接共享内存缓存使用lua_shared_dict缓存高频访问IP，减少Redis查询压力异步日志记录封禁操作异步写入日志文件，避免阻塞请求处理：1234567ngx.timer.at(0, function()    local log_msg = string.format("%s - IP %s blocked at %s",         ngx.var.host, client_ip, ngx.localtime())    local log_file = io.open("/var/log/nginx/blocked_ips.log", "a")    log_file:write(log_msg, "\n")    log_file:close()end)五、验证与测试手动触发封禁1234# 模拟高频请求ab -n 100 -c 10 http://your-domain.com/# 检查Redisredis-cli keys "limit:block:*"自动解封验证等待24小时后检查封禁IP是否自动删除：1redis-cli ttl "limit:block:1.2.3.4"  # 返回剩余秒数六、扩展方案分布式封禁在多台Nginx服务器间共享Redis黑名单，实现集群级拦截可视化监控通过Grafana+Prometheus展示实时拦截数据：12# 采集Redis指标prometheus-redis-exporter --redis.address=localhost:6379动态调整阈值通过Redis Hash存储不同路径的拦截规则：12local rule_key = "limit:rule:" .. ngx.var.urilocal custom_rule = red:hget(rule_key, "max_requests")引用说明核心拦截逻辑参考了Nginx+Lua+Redis的经典架构设计Redis键过期机制确保自动解封性能优化方案借鉴了OpenResty最佳实践

在生产环境中，确保Nginx在服务器重启后自动启动是非常重要的。本文将详细介绍如何在Linux系统中设置Nginx服务开机自动重启的方法，确保Nginx能够在系统启动后自动恢复运行。一、检查Nginx状态首先，检查Nginx服务的当前状态，确保Nginx已安装并正在运行。1sudo systemctl status nginx如果Nginx服务没有启动，可以使用以下命令启动：1sudo systemctl start nginx二、设置Nginx开机自动启动使用systemctl命令将Nginx服务设置为开机自动启动。1sudo systemctl enable nginx执行该命令后，Nginx服务将在系统启动时自动启动。可以通过以下命令验证：1sudo systemctl is-enabled nginx如果返回enabled，则说明Nginx服务已设置为开机自动启动。三、配置Nginx自动重启策略在某些情况下，我们可能需要确保Nginx在意外停止后自动重启。这可以通过配置systemd服务来实现。1. 创建自定义systemd服务配置文件首先，创建一个自定义的systemd服务配置文件以覆盖默认配置。1sudo systemctl edit nginx在编辑器中添加以下内容：123[Service]Restart=alwaysRestartSec=5s其中，Restart=always表示无论退出状态如何，总是重启服务。RestartSec=5s表示在5秒后重启服务。保存并退出编辑器后，重新加载systemd配置：1sudo systemctl daemon-reload2. 验证配置重新启动Nginx服务以应用新的配置：1sudo systemctl restart nginx通过以下命令验证Nginx服务的重启策略：1sudo systemctl show nginx | grep Restart如果输出包含Restart=always，说明重启策略已正确设置。四、示例：Nginx服务自动重启配置以下是一个完整的示例，演示如何配置Nginx服务在意外停止后自动重启，并在系统启动时自动启动：1. 确保Nginx服务已启动并设置为开机自动启动：12sudo systemctl start nginxsudo systemctl enable nginx2. 创建自定义的systemd服务配置文件以设置自动重启策略：1sudo systemctl edit nginx在编辑器中添加以下内容并保存：123[Service]Restart=alwaysRestartSec=5s3.重新加载systemd配置并重启Nginx服务：12sudo systemctl daemon-reloadsudo systemctl restart nginx4.验证Nginx服务的重启策略：1sudo systemctl show nginx | grep Restart五、总结通过上述步骤，我们可以在Linux系统中设置Nginx服务开机自动启动和意外停止后自动重启，确保系统重启或服务故障后Nginx能够自动恢复运行。总结一下主要步骤：使用systemctl enable nginx设置Nginx服务开机自动启动。创建自定义的systemd服务配置文件设置自动重启策略。重新加载systemd配置并重启Nginx服务

1、概述之前我们使用Keepalived实现了Nginx服务的双机主备高可用，但是有几个问题没有解决，今天一起探讨一下。1）在双机主备机制中，Keepalived服务如果宕了，会自动启用备机进行服务，但Nginx服务如果负载过大宕了，虚拟ip是不会指向备机的。2）双机主备的特点是，只有1台机器在提供服务，备机在主机的Keepalived服务宕掉后才会提供服务，大大的造成了资源的浪费。3）目前比较流行租用云服务器去运营公司的产品，那云服务器支不支持虚拟IP呢？今天我们就上述的三个问题来讲解一下。2、使用Keepalived实现Nginx的自动重启2.1 借助Shell脚本，完成Nginx的重启Keepalived不能直接启动Nginx，但可以执行shell脚本，因此这里我们需要借助Shell脚本启动Nginx。在 /etc/keepalived 目录下，新建一个脚本 check_nginx.sh，以下是脚本的具体内容：1234567891011121314#!/bin/bash # 执行查看Nginx进程的命令，并放在变量A中A=`ps -C nginx --no-header | wc -l` # 判断是否宕机，如果宕机尝试重启，如果重启不成功，则停止Keepalivedif [ $A -eq 0 ];then    /usr/local/nginx/sbin/nginx    sleep 3    if [ `ps -C nginx --no-header | wc -l` -eq 0 ];then        killall keepalived     fifi脚本来源于网络2.2 为脚本赋予运行权限1# chmod +x /etc/keepalived/check_nginx.sh2.3 在Keepalived配置文件中增加配置打开Keepalived配置文件，# vi /etc/keepalived/keepalived.conf修改配置文件，增加vrrp_script 和track_script的配置，配置如下：12345678910111213141516171819202122232425262728293031323334353637383940global_defs {       # 全局唯一的主机标识   router_id server_a    } vrrp_script check_nginx {    script "/etc/keepalived/check_nginx.sh"    interval 3 # 每隔3秒运行一次Shell脚本    weight 10 # 脚本运行成功，权重加10} vrrp_instance VI_1 {     # 标识是主节点还是备用节点，值为 MASTER 或 BACKUP    state MASTER    # 绑定的网卡    interface ens33    # 虚拟路由id，保证主备节点是一致的    virtual_router_id 51    # 权重    priority 100    # 同步检查时间，间隔默认1秒    advert_int 1    # 认证授权的密码，所有主备需要一样    authentication {        auth_type PASS        auth_pass 1111    }     track_script {        check_nginx    }     # 虚拟IP    virtual_ipaddress {        192.168.1.88    }}2.4 重启Keepalived服务重启后，发现，Nginx停掉后，很快会自动启动。3、双主热备的搭建3.1 双主热备概述由于双机主备机制，每次只会由一台服务器对外提供服务，且主备机的配置是相同的，因此极大地造成了资源的浪费。双主热备则解决了这个问题，双主热备的原理是两台服务器利用Keepalived互为主备，因此需要两个虚拟IP，再利用DNS轮询的配置，让一个域名按轮询的方式分别路由到两个虚拟IP上，最终达到高可用的目的。3.2 场景说明虚拟IP1：192.168.1.88虚拟IP2：192.168.1.66A服务器IP（主）：192.168.1.144B服务器IP（备）：192.168.1.223.3 修改A服务器配置配置如下：123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354! Configuration File for keepalived global_defs {       # 全局唯一的主机标识   router_id server_a    } vrrp_instance VI_1 {     # 标识是主节点还是备用节点，值为 MASTER 或 BACKUP    state MASTER    # 绑定的网卡    interface ens33    # 虚拟路由id，保证主备节点是一致的    virtual_router_id 51    # 权重    priority 100    # 同步检查时间，间隔默认1秒    advert_int 1    # 认证授权的密码，所有主备需要一样    authentication {        auth_type PASS        auth_pass 1111    }    # 虚拟IP    virtual_ipaddress {        192.168.1.88    }} vrrp_instance VI_2 {     # 标识是主节点还是备用节点，值为 MASTER 或 BACKUP    state BACKUP    # 绑定的网卡    interface ens33    # 虚拟路由id，保证主备节点是一致的    virtual_router_id 52    # 权重    priority 80    # 同步检查时间，间隔默认1秒    advert_int 1    # 认证授权的密码，所有主备需要一样    authentication {        auth_type PASS        auth_pass 1111    }    # 虚拟IP    virtual_ipaddress {        192.168.1.66    }}3.4 修改B服务器配置配置如下：123456789101112131415161718192021222324252627282930313233343536373839404142434445! Configuration File for keepalived global_defs {       router_id server_b    } vrrp_instance VI_1 {         # 设置为备机    state BACKUP    interface ens33    virtual_router_id 51    # 权重设置的要比主机低    priority 90    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    # 虚拟IP需要主备设置成一样    virtual_ipaddress {        192.168.1.88    }} vrrp_instance VI_2 {         # 设置为主机    state MASTER    interface ens33    virtual_router_id 52    # 权重设置的要比主机低    priority 100    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    # 虚拟IP需要主备设置成一样    virtual_ipaddress {        192.168.1.66    }}3.5 重启两台服务器的Keepalived重启Keepalived即可。3.6 设置DNS轮询联系网络运营商解决。4、云服务器的负载均衡现在，很多公司都会选择租用云服务器运行自己的产品，因为更划算、更稳定，有专业人员负责运维。但使用了云服务器，就要受云服务运营商的限制。就拿虚拟IP这个事儿来说，一些云服务运营商就是不支持的。如果不支持虚拟IP，则Keepalived这个方案就只能放弃了。但即使Keepalived用不了，Nginx的高可用还是有解决方案的，很多云服务商都已经推出了自己的负载均衡服务（例如：阿里云的负载均衡 SLB 和 腾讯云的负载均衡 CLB）。我们直接租用就好了，不需要我们自己去配置。5、综述今天大概聊了一下KeepAlived自动重启Nginx，Keepalived的双主热备高可用的搭建，以及云服务器负载均衡的解决方案，希望能对大家有所帮助。

Nginx 与 Node.js 的集成在现代 Web 开发中，Nginx 和 Node.js 是两种非常流行且高效的技术。Nginx 作为一个高性能的 Web 服务器和反向代理服务器，广泛应用于静态资源的处理、负载均衡、反向代理等场景。而 Node.js 则是一个基于事件驱动的 JavaScript 运行环境，适合构建高并发、实时的网络应用。将 Nginx 与 Node.js 集成，利用 Nginx 的反向代理功能将请求转发到 Node.js 应用中，可以有效地提升 Web 应用的性能、可扩展性和安全性。一、Nginx 和 Node.js 集成的优势1.1 高性能反向代理Nginx 是一个高效的反向代理服务器，具有出色的并发处理能力。当将 Node.js 应用部署在 Nginx 后面时，Nginx 可以作为前端的反向代理，将来自客户端的请求转发给 Node.js。这样，Nginx 负责处理静态资源（如图片、CSS、JavaScript 文件），并将动态请求（如 API 请求）转发给 Node.js 应用进行处理，减少了 Node.js 的负担。1.2 静态资源处理与负载均衡Nginx 在处理静态资源（如图像、CSS、JavaScript 等）方面的性能非常强大。它能够高效地处理大量并发请求，而 Node.js 更适合处理动态请求。将静态资源的处理交给 Nginx，可以减少 Node.js 的负担，充分发挥 Nginx 的优势。此外，Nginx 还可以作为负载均衡器，将客户端的请求按轮询、加权等方式分发到多个 Node.js 实例，提高系统的扩展性和容错能力。1.3 安全性与 HTTPS 支持Nginx 提供了非常强大的安全性功能，如访问控制、防火墙设置、请求过滤等。通过将 Nginx 作为反向代理，还可以将 HTTPS 配置和证书管理的责任交给 Nginx，而不需要将其集成到 Node.js 应用中，从而简化了 Node.js 应用的配置。1.4 WebSocket 和长连接支持Node.js 的事件驱动模型非常适合处理 WebSocket 和长连接。而 Nginx 也可以很好地支持 WebSocket 协议。通过 Nginx 转发 WebSocket 请求到 Node.js 应用，可以使得 Node.js 更专注于处理实时通信，而 Nginx 负责转发和管理连接。二、Nginx 和 Node.js 集成的工作原理在将 Nginx 与 Node.js 集成时，Nginx 作为反向代理服务器，负责接收来自客户端的请求。具体工作流程如下：客户端请求：客户端发送请求到 Nginx，通常是通过 HTTP 或 HTTPS 协议。Nginx 处理静态资源：Nginx 会处理静态资源（如 HTML、图片、CSS、JavaScript 文件），如果请求的是动态内容，则将请求转发给 Node.js。反向代理到 Node.js：Nginx 将动态请求转发到 Node.js 应用，Node.js 处理请求并返回响应。响应返回客户端：Nginx 将 Node.js 返回的响应发送给客户端，完成整个请求的处理过程。2.1 基本的反向代理设置Nginx 通过 proxy_pass 指令将请求转发到后端的 Node.js 应用。基本配置如下：server {    listen 80;    server_name example.com;    # 处理静态文件    location /static/ {        root /var/www/html;    }    # 转发 API 请求到 Node.js 应用    location /api/ {        proxy_pass http://localhost:3000;  # 假设 Node.js 应用运行在 3000 端口        proxy_http_version 1.1;  # 使用 HTTP/1.1        proxy_set_header Upgrade $http_upgrade;  # 支持 WebSocket        proxy_set_header Connection 'upgrade';        proxy_set_header Host $host;        proxy_cache_bypass $http_upgrade;    }}在上述配置中，Nginx 会将 /static/ 路径下的请求交给自己处理，而将以 /api/ 为前缀的请求转发到 Node.js 应用。proxy_pass 指令将请求转发到运行在 3000 端口的 Node.js 应用。2.2 支持 WebSocketNode.js 常用于实时应用（如聊天应用、实时通知等），这类应用通常使用 WebSocket 协议。Nginx 需要进行特别配置，才能正确地转发 WebSocket 请求。server {    listen 80;    server_name example.com;    # WebSocket 代理    location /ws/ {        proxy_pass http://localhost:3000;  # Node.js WebSocket 服务运行在 3000 端口        proxy_http_version 1.1;  # 使用 HTTP/1.1        proxy_set_header Upgrade $http_upgrade;  # 支持 WebSocket        proxy_set_header Connection 'upgrade';  # 允许升级协议        proxy_set_header Host $host;        proxy_cache_bypass $http_upgrade;    }}在 WebSocket 的配置中，Upgrade 和 Connection 头部的设置至关重要，Nginx 需要通过这些头部告知 Node.js，客户端希望通过 WebSocket 建立长连接。2.3 HTTPS 配置在生产环境中，为了保证安全性，通常会启用 HTTPS。可以将 SSL/TLS 配置留给 Nginx 处理，而 Node.js 只需处理 HTTP 请求。Nginx 配置 HTTPS 的基本方法如下：server {    listen 443 ssl;    server_name example.com;    ssl_certificate /etc/nginx/ssl/example.com.crt;    ssl_certificate_key /etc/nginx/ssl/example.com.key;    location / {        proxy_pass http://localhost:3000;  # 将请求转发给 Node.js 应用        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_certificate 和 ssl_certificate_key 指定了 SSL 证书和私钥的路径。然后，Nginx 会将所有的 HTTPS 请求转发到 Node.js 应用。三、部署 Node.js 应用在将 Nginx 与 Node.js 集成时，Node.js 应用通常需要运行在某个端口上。为保证 Node.js 在生产环境中能够高效稳定运行，通常会将其部署在后台并使用进程管理工具（如 PM2）来管理应用。3.1 使用 PM2 启动 Node.js 应用PM2 是一个功能强大的 Node.js 进程管理工具，它能够确保 Node.js 应用在崩溃后自动重启，并支持日志管理、负载均衡等功能。使用 PM2 启动 Node.js 应用的基本命令如下：pm2 start app.js  # 启动 Node.js 应用pm2 save  # 保存进程配置pm2 startup  # 配置系统开机自启123通过 PM2 启动 Node.js 应用后，Nginx 可以将请求转发到对应的端口（例如 3000 端口）。3.2 配置 Nginx 与 PM2 协同工作在 Nginx 中配置反向代理时，确保将请求转发到 PM2 管理的 Node.js 应用。例如，如果应用运行在 3000 端口，那么 Nginx 配置中的 proxy_pass 应指向 http://localhost:3000。四、常见问题与解决方案4.1 反向代理时 WebSocket 连接失败WebSocket 协议需要特殊处理，确保 Nginx 在代理时能正确地升级 HTTP 协议到 WebSocket 协议。检查以下 Nginx 配置是否正确：location /ws/ {    proxy_pass http://localhost:3000;    proxy_http_version 1.1;    proxy_set_header Upgrade $http_upgrade;    proxy_set_header Connection 'upgrade';    proxy_set_header Host $host;    proxy_cache_bypass $http_upgrade;}确保 Upgrade 和 Connection 头部被正确传递，且 WebSocket 请求的路径（如 /ws/）在 Nginx 配置中被正确匹配。4.2 Node.js 应用负载均衡如果有多个 Node.js 实例运行在不同的端口上，可以通过 Nginx 配置负载均衡，合理分配客户端请求：upstream node_app {    server 127.0.0.1:3000;    server 127.0.0.1:3001;    server 127.0.0.1:3002;}server {    listen 80;    server_name example.com;    location / {        proxy_pass http://node_app;  # 使用负载均衡        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 会将客户端请求按照轮询或加权的方式分配到多个 Node.js 实例，提升整体性能和可用性。4.3 处理 SSL 证书错误如果在配置 SSL 时遇到证书错误，可以使用 openssl 工具检查证书链是否完整。确保证书文件和私钥文件的路径正确，并且证书链包含所有中间证书。openssl s_client -connect example.com:4431通过上述命令，可以验证 SSL 证书是否配置正确。五、总结将 Nginx 与 Node.js 集成，能够充分发挥 Nginx 在静态资源处理、负载均衡和安全性上的优势，同时利用 Node.js 在动态请求和实时应用中的高效性。通过合理的配置，Nginx 可以高效地代理 Node.js 应用，优化性能并提升系统的可靠性和扩展性。————————————————                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                        原文链接：https://blog.csdn.net/Flying_Fish_roe/article/details/144523159

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