Automannn的学习园地

# 负载均衡

建立在现有网络结构上，提高服务可用性和灵活性，增加吞吐量的方式。

# 四层负载

  • 通过 ip+port的方式接收请求，再转发到对应的机器
  • 实现原理
    • 负载均衡器对客户端请求报文中的目标IP地址进行修改,客户端的TCP握手直接与服务端建立，类似路由器的转发作用。
  • 优缺点
    • 性能更高，但是灵活度不够
  • 应用
    • 基于C/S开发的ERP系统等

# 七层负载

  • 根据虚拟URL或IP,主机名接收请求，再转发到相应的服务器
  • 实现原理
    • 负载均衡设备先代理最终的服务器和客户端建立连接(三次握手)后，获取到客户端发送的真正应用层内容的报文，再根据报文内容选择最终的服务器。负载均衡器会与客户端及服务器分别建立TCP连接。
  • 优缺点
    • 极大的提升了灵活性(可再负载均衡层面实现Header重写，响应关键字过滤，或者内容插入等)，处理能力低于四层方式。
    • 更加安全，能够更有效的防止DOS攻击，在负载均衡层面即可拦截。
  • 应用
    • 基于B/S开发的，使用HTTP协议的系统

# nginx

engine x,是一个高性能 http和反向代理web服务器。为俄罗斯访问量第二的网站开发。占有内存少，并发能力强。

# 发展历程

  • 第一个版本，0.1.0，发布于2004年10月4日。
  • 1.0.0，2011年4月12日发布
  • 1.3.0，2012年
  • 1.4.0，2013年
  • 1.6.0，2014年
  • 1.7.0，2014年
  • 1.8.0，2015年
  • 1.9.9，2015年

# 常用模块

  1. ngx_http_core_module
    • 核心的http参数配置，对应nginx的http配置区块部分
  2. ngx_http_access_mdule
    • 访问控制模块
  3. ngx_http_gzip_module
    • 压缩模块，对nginx返回的数据压缩，属于性能优化模块
  4. ngx_http_fastcgi_module
    • 动态应用相关模块，如php
  5. ngx_http_proxy_module
    • proxy代理模块
  6. ngx_http_upstream_module
    • 负载均衡模块，实现网站负载均衡功能，及节点健康检查
  7. ngx_http_rewrite_module
    • url地址重写模块
  8. ngx_http_limit_conn_module
    • 限制用户并发连接及请求数模块
  9. ngx_http_limit_req_module
    • nginx请求过程速率限制
  10. ngx_http_log_module
    • 访问日志模块
  11. ngx_http_auth_basic_module
    • basic认证模块
  12. ngx_http_ssl_module
    • ssl模块，用于加密的http连接

# 代理

  • 正向代理

    • 远程访问局域网时，在公网上先连上VPN之后，再访问局域网内的服务。VPN就是正向代理。
    • 正向代理服务器位于客户端和服务器之间，提供数据中转服务。
    • 正向代理，代理的是客户端

  • 反向代理

    • 反向代理，代理的是服务器
    • nginx就是反向代理

  • 代理规则

    • 代理目录

      • # ~ 表示区分大小写匹配
location ~ /api1/*** {
      //此处省略
}

    • 模糊代理

      • # 匹配以v1开始，且跳过任意字符串，且后面包含xxx的url路径
location ~ ^/v1/.*/xxx.* {
      //此处省略
}

# 代理匹配规则

# 规则简介

  • = 精确匹配
  • ~ 区分大小写匹配
  • ~* 不区分大小写匹配
  • !~ 区分大小写不匹配
  • / 通用匹配，全部被匹配到

# 规则分类

  • 基于普通字符串的匹配
    • 以**=引导符开头的精确匹配**
    • 无引导字符的字符串
  • 基于正则的匹配
    • 以**~引导符开头的正则匹配**
    • 以**~引导符开头的正则匹配*

# 规则优先级

  1. =引导符的精确匹配（后方不能带参数）
  2. ^~引导符开头的前缀路径匹配
  3. ~或者~*引导符定义的正则匹配，根据顺序来，在前的优先级更高，前方匹配后，将会停止匹配
  4. 部分起始路径匹配(字符串模式)
  5. 通用匹配,通过 /进行配置，如果没有其它匹配，则任何请求都会匹配到;

