第五章 Nginx其他功能合集笔记

àì夳堔傛蜴生んèń 2021-10-19 00:52 260阅读 0赞

## **一、跨域处理** ##

问题由来：浏览器拒绝执行其它域名下的ajax运作

如果浏览器在static.enjoy.com对应的html页面内，发起ajax请求偷盗www.enjoy.com域名下的内容来填充自己的页面，整个互联网秩序将混乱。为了防止这种混乱，W3C组织制定了浏览器安全规范，即html页面发起的ajax请求仅限于同域名后端范围，跨越域名的ajax请求不得执行，此谓跨域问题。

常见的跨域方案：jsonp、 document.domain + iframe 跨域---对业务有侵入

当前访问地址：[http://static.chj.com//index.html][http_static.chj.com_index.html]

对应的页面js代码如下：

结果：当前访问页面域名与ajax的目标域名不一致，浏览器将拒绝执行请求，浏览器控制台打印错误如下图所示：

![20190814001620469.png][]

而在日常工作中，我们自己有多个子系统，避免不了要有跨越子系统的ajax请求，此时，我们希望自己内部的各个子系统不必有这种跨域限制。

### **1、Jsonp的解决之道** ###

w3c制定的规则不允许ajax跨域请求，却允许script标签发起跨域请求，具体实现如下：

因此，有人便扩展的script标签src源可以跨域的用法，来得到跨域名的请求信息，这便是jsonp的解决办法。jsonp的方法有其不美的地方，主要是两点：

1）jsonp只能解决GET类的请求，其它类型的请求，script标签无法做到。

2）使用jsonp的方式，对应的后台程序必须对结果进行改造，将返回值做一个函数式包装，这对业务开发有较大侵入性，增加开发人员负担。

### **2、cors方案的解决之道** ###

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）,它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服AJAX只能同源使用的限制。

W3C制定跨域限制的本意，是防止页面领域安全混乱，即防止A公司不经B公司同意，使用ajax盗取B公司的服务内容。出于这个本意，W3C改进了跨域的方案，即：如果B公司是同意将自己的内容分享给A公司的，跨域限制可放开，此方案即CORS方案，如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70][]

nginx配置跨域操作：

**简单请求：**

浏览器在跨源AJAX请求的头信息之中，自动在添加一个Origin字段（本次请求来自哪个源 ）。

服务器根据这个值，在许可范围内，则在头信息包含 Access-Control-Allow-Origin 。

对于比较简单的http请求（GET、POST、HEAD类型），无须浏览器来问，nginx服务器直接在响应头部，加入同意跨域的信号即可：

\#是否允许请求带有验证信息

add\_header Access-Control-Allow-Credentials true;

**\#允许跨域访问的域名,可以是一个域的列表，也可以是通配符\***

**add\_header Access-Control-Allow-Origin  ****http://static.chj.com;**

