失眠网 > 高性能微服务网关APISIX - 常用插件（1）

高性能微服务网关APISIX - 常用插件（1）

时间：2023-08-30 04:26:21

APISIX 插件机制

Plugin表示将在HTTP请求/响应生命周期期间执行的插件配置。

Plugin配置可直接绑定在Route上，也可以被绑定在Service或Consumer上。而对于同一个插件的配置，只能有一份是有效的，配置选择优先级总是Consumer>Route>Service。

在conf/config.yaml中，可以声明本地 APISIX 节点都支持哪些插件。这是个白名单机制，不在该白名单的插件配置，都将会被自动忽略。这个特性可用于临时关闭或打开特定插件，应对突发情况非常有效。如果你想在现有插件的基础上新增插件，注意需要拷贝conf/config-default.yaml的插件节点内容到conf/config.yaml的插件节点中。

插件的配置可以被直接绑定在指定 Route 中，也可以被绑定在 Service 中，不过 Route 中的插件配置优先级更高。

一个插件在一次请求中只会执行一次，即使被同时绑定到多个不同对象中（比如 Route 或 Service）。插件运行先后顺序是根据插件自身的优先级来决定的，优先级越高的插件将会被先执行，例如：

local _M = {version = 0.1,priority = 0, -- 这个插件的优先级为 0name = plugin_name,schema = schema,metadata_schema = metadata_schema,}

插件配置作为 Route 或 Service 的一部分提交的，放到plugins下。它内部是使用插件名字作为哈希的 key 来保存不同插件的配置项。

{..."plugins": {"limit-count": {"count": 2,"time_window": 60,"rejected_code": 503,"key": "remote_addr"},"prometheus": {}}}

并不是所有插件都有具体配置项，比如prometheus下是没有任何具体配置项，这时候用一个空的对象标识即可。

如果一个请求因为某个插件而被拒绝，会有类似这样的 warn 日志：ip-restriction exits with http status code 403。

热加载

APISIX 的插件是热加载的，不管你是新增、删除还是修改插件，都不需要重启服务。

只需要通过 admin API 发送一个 HTTP 请求即可：

curl http://127.0.0.1:9080/apisix/admin/plugins/reload -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT

注意：如果你已经在路由规则里配置了某个插件（比如在route的plugins字段里面添加了它），然后禁用了该插件，在执行路由规则的时候会跳过这个插件。

redirect

URI 重定向插件。

参数

http_to_https，uri或regex_uri三个中只能配置一个。

示例

启用插件

下面是一个基本实例，为特定路由启用redirect插件：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/test/index.html","plugins": {"redirect": {"uri": "/test/default.html","ret_code": 301}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:80": 1}}}'

我们可以在新的 URI 中使用 Nginx 内置的任意变量：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/test","plugins": {"redirect": {"uri": "$uri/index.html","ret_code": 301}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:80": 1}}}'

测试

测试示例基于上述例子：

$ curl http://127.0.0.1:9080/test/index.html -iHTTP/1.1 301 Moved PermanentlyDate: Wed, 23 Oct 13:48:23 GMTContent-Type: text/htmlContent-Length: 166Connection: keep-aliveLocation: /test/default.html...

我们可以检查响应码和响应头中的Location参数，它表示该插件已启用。