# 匹配流程

  1. 先查找精确匹配，如果命中，则直接返回
  2. 再查找普通匹配,以最大前缀为原则，如果命中,暂存当前的匹配结果，继续搜索正则模式
  3. 按照顺序搜索正则匹配,如果命中，则以此为结果返回；如果没命中，则以缓存的结果为最终结果。
  4. 如果前方的搜索没匹配到，则匹配通用匹配
  5. 如果没有通用匹配，则返回404

# 匹配注意事项

  • 正则匹配项的匹配规则，受定义的前后顺序影响。但普通匹配模式不受前后顺序影响;

# 转发规则

# 转发规则(来自网络)

  • proxy_pass不带URI的(只包含IP和端口，端口后的/也没有)

    • 原样保留路径。即保留location中路径部分

    • location /api1/{
	proxy_pass http://localhost:8080
}
访问 http://localhost/api1/xxx   代理到 http://localhost:8080/api1/xxx

  • proxy_pass带有URI的（包含只有/的方式）

    • 进行字面替换,对请求的URL进行替换

    • location /api2/{
	proxy_pass http://localhost:8080/
}
访问 http://localhost/api2/xxx  代理到 http://localhost:8080/xxx

location /api2{
	proxy_pass http://localhost:8080/
}
访问 http://localhost/api2/xxx 代理到 http://localhost//xxx

# 代理转发实测

  • 代理配置

    server {
    location /test/aaa {
            proxy_pass http://localhost/bcd/;
    }

    location /test/bbb {
            proxy_pass http://localhost/gef;
    }

    location /test/ccc/ {
            proxy_pass http://localhost/lmn/;
    }

    location /test/ddd/ {
            proxy_pass http://localhost/ijk;
    }
}

  • 请求路径

    http://localhost/test/ddd///thisismypath/1/2/3

  • 转发结果

    转发前 转发后 转发配置
    /test/aaa///thisismypath/1/2/3 /bcd//thisismypath/1/2/3 location /test/aaa {
    proxy_pass http://localhost/bcd/;
    }
    /test/bbb///thisismypath/1/2/3 /gef/thisismypath/1/2/3 location /test/bbb {
    proxy_pass http://localhost/gef;
    }
    /test/ccc///thisismypath/1/2/3 /lmn/thisismypath/1/2/3 location /test/ccc/ {
    proxy_pass http://localhost/lmn/;
    }
    /test/ddd///thisismypath/1/2/3 /ijkthisismypath/1/2/3 location /test/ddd/ {
    proxy_pass http://localhost/ijk;
    }
    /test/aaa/thisismypath/1/2/3 /bcd//thisismypath/1/2/3 location /test/aaa {
    proxy_pass http://localhost/bcd/;
    }
    /test/bbb/thisismypath/1/2/3 /gef/thisismypath/1/2/3 location /test/bbb {
    proxy_pass http://localhost/gef;
    }
    /test/ccc/thisismypath/1/2/3 /lmn/thisismypath/1/2/3 location /test/ccc/ {
    proxy_pass http://localhost/lmn/;
    }
    /test/ddd/thisismypath/1/2/3 /ijkthisismypath/1/2/3 location /test/ddd/ {
    proxy_pass http://localhost/ijk;
    }

# 代理转发结论

  • 代理转发为了方便记忆，可大致理解为字面替换，但绝不能简单的理解为字面替换
  • 大多数情况下,匹配路径带/,转发路径不带/，容易导致异常现象;

# 最佳实践

匹配规则与转发规则保持一致。即要么结尾都带/,要么结尾都不带/

# 七层负载配置

worker_processes  1;

events {
   worker_connections  1024;
}

http {
   include       mime.types;
   default_type  application/octet-stream;
   sendfile        on;
   keepalive_timeout  65;

   #允许客户端请求的最大单文件字节数
   client_max_body_size 10m; 

   #缓冲区代理缓冲用户端请求的最大字节数，
   client_body_buffer_size 128k;

   upstream myAuth {
       server localhost:18010 weight=1;
       server localhost:18011 weight=1;
   }

   server {
       listen       80;
       server_name  localhost;

       set $core_origin "";
       if ($http_origin ~* "^http://localhost/ips/admin/$") {
           set $core_orgin $http_origin;
       }
       if ($http_origin ~* "^http://localhost/ips/auth/$") {
           set $core_orgin $http_origin;
       }
       if ($http_origin ~* "^http://www.xxx.cn$") {
           set $core_orgin $http_origin;
       }

       location / {
           root   html;
           try_files $uri $uri/ /index.html
           index  index.html index.htm;
       }

       location /portal/ {
            proxy_pass http://127.0.0.1:8081/portal/;
       }

       location /ips/admin/ {
            proxy_pass http://localhost:18020/ips/admin/;
       }

       location /cep/auc/ {
            proxy_pass http://localhost:17020/cep/auc/;
       }

       location /ips/auth/ {
            proxy_pass http://myAuth;
       }
   }

}
  • 配置cookie隔离
