Cpp五条

这个屌丝很懒，什么也没留下！

热门标签

nginx常用功能配置_access-control-allow-methods 大小写

作者：Cpp五条 | 2024-03-06 01:48:54

踩

access-control-allow-methods 大小写

nginx使用

1.什么是nginx

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器。它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

说白了nginx就是一款轻量级的服务器，我们通过修改其配置文件，就可以轻松的进行服务器的管理。

2.nginx基础

安装：官网- 注意安装后要修改登录身份
配置文件地址：/etc/nginx/nginx.config，注意配置文件中要添加分号。
启动：nginx
日志地址：/var/log/nginx/error.log;
当nginx启动后，可以使用“-s”参数向nginx管理进程发送信号来控制nginx：
```
nginx -s signal
1
```
其中，signal可以是以下值：
- stop：快速关闭
- quit：安全关闭
- reload：重载配置文件
- reopen：重新打开一个log文件，用于日志切割

3.nginx请求匹配规则

语法规则： location [=|_|*|^~] /uri/ { … }

= 开头表示精确匹配
^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。以xx开头
~ 开头表示区分大小写的正则匹配以xx结尾
~* 开头表示不区分大小写的正则匹配以xx结尾
!_和!*分别为区分大小写不匹配及不区分大小写不匹配的正则
/ 通用匹配，任何请求都会匹配到。

多个location配置的情况下匹配顺序为：首先精确匹配 =-》其次以xx开头匹配^~-》然后是按文件中顺序的正则匹配-》最后是交给 / 通用匹配。

当有匹配成功时候，停止匹配，按当前匹配规则处理请求。

例子，有如下匹配规则：

location = / {
   #规则A
}
location = /login {
   #规则B
}
location ^~ /static/ {
   #规则C
}
location ~ \.(gif|jpg|png|js|css)$ {
   #规则D，注意：是根据括号内的大小写进行匹配。括号内全是小写，只匹配小写
}
location ~* \.png$ {
   #规则E
}
location !~ \.xhtml$ {
   #规则F
}
location !~* \.xhtml$ {
   #规则G
}
location / {
   #规则H
}
那么产生的效果如下：

访问根目录/， 比如http://localhost/ 将匹配规则A

访问 http://localhost/login 将匹配规则B，http://localhost/register 则匹配规则H

访问 http://localhost/static/a.html 将匹配规则C

访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用， 而 http://localhost/static/c.png 则优先匹配到 规则C

访问 http://localhost/a.PNG 则匹配规则E， 而不会匹配规则D，因为规则E不区分大小写。

访问 http://localhost/a.xhtml 不会匹配规则F和规则G，

http://localhost/a.XHTML不会匹配规则G，（因为!）。规则F，规则G属于排除法，符合匹配规则也不会匹配到，所以想想看实际应用中哪里会用到。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

1、配置静态文件服务器：

 location /ttms/ {
     root      /root/;
     autoindex on;
}
1
2
3
4

注意文件目录，与location之间关系。nginx会将ttms作为请求识别，ttms之后的内容为具体的uri，根路径为root设置的路径。

2、配置https

server {
        listen       443 ssl;
        listen       [::]:443 ssl;
        server_name  _;
        root         /usr/share/nginx/html;

        ssl_certificate "证书";
        ssl_certificate_key "秘钥";
        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  10m;
        ssl_ciphers HIGH:!aNULL:!MD5;
        # ssl_prefer_server_ciphers on;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

3、配置均衡负载

upstream taishan {
    server 132.232.169.227:1789 weight=2;
    server 132.232.169.227:2789 weight=1;
}
#配置在http中

proxy_pass http://taishan;#请求转向taishan定义的服务器列表
proxy_set_header Host $host;#将请求头转发给后端服务器
proxy_set_header X-Forward-For $remote_addr;#后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
#其他相关配置入下，可以根据需要添加配置
#client_max_body_size 10m;#允许客户端请求的最大单文件字节数
#client_body_buffer_size 128k;#缓冲区代理缓冲用户端请求的最大字节数
#proxy_connect_timeout 90;#nginx跟后端服务器连接超时时间(代理连接超时)
#proxy_send_timeout 90;#后端服务器数据回传时间(代理发送超时)
#proxy_read_timeout 90;#连接成功后，后端服务器响应时间(代理接收超时)
#proxy_buffer_size 4k;#设置代理服务器（nginx）保存用户头信息的缓冲区大小
#proxy_buffers 4 32k;#proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
#proxy_busy_buffers_size 64k;#高负荷下缓冲大小（proxy_buffers*2）
#proxy_temp_file_write_size 64k;#设定缓存文件夹大小，大于这个值，将从upstream服务器传
# root   html;
# index index.php index.html index.htm;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

4、配置反向代理

 location /ttmsOperation/ {
      proxy_pass http://132.232.169.227:510;
}
1
2
3

5、cors跨域

location / {  
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

    if ($request_method = 'OPTIONS') {
        return 204;
    }
} 
1
2
3
4
5
6
7
8
9

1. Access-Control-Allow-Origin

服务器默认是不被允许跨域的。给Nginx服务器配置Access-Control-Allow-Origin *后，表示服务器可以接受所有的请求源（Origin）,即接受所有跨域的请求。

2. Access-Control-Allow-Headers 是为了防止出现以下错误：

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

这个错误表示当前请求Content-Type的值不被支持。其实是我们发起了"application/json"的类型请求导致的。这里涉及到一个概念：预检请求（preflight request）,请看下面"预检请求"的介绍。

3. Access-Control-Allow-Methods 是为了防止出现以下错误：

Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

4.给`OPTIONS` 添加 `204`的返回，是为了处理在发送POST请求时Nginx依然拒绝访问的错误

发送"预检请求"时，需要用到方法 OPTIONS ,所以服务器需要允许该方法。

其实上面的配置涉及到了一个W3C标准：CROS,全称是跨域资源共享 (Cross-origin resource sharing)，它的提出就是为了解决跨域请求的。

跨域资源共享(CORS)标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。

其实Content-Type字段的类型为application/json的请求就是上面所说的搭配某些 MIME 类型的 POST 请求,CORS规定，Content-Type不属于以下MIME类型的，都属于预检请求：

application/x-www-form-urlencoded
multipart/form-data
text/plain
1
2
3

所以 application/json的请求会在正式通信之前，增加一次"预检"请求，这次"预检"请求会带上头部信息 Access-Control-Request-Headers: Content-Type：

OPTIONS /api/test HTTP/1.1
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type
… 省略了一些

服务器回应时，返回的头部信息如果不包含Access-Control-Allow-Headers: Content-Type则表示不接受非默认的的Content-Type。即出现以下错误：