下面是一个实现 http 到 https 跳转的示例：```shellcurl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/hello","plugins": {"redirect": {"http_to_https": true}}}'

禁用插件

移除插件配置中相应的 JSON 配置可立即禁用该插件，无需重启服务：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/test/index.html","plugins": {},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:80": 1}}}'

这时该插件已被禁用。

response-rewrite

简介

该插件支持修改上游服务或网关本身返回的 body 和 header 信息。

使用场景： 1、可以设置Access-Control-Allow-*等 header 信息，来实现 CORS （跨域资源共享）的功能。 2、另外也可以通过配置 status_code 和 header 里面的 Location 来实现重定向，当然如果只是需要重定向功能，最好使用 redirect 插件。

配置参数

示例

开启插件

下面是一个示例，在指定的 route 上开启了response-rewrite插件：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"methods": ["GET"],"uri": "/test/index.html","plugins": {"response-rewrite": {"body": "{\"code\":\"ok\",\"message\":\"new json body\"}","headers": {"X-Server-id": 3,"X-Server-status": "on","X-Server-balancer_addr": "$balancer_ip:$balancer_port"},"vars":[[ "status","==",200 ]]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:80": 1}}}'

测试插件

基于上述配置进行测试：

curl -X GET -i http://127.0.0.1:9080/test/index.html

Copy

如果看到返回的头部信息和内容都被修改了，即表示response-rewrite插件生效了,vars将确保仅覆盖状态为 200 的响应。

HTTP/1.1 200 OKDate: Sat, 16 Nov 09:15:12 GMTTransfer-Encoding: chunkedConnection: keep-aliveX-Server-id: 3X-Server-status: onX-Server-balancer_addr: 127.0.0.1:80{"code":"ok","message":"new json body"}

禁用插件

禁用response-rewrite插件很简单。你不需要重新启动服务，只需要在插件配置中删除相应的 json 配置，它将立即生效。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"methods": ["GET"],"uri": "/test/index.html","upstream": {"type": "roundrobin","nodes": {"127.0.0.1:80": 1}}}'

注意事项

ngx.exit将中断当前请求的执行，并返回状态码给 Nginx。

但是很多人可能会对ngx.exit理解出现偏差，即如果你在access阶段执行ngx.exit，只是中断了请求处理阶段，响应阶段仍然会处理。比如，如果你配置了response-rewrite插件，它会强制覆盖你的响应信息（如响应代码）。

cors

简介

cors插件可以让你为服务端启用 CORS 的返回头。

属性

提示
请注意allow_credential是一个很敏感的选项，谨慎选择开启。开启之后，其他参数默认的*将失效，你必须显式指定它们的值。使用**时要充分理解它引入了一些安全隐患，比如 CSRF，所以确保这样的安全等级符合自己预期再使用。

如何启用

创建Route或Service对象，并配置cors插件。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/hello","plugins": {"cors": {}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:8080": 1}}}'

测试插件

请求下接口，发现接口已经返回了CORS相关的header，代表插件生效

curl http://127.0.0.1:9080/hello -v...< Server: APISIX web server< Access-Control-Allow-Origin: *< Access-Control-Allow-Methods: *< Access-Control-Allow-Headers: *< Access-Control-Expose-Headers: *< Access-Control-Max-Age: 5...

禁用插件

当你想去掉cors插件的时候，很简单，在插件的配置中把对应的 json 配置删除即可，无须重启服务，即刻生效：

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/hello","plugins": {},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:8080": 1}}}'

现在就已经移除了cors插件了。其他插件的开启和移除也是同样的方法。

uri-blocker

定义

该插件可帮助我们拦截用户请求，只需要指定block_rules即可。

属性列表

启用方式

这是一个示例，在指定的路由上启用uri blocker插件：

curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/*","plugins": {"uri-blocker": {"block_rules": ["root.exe", "root.m+"]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

测试插件

$ curl -i http://127.0.0.1:9080/root.exe?a=aHTTP/1.1 403 ForbiddenDate: Wed, 17 Jun 13:55:41 GMTContent-Type: text/html; charset=utf-8Content-Length: 150Connection: keep-aliveServer: APISIX web server... ...

如果你设置了属性rejected_msg的值为"access is not allowed"，将会收到如下的响应体：

禁用插件

当想禁用uri blocker插件时，非常简单，只需要在插件配置中删除相应的 json 配置，无需重启服务，即可立即生效：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/*","upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

uri blocker插件现在已被禁用，它也适用于其他插件。

ip-restriction

名字

ip-restriction可以通过以下方式限制对服务或路线的访问，将 IP 地址列入白名单或黑名单。单个 IP 地址，多个 IP 地址或 CIDR 范围，可以使用类似 10.10.10.0/24 的 CIDR 表示法。

属性

只能单独启用白名单或黑名单，两个不能一起使用。message可以由用户自定义。

如何启用

下面是一个示例，在指定的 route 上开启了ip-restriction插件:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}},"plugins": {"ip-restriction": {"whitelist": ["127.0.0.1","113.74.26.106/24"]}}}'

当未允许的IP访问时，默认返回{"message":"Your IP address is not allowed"}。如果你想使用自定义的message，可以在插件部分进行配置:

"plugins": {"ip-restriction": {"whitelist": ["127.0.0.1","113.74.26.106/24"],"message": "Do you want to do something bad?"}}

测试插件

通过127.0.0.1访问：

$ curl http://127.0.0.1:9080/index.html -iHTTP/1.1 200 OK...

通过127.0.0.2访问：

$ curl http://127.0.0.1:9080/index.html -i --interface 127.0.0.2HTTP/1.1 403 Forbidden...{"message":"Your IP address is not allowed"}

禁用插件

当你想去掉ip-restriction插件的时候，很简单，在插件的配置中把对应的 json 配置删除即可，无须重启服务，即刻生效：

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {},"upstream": {"type": "roundrobin","nodes": {"39.97.63.215:80": 1}}}'

现在就已移除ip-restriction插件，其它插件的开启和移除也类似。

proxy-mirror

代理镜像插件，该插件提供了镜像客户端请求的能力。

注：镜像请求返回的响应会被忽略。

参数

示例

启用插件

示例1：为特定路由启用proxy-mirror插件：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"plugins": {"proxy-mirror": {"host": "http://127.0.0.1:9797"}},"upstream": {"nodes": {"127.0.0.1:1999": 1},"type": "roundrobin"},"uri": "/hello"}'

测试：

$ curl http://127.0.0.1:9080/hello -iHTTP/1.1 200 OKContent-Type: application/octet-streamContent-Length: 12Connection: keep-aliveServer: APISIX web serverDate: Wed, 18 Mar 13:01:11 GMTLast-Modified: Thu, 20 Feb 14:21:41 GMThello world

由于指定的 mirror 地址是127.0.0.1:9797，所以验证此插件是否已经正常工作需要在端口为9797的服务上确认，例如，我们可以通过 python 启动一个简单的 server： python -m SimpleHTTPServer 9797。

禁用插件

移除插件配置中相应的 JSON 配置可立即禁用该插件，无需重启服务：

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/hello","plugins": {},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1999": 1}}}'

这时该插件已被禁用。

traffic-split

名字

traffic-split 插件使用户可以逐步引导各个上游之间的流量百分比。

注：由于加权循环算法（特别是在重置wrr状态时）的缺点，因此每个上游之间的比率可能不太准确。

属性

目前在weighted_upstreams.upstream的配置中，不支持的字段有： service_name、discovery_type、checks、retries、retry_timeout、desc、scheme、labels、create_time 和 update_time。但是你可以通过weighted_upstreams.upstream_id绑定upstream对象来实现他们。

traffic-split 插件主要由match和weighted_upstreams两部分组成，match是自定义的条件规则，weighted_upstreams是 upstream 的配置信息。如果配置match和weighted_upstreams信息，那么在match规则校验通过后，会根据weighted_upstreams中的weight值；引导插件中各个 upstream 之间的流量比例，否则，所有流量直接到达route或service上配置的upstream。当然你也可以只配置weighted_upstreams部分，这样会直接根据weighted_upstreams中的weight值，引导插件中各个 upstream 之间的流量比例。

注：1、在match里，vars 中的表达式是and的关系，多个vars之间是or的关系。2、在插件的 weighted_upstreams 域中，如果存在只有weight的结构，表示route或service上的 upstream 流量权重值。例如：

"weighted_upstreams": [......{"weight": 2}]

如何启用

创建一个路由并启用traffic-split插件，在配置插件上游信息时，有以下两种方式：

1、通过插件中的upstream属性配置上游信息。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {"traffic-split": {"rules": [{"weighted_upstreams": [{"upstream": {"name": "upstream_A","type": "roundrobin","nodes": {"127.0.0.1:1981":10},"timeout": {"connect": 15,"send": 15,"read": 15}},"weight": 1},{"weight": 1}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

2、通过插件中的upstream_id属性绑定上游服务。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {"traffic-split": {"rules": [{"weighted_upstreams": [{"upstream_id": 1,"weight": 1},{"weight": 1}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

注：1、通过upstream_id方式来绑定已定义的上游，它可以复用上游具有的健康检测、重试等功能。2、支持upstream和upstream_id的两种配置方式一起使用。

示例

灰度发布

缺少match规则部分，根据插件中weighted_upstreams配置的weight值做流量分流。将插件的 upstream与route 的 upstream按 3:2 的流量比例进行划分，其中 60% 的流量到达插件中的1981端口的 upstream， 40% 的流量到达 route 上默认1980端口的 upstream。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {"traffic-split": {"rules": [{"weighted_upstreams": [{"upstream": {"name": "upstream_A","type": "roundrobin","nodes": {"127.0.0.1:1981":10},"timeout": {"connect": 15,"send": 15,"read": 15}},"weight": 3},{"weight": 2}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

插件测试:

请求5次，3次请求命中插件1981端口的 upstream, 2次请求命中route的1980端口 upstream。

$ curl http://127.0.0.1:9080/index.html -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8hello 1980$ curl http://127.0.0.1:9080/index.html -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8world 1981......

蓝绿发布

通过请求头获取match规则参数(也可以通过请求参数获取或NGINX变量)，在match规则匹配通过后，表示所有请求都命中到插件配置的 upstream ，否则所以请求只命中route上配置的 upstream 。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {"traffic-split": {"rules": [{"match": [{"vars": [["http_release","==","new_release"]]}],"weighted_upstreams": [{"upstream": {"name": "upstream_A","type": "roundrobin","nodes": {"127.0.0.1:1981":10}}}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

插件测试：

match规则匹配通过，所有请求都命中插件配置的1981端口 upstream ：

$ curl http://127.0.0.1:9080/index.html -H 'release: new_release' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......world 1981

match规则匹配失败，所有请求都命中route上配置的 1980端口 upstream ：

$ curl http://127.0.0.1:9080/index.html -H 'release: old_release' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......hello 1980

自定义发布

match中可以设置多个vars规则，vars中的多个表达式之间是add的关系，多个vars规则之间是or的关系；只要其中一个 vars 规则通过，则整个match通过。

示例1：只配置了一个vars规则，vars中的多个表达式是add的关系。在weighted_upstreams中根据weight值将流量按 3:2 划分，其中只有weight值的部分表示route上的 upstream 所占的比例。当match匹配不通过时，所有的流量只会命中 route 上的 upstream 。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {"traffic-split": {"rules": [{"match": [{"vars": [["arg_name","==","jack"],["http_user-id",">","23"],["http_apisix-key","~~","[a-z]+"]]}],"weighted_upstreams": [{"upstream": {"name": "upstream_A","type": "roundrobin","nodes": {"127.0.0.1:1981":10}},"weight": 3},{"weight": 2}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

插件设置了请求的match规则及端口为1981的 upstream，route 上具有端口为1980的 upstream。

插件测试：

1、在match规则校验通过后, 60% 的请求命中到插件的1981端口的 upstream, 40% 的请求命中到route的1980端口的 upstream。

match 规则校验成功，命中端口为1981的 upstream。

$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......world 1981

match 规则校验失败，，命中默认端口为1980的 upstream。

$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......hello 1980

在请求5次后，3次命中1981端口的服务，2次命中1980端口的服务。

2、match规则校验失败(缺少请求头apisix-key), 响应都为默认 upstream 的数据hello 1980。

$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......hello 1980

示例2：配置多个vars规则，vars中的多个表达式是add的关系，多个vars之间是or的关系。根据weighted_upstreams中的weight值将流量按 3:2 划分，其中只有weight值的部分表示 route 上的 upstream 所占的比例。当match匹配不通过时，所有的流量只会命中 route 上的 upstream 。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/index.html","plugins": {"traffic-split": {"rules": [{"match": [{"vars": [["arg_name","==","jack"],["http_user-id",">","23"],["http_apisix-key","~~","[a-z]+"]]},{"vars": [["arg_name2","==","rose"],["http_user-id2","!",">","33"],["http_apisix-key2","~~","[a-z]+"]]}],"weighted_upstreams": [{"upstream": {"name": "upstream_A","type": "roundrobin","nodes": {"127.0.0.1:1981":10}},"weight": 3},{"weight": 2}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

插件设置了请求的match规则及端口为1981的 upstream，route 上具有端口为1980的 upstream 。

测试插件：

1、两个vars的表达式匹配成功，match规则校验通过后, 60% 的请求命中到插件的1981端口 upstream, 40% 的请求命中到route的1980端口upstream。

$ curl 'http://127.0.0.1:9080/index.html?name=jack&name2=rose' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......world 1981

在请求5次后，3次命中1981端口的服务，2次命中1980端口的服务。

2、第二个vars的表达式匹配失败（缺少name2请求参数），match规则校验通过后, 60% 的请求命中到插件的1981端口 upstream, 40% 的请求流量命中到route的1980端口 upstream。

$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......world 1981

在请求5次后，3次命中1981端口的服务，2次命中1980端口的服务。

3、两个vars的表达式校验失败（缺少name和name2请求参数），match规则校验失败, 响应都为默认route的 upstream 数据hello 1980。

$ curl 'http://127.0.0.1:9080/index.html?name=jack' -iHTTP/1.1 200 OKContent-Type: text/html; charset=utf-8......hello 1980

匹配规则与上游对应

通过配置多个rules，我们可以实现不同的匹配规则与上游一一对应。

示例：

当请求头x-api-id等于 1 时，命中 1981 端口的上游；当x-api-id等于 2 时，命中 1982 端口的上游；否则，命中 1980 端口的上游（上游响应数据为对应的端口号）。

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"uri": "/hello","plugins": {"traffic-split": {"rules": [{"match": [{"vars": [["http_x-api-id","==","1"]]}],"weighted_upstreams": [{"upstream": {"name": "upstream-A","type": "roundrobin","nodes": {"127.0.0.1:1981":1}},"weight": 3}]},{"match": [{"vars": [["http_x-api-id","==","2"]]}],"weighted_upstreams": [{"upstream": {"name": "upstream-B","type": "roundrobin","nodes": {"127.0.0.1:1982":1}},"weight": 3}]}]}},"upstream": {"type": "roundrobin","nodes": {"127.0.0.1:1980": 1}}}'

测试插件：

请求头x-api-id等于 1，命中带 1981 端口的上游。

$ curl http://127.0.0.1:9080/hello -H 'x-api-id: 1'1981

请求头x-api-id等于 2，命中带 1982 端口的上游。

$ curl http://127.0.0.1:9080/hello -H 'x-api-id: 2'1982

请求头x-api-id等于 3，规则不匹配，命中带 1980 端口的上游。

$ curl http://127.0.0.1:9080/hello -H 'x-api-id: 3'1980