location /casserver/ {
             proxy_pass http://casserver/casserver/;
             proxy_set_header Host $http_host;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
             proxy_cookie_path /casserver/ /casserver/;
}

# 四层负载配置

stream {
    upstream sshAuth {
        server localhost:18010 weight=1;
        server localhost:18011 weight=1;
    }

    server {
        listen 83;
        proxy_connect_timeout 1s;
        proxy_timeout 3s;
        proxy_pass sshAuth;
     }
}

# nginx疑难杂症

# 应用服务器获取host异常

# host请求头描述

  • http的Request header 中的 Host 指定了所请求资源的主机和端口

  • RFC 2616 HTTP/1.1 中规定，在所有HTTP/1.1 请求中，client 必须包含 Host header；如果headers中没有Host，所有 HTTP/1.1 proxy 必须返回 400(Bad Request)。

  • 在 nginx proxy_pass 指令中，若不做任何配置，会使用后面的 URL 重写的Host

# 如何维持请求头

  • 通过配置proxy_set_header Host $host;

# nginx变量大全

变量名称 变量含义
$remote_addr 客户端地址，注意是客户端的公网IP
$args 存放了URL中的指令；www.a.com?id=1&name=a, id=1&name=a即为 $args
$document_root 当前资源的请求的系统根目录，如 /apps/nginx/html
$cookie_name key为name的cookie值；同理，$cookie_a,表示 key为a的cookie值;
$document_uri 当前请求中不包含指令的uri；www.a.com/a/b/c?id=1,/a/b/c 即为 $document_uri
$host 当前请求的host名称
$http_user_agent 客户端浏览器的详细信息
$http_cookie 客户端的cookie信息
$limit_rate 如果nginx配置了显示网络速率，则为网络速率值，没有设置则为0
$remote_port 客户端请求ng服务器时，客户端随机打开的端口
$remote_user 已经经过 Auth Basic Module验证的用户名
$request_body_file 做反向代理时,发给后端服务器的本地资源的名称
$request_method 请求资源的方式，get/post/put/delete等
$request_filename 当前请求的资源文件的路径名称,由root或alias指令 与 URI请求生成的文件绝对路径，如/apps/nginx/html/main/index.html
$request_uri 包含请求参数的原始URI，不包含主机名;www.a.com/a?id=1中, a?id=1 即为 $request_uri
$scheme 请求的协议，如 ftp,https,http等
$server_protocol 请求资源的协议版本，如 HTTP/1.0等
$server_addr 服务器的ip地址
$server_name 服务器的主机名
$server_port 服务器的端口
set $var_name value; 自定义变量

# proxy_pass追加头信息

  • 有时候只写 proxy_pass，可能无法正常转发，比如 jenkins;

# proxy_set_header指令，添加头信息给后端服务器

  • proxy_set_header X-Real-IP $remoet_addr; 自定义请求头，这个ip可能是其它代理，也可能是真正的请求端，目前它并不属于任何标准，仅约定

  • proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 扩展头，用来表示HTTP请求端真实ip

  • proxy_set_header Host $host; 传递当前请求的host名称

  • 注意，传递请求头可能有三个配置: $http_host,$host,以及$proxy_host, 这个对于下游服务器的host拦截影响很大，具体如下:

    • $http_host就是浏览器访问的地址加端口(如果请求没带Host就没有);
    • $http是浏览器访问的地址(如果请求没带Host，就用第一个serverName)，不带端口;
    • $proxy_host就是使用的proxy_pass的ip和端口(如果是80端口就不携带);

# add_header指令，添加响应给浏览器的头信息

  • add_header Access-Contro-Allow-Headers $http_access_control_request_headers;

# 头信息限制

  • ng的头信息，不能含有下划线
  • 可以用驼峰式命名，或者用-
  • 如果含有下划线的头信息，默认会被直接丢弃
  • 可以通过 underscores_in_headers on;修改这个特性

# cookie丢失问题排查

# cookie反向代理的两种情况(本质在于上下文是否发生变化)

  • host、端口转换,cookie不会丢失
