当前在我们项目的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站点添加域名绑定非常类似。

Nginx的流式响应配置使用ChatGPT的能力在聊天时来实现打字机效果，因此需要服务端接口进行流式响应，碰到了几个问题：1、服务端明明配置了响应头的Content-Type为：text/event-stream，但前端仍然不是流式接收内容。2、虽然前端能以流式接收服务端的响应内容，但内容接收完毕，长连接并未关闭，导致前端还以为服务端有数据，会一直请求服务端，最后导致超时。最后发现是nginx的问题，由于本地对接的时候并未启用nginx，所以本地对接没有任何问题。而线上使用nginx请求转发，有些配置是有默认参数的，所以会失败。因此，在这里分享一下，如果小伙们遇到同样的问题，可以试一试。nginx部分配置如下：123456789101112131415161718192021222324252627server {  server_name xxxx;  listen xxxx;  location /xx/xx  {             add_header backendIP $upstream_addr;                     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_http_version 1.1; # 设置http版本为1.1；默认为：1.0             proxy_set_header Connection ""; # 设置Connection为长连接；默认为：no                  proxy_cache off;  # 关闭缓存；默认是：on             proxy_buffering off;  # 关闭代理缓冲；默认是：on             chunked_transfer_encoding on;  # 开启分块传输编码             tcp_nopush on;  # 开启TCP NOPUSH选项，禁止Nagle算法             tcp_nodelay on;  # 开启TCP NODELAY选项，禁止延迟ACK算法             keepalive_timeout 60;  # 设定keep-alive超时时间为60秒               proxy_pass http://xxxx:xxxx;               proxy_redirect          off;               proxy_connect_timeout   15;  # 与upstream server的连接超时时间（没有单位，最大不可以超过75s）             proxy_send_timeout      300; # 发送请求给upstream服务器的超时时间             proxy_read_timeout      300; # nginx会等待多长时间来获得请求的响应    }}最主要的几个配置：proxy_http_version 1.1;proxy_set_header Connection “”;proxy_cache off;proxy_buffering off;chunked_transfer_encoding on;知识点：Nginx 是通过缓存响应内容来处理请求的。也就是说，当 Nginx 接收到完整的响应后，才会将其发送给客户端，因此默认是不支持流式响应，需要手动开启。

1. 问题描述在启动nginx服务的时候显示内容如下：1sudo systemctl status nginx题出现原因：根据日志显示，Nginx 服务启动失败，主要原因是无法绑定到端口 80。这通常是由于该端口已被其他进程占用而导致的。2. 解决方案要解决此问题，可以执行以下步骤：确认端口 80 是否被其他进程占用。可以使用以下命令检查：1sudo netstat -tuln | grep :80该命令会列出正在监听端口 80 的进程。如果有其他进程在使用该端口打开配置文件：可以将80端口【默认端口】修改为 8080 端口【当然也可以是其他的，不过要记得去防火墙添加规则（即添加端口）可以使用以下命令打开配置文件：1sudo nano /etc/nginx/sites-available/将里面的代码模块123server {    listen 80 default_server;    listen [::]:80 default_server;修改成123server {    listen 8080 default_server;    listen [::]:8080 default_server;完成修改！【如果其他地方还有 80 的修改成 8080 即可】。启动Nginx服务1sudo systemctl start nginx设置Nginx服务自启动：1sudo systemctl enable nginx验证Nginx是否运行：1sudo systemctl status nginx

proxy_pass参数用于配置反向代理，指定客户端请求被转发到后端服务器，后端地址可以是域名、ip端口URI代理后端报错提示本地找不到CSS文件、JavaScript文件或图片例如：nginx ：10.1.74.109后端服务：http://10.1.74.109:8082参数配置：123location /harbor {            proxy_pass http://10.1.74.109:8082;    }访问http://10.1.74.109/zabbix 显示不全，提示文件css等静态文件不存在。原因在于proxy_pass确实指向后端服务器，但浏览器加载页面时，可能会请求一些静态资源，但是这些请求可能不包含/zabbix前缀，也可能静态资源是动态生成的，因此才会去本地去查找这些文件例如以上后端登录前访问得地址为http://10.1.74.109:8082/，登录成功后得地址为http://10.1.74.109:8082/zabbix.php?action=dashboard.view，没有包含/zabbix前缀如果当后端地址后缀不会发生改变的前提代理,一般来说是正常的处理方式：使用proxy_set_header设置正确的Host头1234567location /zabbix {      proxy_pass http://10.1.74.109:8082/;  #url后面必须加上"/"    proxy_set_header Host $host;      proxy_set_header X-Real-IP $remote_addr;      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;     keepalive_timeout 500; }参数含义proxy_set_header Host $host;nginx在转发请求时，将Host请求头的值设置为原始请求的主机名和端口，后端可能依赖Host头来确定应该提供那些内容proxy_set_header X-Real-IP $remote_addr;X-Real-IP用于设别发起请求客户端的真是IP地址，$remote_addr是一个变量包含客户端的IP地址proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;X-Forwarded-For 表示HTTP请求的来源地址，用于追踪请求来源，$proxy_add_x_forwarded_for 是一个特殊的变量，包含原始请求的 X-Forwarded-For 头（如果存在的话）和客户端的 IP 地址。后端服务器可以看到所有经过的代理服务器和原始客户端的 IP 地址。keepalive_timeout 500;设置长连接超时时间，当客户端和服务器之间建立一个长连接后，该连接会在设置时间内保持打开状态，以便客户端通过相同的连接发送多个请求，减少连接开销，提高性能proxy_pass不同写法的影响客户端请求地址为：www.ljx.com/a.html方式一：proxy_pass http://10.1.1.1;12345location /ceshi/{    proxy_pass http://10.1.1.1;    ...} 请求地址：www.ljx.com/ceshi/a.html代理后地址：http://10.1.1.1/ceshi/a.html解释：完整的请求URI（包括/ceshi/a.html）将被发送到后端服务器10.1.1.1。由于proxy_pass没有指定URI部分，因此原始请求的URI保持不变。方式二：proxy_pass http://10.1.1.1/;12345location /ceshi/{    proxy_pass http://10.1.1.1/;    ...} 请求地址：www.ljx.com/ceshi/a.html代理后地址：http://10.1.1.1/a.html解释：由于proxy_pass后面有一个斜杠/，nginx会忽略原始请求URI中的/ceshi/部分，只保留a.html部分，并将其发送到后端服务器方式三：proxy_pass http://10.1.1.1/index/;12345location /ceshi/{    proxy_pass http://10.1.1.1/index/;    ...} 请求地址：www.ljx.com/ceshi/a.html代理后地址：http://10.1.1.1/index/a.html解释：原始请求的URI中的/ceshi/被替换为/index/，然后发送到后端服务器。路径的其余部分a.html保持不变方式四：proxy_pass http://10.1.1.1/somepath;12345location /ceshi/{    proxy_pass http://10.1.1.1/somepath;    ...} 请求地址：ljx./ceshi/a.html代理后地址：http://10.1.1.1/somepath解释：无论原始请求的URI是什么，都会被完全替换为proxy_pass后面指定的URI（在这里是/somepath）。查询字符串（如果有的话）也会被忽略