页面请求：[http://test.chj.com/order/hankin/getPage返回正常结果。][http_test.chj.com_order_hankin_getPage]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 1][]

**复杂请求：**会在正式通信之前，增加一次HTTP查询请求，称为“预检”请求OPTIONS。

对于复杂的http请求（PUT、DELETE、含json格式数据），浏览器会在发请求前，先发一道OPTION请求来询问。我们在Nginx上直接配置对此询问的回答即可：

if ($request\_method = 'OPTIONS') \{\#\#OPTIONS类的请求，是跨域先验请求

return 204;   \#\#  204代表ok

有了上述Nginx的两道配置，跨域问题自然而解，对业务毫无侵入性。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 2][]

## **二、防盗链** ##

### **1、nginx配置DDOS** ###

**限制请求次数****：**

设置Nginx、Nginx Plus的连接请求在一个真实用户请求的合理范围内。比如，如果你觉得一个正常用户每两秒可以请求一次登录页面，你就可以设置Nginx每两秒钟接收一个客户端IP的请求（大约等同于每分钟个请求）。

limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;
        server {
            ...
            location /login.html {
            limit_req zone=one;
            ...
            }
    }

\`limit\_req\_zone\`命令设置了一个叫one的共享内存区来存储请求状态的特定键值，在上面的例子中是客户端IP($binary\_remote\_addr)。location块中的\`limit\_req\`通过引用one共享内存区来实现限制访问/login.html的目的。

### **2、nginx配置防盗链** ###

location ~ .*\.(jpg|jpeg|JPG|png|gif|icon)$ {
         valid_referers blocked http://www.itcats.cn www.itcats.cn;
         if ($invalid_referer) {
             return 403;
         }
    }

nginx作为服务器的入口，所有的请求都需要经过nginx再分发给tomcat，如果有一天nginx挂了怎么办？nginx怎么实现高可用？

目标：让资源只能在我的页面内显示，不能被其它页面直接引用

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 3][]

### **3、解决办法：** ###

浏览器发起的任何请求，在其request头部，都会标注其请求发起地的URL，如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 4][]

因此，在Nginx服务器上，只要校验此发起地url，就可以对应地拒绝响应它，Nginx配置方法如下：

location ^~ /mall {
         valid_referers *.chj.com;  ## 对referer进行校验
         if ($invalid_referer) { ## 校验不过，拒绝访问
         return 404;
         }
         root /etc/nginx/html/gzip;
    }

## **三、压缩** ##

带宽资源很贵，/html/js/css压缩一下再传输，通常可减少50%的体积，何乐而不为。

过程：浏览器在发送请求时，会附带自己支持的压缩方式：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 5][]

**nginx配置：**

location ~ /(.*)\.(html|js|css|png)$ {
    gzip on; # 启用gzip压缩，默认是off，不启用
    # 对js、css、jpg、png、gif格式的文件启用gzip压缩功能
    gzip_types application/javascript text/css image/jpeg image/png image/gif;
    gzip_min_length 1024; # 所压缩文件的最小值，小于这个的不会压缩
    gzip_buffers 4 1k; # 设置压缩响应的缓冲块的大小和个数，默认是内存一个页的大小
    gzip_comp_level 1; # 压缩水平，默认1。取值范围1-9，取值越大压缩比率越大，但越耗cpu时间
    root /etc/nginx/html/gzip;
    }

## **四、https配置** ##

### **1、对称加密** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 6][]

安全隐患：钥匙除我之外，还有多个人拥有。泄露风险较大，钥匙传递的过程风险较大

### **2、非对称加密** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 7][]

优缺点：私钥很安全。但是非对称算法开销很大，大批量应用于业务，会导致性能成本过高（太败家）。

### **3、https加密方案** ###

综合上述方案优缺点，各取所长，得到自己的方案

1）业务数据的加密使用对称加密，降低性能开销

2）对称密钥，采用非对称加密，保驾护航

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 8][]

### **4、Nginx配置https** ###

前提：查看nginx已经安装好了https模块（openresty默认是开启https模块的）：

是否包含： --with-http\_ssl\_module

Nginx配置https只需要两个文件：一个是浏览器证书（内含公钥，供浏览器加密使用），一个是私钥（供自己解密使用）。server.crt和server.key可以自己去购买商业的，也可以自己使用程序生成一份（曾经的12306就使用自签的证书）。

**4.1、自签证书**

自签证书生成过程如下（前提是机器里装好了openssl程序，复制命令即可）：

> \# 1）创建服务器私钥，命令会让你输入一个口令：
> 
> openssl genrsa -des3 -out server.key 4096  -- 密码123456
> 
> \# 2）创建签名请求的证书（CSR）：
> 
> openssl req -new -key server.key -out server.csr   \-- 密码123456
> 
> \# 3）在加载SSL支持的Nginx并使用上述私钥时除去必须的口令：
> 
> openssl rsa -in server.key -out server\_nopass.key  -- 密码123456
> 
> \# 4）最后标记证书使用上述私钥和CSR：
> 
> openssl x509 -req -days 365 -in server.csr -signkey server\_nopass.key -out server.crt

创建https.conf文件中添加如下配置：

> ssl\_certificate      /etc/nginx/server.crt;
> 
> ssl\_certificate\_key  /etc/nginx/server\_nopass.key;

**4.2、Nginx配置**

Nginx内的配置如下：

server {
       listen      443 ssl ;
       server_name  chj.com;
       # access_log  logs/access_a.log  access;
       ssl_certificate /etc/nginx/server.crt;  ## 共浏览器下载证书
       ssl_certificate_key /etc/nginx/server_nopass.key; ## 自己用来解密的私钥
       location / {
            root   /etc/nginx/html;
            index  a.html;
    
       }
       error_page   500 502 503 504  /50x.html;
       location = /50x.html {
            root   html;
       }
    }

**4.3、校验**

输入网址：https://enjoy.com/a.html

https方式显示页面如下：

![20190814003006232.png][]

查看证书：可看到证书只包含公钥字符串内容

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 9][]

## **五、nginx高可用** ##

**什么是负载均衡高可用****:**

nginx作为负载均衡器，所有请求都到了nginx，可见nginx处于非常重点的位置，如果nginx服务器宕机后端web服务将无法提供服务，影响严重。为了屏蔽负载均衡服务器的宕机，需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。

**Nginx + Keepalived实现高可用****:**

正常的互联网公司都会搭建nginx一主一备，主nginx挂了，备nginx就工作了。而keepalived负责

**Keepalived是什么？**

keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。 Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

关于Keepalived用户后续补充。参考：[https://blog.csdn.net/itcats\_cn/article/details/82454657][https_blog.csdn.net_itcats_cn_article_details_82454657]

### **1、传统的高可用思路** ###

tomcat的高可用的思路，是在tomcat集群前面加一层负载服务nginx。如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 10][]

这种做法，解决了tomcat的高可用问题，但是引入了前面的负载机器的高可用问题（Nginx如果挂了玩完），如果nginx沿用此思路，总会有一个最前端是单机的，存在宕机玩完的风险。

### **2、lvs思想解决高可用问题** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 11][]

如上图，由服务器集群虚拟出来一台 虚拟网关vip（不真实存在，自然不存在宕机问题），

此vip由两台机器共同协商生成。当有一台机器宕机时，另一台机器一样能维持vip。这保证了，只要两台机器不同时宕机，vip就存在

### **3、keepalived配置LVS过程** ###

前提：

1）关闭selinux，打开/etc/sysconfig/selinux设置其中值  à SELINUX=disabled

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 12][]

2）安装必须的依赖包

> yum -y install libnl libnl-devel libnfnetlink-devel

**3.1、keepalived安装**

下载源码包--不能使用yum方式安装（有bug）：

> wget https://www.keepalived.org/software/keepalived-1.3.4.tar.gz

配置(指定安装目录和配置目录，否则文件太散乱)：

> ./configure --prefix=/usr/local/keepalived --sysconf=/etc
> 
> make && make install

**3.2、keepalived主机配置**

打开/etc/keepalived/keepalived.conf，只需要配置如下一段。（其它是多余配置，删除）

[root@localhost keepalived]# cat keepalived.conf
    
    ! Configuration File for keepalived
    global_defs {
       router_id LVS_1 ##唯一标识
    }
    vrrp_script chk_http_port {
        script "/etc/nginx/chk_nginx.sh" # 心跳执行的脚本
        interval 2                       #（检测脚本执行的间隔，单位是秒）
        weight 2
    }
    vrrp_instance VI_1 {
        state one
        interface ens33   #系统网卡
        virtual_router_id 51 #主备两机器一致
        priority 200   #值大的机器，胜出
        advert_int 1 ##每1s检测一次心跳
        authentication {
            auth_type PASS
            auth_pass 1111
    
        }
        track_script {
            chk_http_port            #（调用检测脚本）
        }
        virtual_ipaddress { #可虚拟多个ip
            192.168.200.16
        }
    }

启动keepalived(/usr/local/keepalived/sbin/keepalived)，

查看机器ip地址，可发现多出一个200.16的ip

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 13][]

此时，使用原ip地址244.253能打开的页面，使用200.16也能打开

![20190814003600764.png][]

**3.3、keepalived从机配置**

从机配置与主机过程完全一样，配置文件内以下标识id与优先级稍作变化即可：

[root@localhost keepalived]# cat keepalived.conf
    
    ! Configuration File for keepalived
    global_defs {
       router_id LVS_3 ##唯一标识
    }
    vrrp_script chk_http_port {
        script "/etc/nginx/chk_nginx.sh" # 心跳执行的脚本
        interval 2                       #（检测脚本执行的间隔，单位是秒）
        weight 2
    }
    vrrp_instance VI_3 {
        state one
        interface ens33   #系统网卡
        virtual_router_id 51 #主备两机器一致
        priority 100   #值大的机器，胜出
        advert_int 1 ##每1s检测一次心跳
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        track_script {
            chk_http_port            #（调用检测脚本）
        }
        virtual_ipaddress { #可虚拟多个ip
            192.168.200.16
        }
    }

启动从机的keepalived后，可发现其ip地址无变化

**3.4、keepalived校验LVS效果**

*  此时，杀掉主机上的keepalived，244.200的ip将从主机上消失。而出现的从机的ip中
 *  再次启动主机的keepalived，244.200的ip将被主机重新夺回
 *  此效果是单主单备方式。备机资源有一定的浪费。可以重复前面的动作，虚拟出第二个ip，将主从机优先级颠倒，从而利用起备机服务

**3.5、keepalived监控服务软件**

以上操作中，keepalived很好的实现了LVS功能，即集群机器共同虚拟一个vip，并实现在集群中自动漂移。但假如物理机状况良好，并不能保障其上运行的服务软件ok，因此需要借助keepalived来监控服务软件。

**a、使用keepalived来监控nginx**

编辑一个sh监控脚本，sh脚本：

#!/bin/bash
    A=`ps -C nginx --no-header |wc -l`       #统计nginx进程是否存在
    if [ $A -eq 0 ];
        then      #为0，表明nginx停止了
        /usr/local/nginx/sbin/nginx      #尝试重启nginx
        #nginx重启失败，则keepalived自杀，进行VIP转移      
        if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then    
                  killall keepalived    #杀掉，vip就漫游到另一台机器                
        fi
    
    fi

**b、在配置文件中加入以下两处配置：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 14][]

c、重启keepalived，测试监控效果，如下图操作：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 15][]

nginx已变成不死鸟

Nginx在mvvm模式中的使用：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 16][]

[http_static.chj.com_index.html]: http://static.chj.com//index.html
[20190814001620469.png]: /images/20211018/05254171fc1e42b497ee7f41a983f59d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70]: /images/20211018/b0eacbc35c1843edbd233f653a9abb95.png
[http_test.chj.com_order_hankin_getPage]: http://test.chj.com/order/hankin/getPage%E8%BF%94%E5%9B%9E%E6%AD%A3%E5%B8%B8%E7%BB%93%E6%9E%9C%E3%80%82
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 1]: /images/20211018/65a6495c99a04b2cb9b6c539c7a68fda.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 2]: /images/20211018/27e7fd8e82b74af89b9589fd456566f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 3]: /images/20211018/8034c7b5d4bc44c29e37602502e3393b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 4]: /images/20211018/2416ccb7203049bf80890edefe90eb98.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 5]: /images/20211018/dde1380ac03f44269e8c4c123002aba6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 6]: /images/20211018/908f8cfab3d54e9892a5cad24bc927b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 7]: /images/20211018/cdbf3dfb9e5744af97b128536e3e3a35.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 8]: /images/20211018/e094bbe571f94fcabecbc7ebcd2ec586.png
[20190814003006232.png]: /images/20211018/a0bbe66e121f48b4a9e62041e7e63426.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 9]: /images/20211018/3b0eee90423b4bcc8347f4b91483b9f5.png
[https_blog.csdn.net_itcats_cn_article_details_82454657]: https://blog.csdn.net/itcats_cn/article/details/82454657
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 10]: /images/20211018/58fffd25211d4e6c9e1ec414857a86c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 11]: /images/20211018/3614970472af447ca095f098838f54d3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 12]: /images/20211018/c5e54c4b7168454aa2a0beb9a78ca498.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 13]: /images/20211018/ccb3925071214fc79a48dd23d7215c1d.png
[20190814003600764.png]: /images/20211018/afe2e1a541344adf93db72ceb921f14b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 14]: /images/20211018/bba53868136c423bbd7df4d88bfb0c69.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 15]: /images/20211018/65f8271c40974691a2ffbf1b11f1bbb1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 16]: /images/20211018/b2fc239133f845c0ba705e3d8809c1f0.png