location /project {
    proxy_pass http://192.168.100.3:8080/project
}
  • host、端口、路径均变化,cookei会丢失，可通过proxy_cookie_path /project /proxy_project,注意实际的上下文在前
    • 客户端请求带有cookie时，上下文为 proxy_project,后端服务器需要取的cookie上下文为 project，属于 服务器未识别cookie
    • 服务端返回响应时，写入cookie,上下文为 project,此时浏览器的访问路径为 proxy_project,属于 没有跨站，客户应该时可以写入cookie，但无法在下次请求时携带
location /proxy_project {
    proxy_pass http://192.168.100.3:8080/project,
    proxy_cookie_path /project /proxy_project       #进行cookie上下文转换
}
  • 特别注意，有些场景，应用服务器设置了上下文为/,此时便不配置亦可

# proxy_pass头信息传递规则

  • 在没有定义proxy_set_header时，会继承之前的值。默认情况下，只有两个字段被重定义
    • proxy_set_header Host $proxy_host
    • proxy_set_header Connection close;

# ng配置项

  • proxy_pass_request_headers,默认为on,作为确定是否转发http头部
  • proxy_pass_request_body,默认为on,作为确定是否向上游服务器发送http包体

# proxy_pass内外网端口重定向错误:port_in_redirect参数

  • nginx默认做了端口重定向，重定向的端口是当前server配置的端口; 即 $HOST:${当前server配置的port}; 参考地址 ：https://blog.csdn.net/weixin_42272246/article/details/128134903
  • 解决方法1：
port_in_redirect off;
proxy_set_header   Host    $host:外网端口;
proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;
  • 解决方法2:
proxy_set_header   Host    $http_host;

# nginx的静态资源重定向错误：外网端口被重定向为内网端口

  • 如果的 URL 不包含尾部斜杠并且对应于一个目录（而不是文件），Nginx 会自动执行一次内部重定向，在 URL 后面加上斜杠，然后再次查找。这是为了确保正确的文件查找和避免潜在的安全问题（如目录遍历攻击）。
  • 如果请求的文件名（$request_filename）对应的是一个目录（-d），那么就执行自定义的重写规则
if (-d $request_filename) {
                rewrite [^/]$ $scheme://$http_host$uri/ permanent;
}
  • 配置示例
server {
    listen       80;
    server_name  localhost; # 修改为docker服务宿主机的ip

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        try_files $uri $uri/ /index.html =404;
        if (-d $request_filename) {
                        rewrite [^/]$ $scheme://$http_host$uri/ permanent;
        }
    }

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

# rewrite与proxy_pass的区别

  • 目的不同：rewrite 旨在修改URL路径，而 proxy_pass 用于将请求转发给其他服务器。

  • 对客户端的影响：rewrite 可以导致客户端浏览器的URL变化（如果是外部重定向的话），而 proxy_pass 对客户端是透明的，不会改变客户端看到的URL。

  • 工作范围：rewrite主要在Nginx内部工作，可能会影响后续的请求处理逻辑，包括如何选择location块。proxy_pass 则涉及与外部服务器的通信，通常用于构建分布式系统或服务架构。

  • 在实际配置中，这两个指令经常一起使用。例如，你可能会先使用 rewrite 修改请求的URI，然后再使用 proxy_pass 将修改后的请求转发给适当的后端服务器。

# 举例说明

在Nginx中，rewrite 和 proxy_pass 在同一个 location 块内时，它们的执行顺序和优先级取决于配置的具体情况。但一般来说，rewrite 指令会在 proxy_pass 之前处理。这是因为Nginx按照其内部的阶段（phases）来处理请求，每个阶段有特定的任务。

  • Nginx的处理阶段大致如下：

    1. Rewrite phase (重写阶段)：在这个阶段，所有 rewrite 指令会被评估和执行。如果 rewrite 规则导致了URI的变化，并且没有使用 break 或 last 标志，那么可能会触发新的location匹配过程。
    2. Post-rewrite phase (后重写阶段)：这个阶段会再次检查location匹配，以确保在URI改变后选择正确的location块。
    3. Access phase (访问控制阶段)：执行访问控制指令，如 allow、deny 等。
    4. Content phase (内容处理阶段)：这是处理实际请求的地方，proxy_pass 指令通常在这个阶段执行，因为它涉及到将请求转发给后端服务器或生成响应内容。

  • 在一个 location 中同时存在 rewrite 和 proxy_pass 时，rewrite 会先于 proxy_pass 执行。

location /api/ {
    rewrite ^/api/(.*)$ /$1 break;
    proxy_pass http://backend_server;
}

