Nginx之rewrite、防盗链、高可用配置（2025）

一、rewrite（对请求的 URI 进行重写）

rewrite 是 Nginx 中一个非常强大的指令，用于对请求的 URI 进行重写（即修改请求的路径）。它通常用于实现 URL 重定向、SEO 优化、隐藏实际的资源路径等功能。

rewrite 指令的基本语法如下：

rewrite <regex> <replacement> [flag];

• <regex>：正则表达式，用于匹配请求的 URI。

• <replacement>：替换后的 URI 或重定向的目标地址。

• [flag]：可选的标志，用于控制重写的行为。常见的标志包括：

  • last：完成当前的重写操作后，重新检查新的 URI 是否匹配其他 location 块。

  • break：完成当前的重写操作后，停止进一步的重写操作，直接进入当前 location 块的处理。

  • redirect：返回 302 临时重定向响应，告诉客户端请求的新位置。

  • permanent：返回 301 永久重定向响应，告诉客户端请求的新位置。

案例1：

将 /old-path 重写为 /new-path

server {
    listen 80;
    server_name example.com;

    location /old-path {
        rewrite ^/old-path(.*)$ /new-path$1 last;
    }
}

rewrite ^/old-path(.*)$ /new-path$1 last;

• 作用：对匹配到的请求路径进行重写。

• 详细解释：

  • 正则表达式：^/old-path(.*)$

    • ^ 表示匹配 URI 的开头。

    • /old-path 是要匹配的路径前缀。

    • (.*) 是一个捕获组，用于匹配 /old-path 后面的任何内容（包括空字符串），并将其捕获到变量 $1 中。

    • $ 表示匹配 URI 的结尾。

  • 替换规则：/new-path$1

    • 将匹配到的 URI 重写为 /new-path，并附加捕获组 $1 的内容。

    • 例如，如果请求的 URI 是 /old-path/somefile，则捕获组 $1 的内容是 /somefile，最终重写后的 URI 是 /new-path/somefile。

  • 标志：last

    • 表示完成当前的重写操作后，Nginx 会重新检查新的 URI 是否匹配其他 location 块。

    • 这意味着重写后的 URI /new-path/somefile 会重新进入 Nginx 的 location 匹配流程，可能会匹配到其他更具体的 location 块。

案例2：

如果你希望将 /product?id=123 重写为 /product/123，可以使用如下规则：

location /product {
    rewrite ^/product\?id=(\d+)$ /product/$1 last;
}

• ^/product\?id=(\d+)$ 是正则表达式，匹配 /product?id=数字 的格式。

• $1 是捕获的分组，表示匹配到的数字部分。

• /product/$1 是替换后的 URI。

案例3：

如果你希望将所有请求从 old.example.com 重定向到 new.example.com，可以在 server 块中添加如下规则：

server {
    listen 80;  # 监听 HTTP 端口
    server_name old.example.com;  # 指定旧域名

    # 永久重定向到新域名，并保留请求的 URI 部分
    return 301 http://new.example.com$request_uri;
}

• listen 80：表示监听 HTTP 的默认端口（80）。

• server_name old.example.com：指定该 server 块处理的域名。

• return 301 http://new.example.com$request_uri：

  • 301 表示返回 HTTP 状态码 301，即永久重定向。

  • http://new.example.com 是目标域名。

  • $request_uri 是 Nginx 的内置变量，表示请求的 URI 部分（包括路径和查询参数）。通过这种方式，可以确保重定向后保留原始请求的路径和参数。

二、防盗链配置

2.1 如何配置使用

通过检查 HTTP 请求头中的 Referer 字段来判断请求的来源是否合法。如果来源不在允许的范围内，Nginx 将拒绝该请求。

valid_referers 指令的语法如下：

valid_referers none | blocked | server_names | strings;

参数说明

• none：

  • 允许没有 Referer 头部的请求。例如，用户直接在浏览器地址栏输入资源的 URL。

• blocked：

  • 允许 Referer 头部为空或包含非法字符的请求。这通常用于处理某些代理服务器或浏览器可能发送的空 Referer。

• server_names：

  • 允许来自指定域名的请求。可以指定多个域名，用空格分隔。

• strings：

  • 允许来自包含指定字符串的 Referer 的请求。可以使用正则表达式来匹配特定的字符串。

示例

valid_referers none blocked server_names example.com www.example.com ~\.google\.;

• 这个配置表示：

  • 允许没有 Referer 头部的请求。

  • 允许 Referer 头部为空或包含非法字符的请求。

  • 允许来自 example.com 和 www.example.com 的请求。

  • 允许 Referer 中包含 .google. 的请求。

2.2使用curl测试

1. 测试没有 Referer 头部的请求

如果配置了 valid_referers none，这种请求应该是允许的。

curl -I http://example.com/path/to/image.jpg

• 参数说明：

  • -I：仅获取 HTTP 响应头，不获取响应体。

• 预期结果：

  • 如果配置正确，应该返回资源的内容（如 200 OK）。

2. 测试带有合法 Referer 的请求

如果配置了 valid_referers server_names example.com，这种请求应该是允许的。

curl -I -e "http://example.com" http://example.com/path/to/image.jpg

• 参数说明：

  • -e "http://example.com"：设置 Referer 头部为 http://example.com。

• 预期结果：

  • 如果配置正确，应该返回资源的内容（如 200 OK）。

三、高可用配置

用 Keepalived 监测两台 Nginx 服务器并实现故障转移

3.1安装Keepalived

3.1.1编译安装

下载地址

https://www.keepalived.org/download.html#

使用 ./configure 编译安装

如遇报错提示

configure: error:
!!! OpenSSL is not properly installed on your system. !!!
!!! Can not include OpenSSL headers files. !!!

安装依赖

yum install openssl-devel

3.1.2yum安装

yum install keepalived

3.2 配置

以yum安装的为例，使用yum安装后配置文件在：

/etc/keepalived/keepalived.conf

3.2.1第一台机器配置

! Configuration File for keepalived
global_defs {
    router_id lb111
}
vrrp_instance atguigu {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.44.200
    }
}

3.2.2第二台机器配置

! Configuration File for keepalived
global_defs {
    router_id lb110
}
vrrp_instance atguigu {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.44.200
    }
}

3.3启动服务

systemctl start keepalived