在这个例子中，首先会应用 rewrite 规则，将 /api/something 重写为 /something，然后 proxy_pass 会将修改后的路径发送到 backend_server。

# rewrite的标志

# last标志

  • 停止当前location块中其他 rewrite 指令的处理，并开始新一轮的location匹配过程。这意味着如果URI被重写，Nginx会根据新的URI再次尝试匹配location块

# break标志

  • 停止当前location块中其他 rewrite 指令的处理，但不会触发新一轮的location匹配。后续的指令（如 proxy_pass）仍然会在当前location中执行

# redirect标志

  • 返回一个临时重定向（HTTP 302）给客户端，告知浏览器访问新的URL。浏览器会发起一个新的请求到新的URL。

# permanent标志

  • 返回一个永久重定向（HTTP 301）给客户端。与 redirect 类似，但它表示资源已永久移动到新位置，搜索引擎会更新索引.

# noescape标志

  • 防止对重写后的URI进行URL编码。默认情况下，Nginx会对替换部分进行URL编码。使用 noescape 标志可以避免这种编码

# rewrite规则

  • 如果有多个 rewrite 指令，它们会按照出现的顺序依次执行，直到遇到带有 last 或 break 标志的指令为止。
  • redirect 和 permanent 会导致客户端浏览器地址栏中的URL发生变化，而 last 和 break 则是内部重写，对客户端不可见。
  • 没有显示指定的情况下，默认使用的是break;

# nginx健康检查机制

# 原生健康检查

  • 原生健康检测主要设计两个模块,ngx_http_proxy_module和ngx_http_upstream_module

# ngx_http_upstream_module模块

upstream myServers{
	server 172.18.23.21:8003 max_fails=3 fail_timeout=30s;
}
  • max_fails(默认为1):nginx与上游服务器通信尝试允许失败次数
    • 在fail_timout参数定义的时间段内,失败次数达到该值，ng认为该服务不可达;
    • 在下一个fail_timeout时间段，该服务器不会再被尝试
    • 设为0后，将认为该服务器一直可用
    • 可以通过proxy_next_upstream,fastcgi_next_upstream,memcached_next_upstream手动配置什么是失败的尝试，默认情况下，http_404状态不被认为是失败的尝试
  • fail_timeout(默认为10s):nginx负载的保活的时间段
    • 上游服务器被认为不可用的时间段
    • 统计失败尝试次数的时间段

# ngx_http_proxy_module模块

  • proxy_connect_timeout:与上游服务器建立连接的超时时间,应该指的是TCP连接

  • proxy_read_timeout:从上游服务器读取响应的超时时间

  • proxy_next_upstream: 指定何种情况下，请求被发送到下一台后端服务器，即定义何为失败的请求

    • 默认值为error,timeout,即发生网络错误，以及超时，才会重试其他服务器，返回500,404均不会重试

    • 可以添加相应的状态码进行重试,如: proxy_next_upstream error timeout http_500 http_404

    • 当请求类型是POST时，ng默认不会失败重试，官网描述为:通常情况下，请求使用非幂等方法(POST,PATCH,LOCK)时,请求失败后不会再到其他服务器进行重试。如果不需要此特性，加上non_idempotent即可。如果需要post也失败重试,需要配置:proxy_next_upstream error timeout non_idempotent

    • 关于幂等的一个说明:

      • 多次执行一个方法的结果预期与单个执行的效果相同，则认为该方法幂等。常见的http方法中，get是幂等的，而post是非幂等的。因为get一般用于获取数据，对应数据库的SELECT语句，多次执行不会影响结果。而POST一般对应INSERT，如果多次执行，可能导致数据重复插入问题。
      • 不建议使用GET方法做一些INSERT操作，业务开发时要遵循http协议规范.
      • 生产环境，不建议加上non_idempotent选项，因为不论是timeout,还是500,服务器都可能已经执行过方法了。

需要注意，当客户端与服务端没有建立通信时，请求转发给下一台后端服务器才是可行的。如果客户端与服务器已经建立连接后，出现错误或者超时,这类错误是不可恢复的.

# 原生健康检查的弊端

  • 节点异常时，nginx依然会把该请求转发给该异常节点，会浪费一次转发，再转发给别的节点.尝试max_fails次失败后，才会设置为异常节点
  • 判断为异常节点后，当fail_timeout时间来临,ng直接使用线上流量请求异常节点,而不是先探测是否恢复，在导入线上流量;无法精确判断异常节点是否恢复.

# 第三方健康检查nginx_upstream_check_module

编译安装该模块后，可在upstream中定义

upstream myServers{
	server 172.18.23.21:8003;
	server 172.18.23.22:8003;
	
	check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp];
}
  • interval: 想后端发送的健康检查包的间隔;
  • fall: 如果连续失败次数达到fall_count,服务器就被认为是down；
  • rise: 如果连续成功次数达到rise_count,服务器就被认为是up;
  • timeout: 后端健康请求的超时时间
  • default_down: 设定初始服务器的状态,如果是true,说明默认是down。默认值是true.
  • type: 健康检查包的类型
    • tcp: 简单的tcp连接，如果连接成功,说明后端正常;
    • ssl_hello: 发送一个初始的SSL hello包并接受服务器的SSL hello包;
    • http: 发送http请求，通过后端的回复包的状态，来判断后端是否存活;
    • mysql: 向mysql服务器连接，通过接受服务器的greeting包，来判断后端是否存活;
    • ajp: 向后端发送ajp协议的Cping包，通过接受Cpong包来判断后端是否存活;
  • port: 后端服务器的检查端口。可以与实际的端口不一致，比如后端提供的443端口应用，可以检查80端口状态来判断后端健康状况。默认是0，表示跟后端server提供真实服务的端口一致。

# nginx反向代理https网页502, ssl_handshake失败

  • nginx的ssl在握手时，默认不发送主机名，以ip连接服务器，当服务器上有多个虚拟主机使用同一个ip时，默认返回第一个可用证书，这样就导致证书无法匹配
  • nginx对于此问题的方案称为 https的SNI, 配置中加入：proxy_ssl_server_name on; 即可;
  • 参考文档：https://crmeb.com/ask/thread/24234

# ng无网环境下安装

# 不要考虑用yum迁移的方案，已失败。  yum迁移适用于较小的工具，比如 telnet
# 大部分情况都能直接成功（不成功的情况下再考虑依次安装依赖， gcc都没有的环境还是比较少，一上来所有依赖都需要安装，就吓住了）
wget https://nginx.org/download/nginx-1.20.2.tar.gz

tar -zxvf nginx-1.20.2.tar.gz

./configure --prefix=/u01/nginx --conf-path=/u01/nginx/nginx.conf

make

make install

# yum迁移小技巧备注

  • 适用于较小的工具，比如 telnet
#这个命令不够彻底
yumdownloader --resolve --destdir=/usr/local/LOCAL-RPMS/nginx nginx  

#这个命令会深度下载，即下载包及其所有层级依赖
repotrack -p /usr/local/LOCAL-RPMS/nginx nginx

# 在网络环境下使用
yum localinstall *.rpm

# ng互联网环境下yum安装

# 安装指令

yum install -y epel-release

yum install -y nginx

systemctl enable nginx

systemctl start nginx

# 关键路径

  • 主配置文件: /etc/nginx/nginx.conf
  • 站点配置文件: /etc/nginx/conf.d/
  • 日志文件: /var/log/nginx/
  • 静态文件: /usr/share/nginx/html/
  • PID文件: /var/run/nginx.pid
  • 模块文件: /usr/lib64/nginx/modules/
  • ng执行文件: /usr/sbin/nginx

# 临时下载服务配置

	#临时关闭selinux, SELinux 默认会限制非标准端口。
    sudo setenforce 0
    #永久关闭selinux
    sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
  • 配置server
 server {
      listen 10555;
      server_name _;

      location / {
        root /hd01/ollama2; #下载地址，需要使用命令 chmod 777 -R 放开权限
        autoindex on;
        autoindex_exact_size off;
        add_header Accept-Ranges bytes;  # 启用断点续传
      }
    }

# 常见关键响应头说明

# proxy_buffering

  • 默认值为on,即开启缓冲
  • 缓冲区大小可以通过proxy_buffer_size进行设置
  • 如果proxy_buffering被关闭了,那么响应body会按照获取body的多少立刻同步传送到客户端。

# no-transform

  • 不得对资源进行转换或转变。Content-Encoding、Content-Range、Content-Type等 HTTP 头不能由代理修改。
  • 例如，非透明代理或者如Google's Light Mode可能对图像格式进行转换，以便节省缓存空间或者减少缓慢链路上的流量。no-transform指令不允许这样做。
  • vue的代理默认会对后端接口进行压缩，所以需要设置cacge-control: no-cache,no-transform