Apache APISIX 网关安全防护实战：WAF 与限流配置指南

作者

API 网关安全防护是微服务架构下将安全能力前移的关键手段，Apache APISIX 作为云原生 API 网关，能在流量入口统一完成身份认证、限流限频与 WAF 拦截，避免每个后端服务各自重复实现。本文介绍 APISIX 的部署与安全插件配置，包括 IP 黑名单、key-auth 认证、limit-req 限流与 ModSecurity WAF 集成，附可直接复制执行的命令。

适用场景

  • 微服务集群对外统一入口，需在网关层做认证与限流
  • API 被恶意调用、撞库或高频爬取，需要限频防护
  • 需要在入口拦截 SQL 注入、XSS 等 Web 攻击，统一 WAF 策略
  • 替换传统 Nginx 配置，用声明式配置管理多服务路由与安全规则

前置条件

  • Docker 20.10+ 或裸机安装（本指南以 Docker Compose 为例）
  • 服务器内存建议 2GB+（APISIX 与 etcd 依赖）
  • 防火墙开放 9080（HTTP 入口）与 9180（Admin API，建议仅内网）

原理说明

APISIX 基于 OpenResty（Nginx + LuaJIT）构建，核心模型是路由 → 插件链 → 上游：请求先匹配 Route，按顺序执行绑定的插件（Plugin），最后转发到 Upstream 后端。安全能力全部由插件提供：ip-restriction 做 IP 黑白名单，key-auth 校验 API Key，limit-req 按令牌桶算法限流，modsecurity 插件将 OWASP CRS 规则集成到网关做 Web 攻击拦截。插件配置通过 Admin API 动态下发，无需重启网关即可生效。

操作步骤

1. Docker Compose 部署

cat > docker-compose.yml <<'EOF'
version: "3.8"
services:
  etcd:
    image: bitnami/etcd:3.5
    environment:
      - ALLOW_NONE_AUTHENTICATION=yes
      - ETCD_ADVERTISE_CLIENT_URLS=http://etcd:2379
  apisix:
    image: apache/apisix:3.9.0-debian
    ports:
      - "9080:9080"
      - "9180:9180"
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro
    depends_on: [etcd]
EOF
docker compose up -d
curl http://127.0.0.1:9080/apisix/admin/routes -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" | head -c 200

Admin API 默认 Key 为 edd1c9f034335f136f87ad84b625c8f1，生产环境必须修改 config.yaml 中的 admin_key。

2. 创建上游与路由

curl -X PUT http://127.0.0.1:9180/apisix/admin/upstreams/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "type": "roundrobin",
  "nodes": {"httpbin.org:80": 1}
}'
curl -X PUT http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "uri": "/anything",
  "upstream_id": 1
}'
# 验证转发
curl http://127.0.0.1:9080/anything

3. 配置 limit-req 限流插件

curl -X PUT http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "uri": "/anything",
  "upstream_id": 1,
  "plugins": {
    "limit-req": {
      "rate": 2,
      "burst": 4,
      "rejected_code": 429,
      "key_type": "var",
      "key": "remote_addr"
    }
  }
}'
# 连续快速请求 7 次，第 7 次应返回 429
for i in $(seq 1 7); do curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9080/anything; done

rate 为每秒允许的请求数，burst 为突发缓冲量，超出后直接返回 429。按客户端 IP 限流可有效抵御 CC 攻击与爬虫。

4. 配置 key-auth 认证

# 创建消费者并分配 Key
curl -X PUT http://127.0.0.1:9180/apisix/admin/consumers \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "username": "app1",
  "plugins": {"key-auth": {"key": "secret-app-key-001"}}
}'
# 路由绑定认证插件
curl -X PATCH http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "plugins": {"key-auth": {}}
}'
# 不带 Key 返回 401，带 Key 正常
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9080/anything
curl -s -o /dev/null -w "%{http_code}\n" -H "apikey: secret-app-key-001" http://127.0.0.1:9080/anything

5. 配置 IP 黑名单

curl -X PATCH http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "plugins": {"ip-restriction": {"blacklist": ["1.2.3.4", "10.0.0.0/8"]}}
}'
# 来自黑名单 IP 的请求返回 403

6. 集成 ModSecurity WAF

# 准备 OWASP CRS 规则（挂载到容器）
mkdir -p ./crs && cd ./crs
git clone --depth 1 https://github.com/coreruleset/coreruleset.git .
cp crs-setup.conf.example crs-setup.conf
# 修改 config.yaml 启用 modsecurity 插件并重启
docker compose restart apisix
# 在路由上启用 WAF 插件
curl -X PATCH http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
  "plugins": {"modsecurity": {
    "deployment": "advance",
    "modsecurity_config": "/usr/local/apisix/conf/crs-setup.conf"
  }}
}'
# 测试 SQL 注入拦截：应返回 403
curl -s -o /dev/null -w "%{http_code}\n" "http://127.0.0.1:9080/anything?id=1%27%20OR%20%271%27%3D%271"

配置验证

  • 不带认证 Key 访问返回 401，带正确 Key 返回 200
  • 循环请求触发限流，超出 rate+burst 的请求返回 429
  • 黑名单 IP 访问返回 403，白名单逻辑反向验证
  • SQL 注入 payload 被 modsecurity 插件拦截返回 403，正常请求不受影响
  • docker compose ps 各容器 healthy；Admin API 修改后 curl http://127.0.0.1:9080/anything 立即生效无需重启

常见问题

FAQ 1：APISIX 与直接用 Nginx 配置限流有什么区别？

Nginx 的 limit_req 写在静态配置中，改规则需 reload；APISIX 的插件通过 Admin API 动态下发并同步到 etcd，秒级生效且支持按路由、按消费者、按上游精细化控制，还可在控制台 Dashboard 可视化配置，适合多服务多团队的网关场景。

FAQ 2：modsecurity 插件会影响性能吗？

会，OWASP CRS 全量规则对每个请求做正则匹配，QPS 会明显下降。建议只对写接口或登录接口开启 WAF 插件，读接口用 limit-req 即可；或将 modsecurity 插件部署为独立插件链，按路由差异化挂载。

FAQ 3：Admin API 暴露公网有什么风险？

风险极高——攻击者可删除路由、关闭认证、添加恶意上游实现流量劫持。务必仅监听内网端口（9180 不对公网开放），更换 admin_key 并限制来源 IP；结合审计日志（access 日志）监控 Admin API 的异常调用。

总结

APISIX 让 API 安全策略实现”一处配置、全网生效”：key-auth 守住入口身份、limit-req 遏制高频滥用、ip-restriction 阻断恶意来源、modsecurity 拦截注入类攻击。建议按接口重要程度分级挂载插件：公开读接口做限流，敏感写接口叠加认证与 WAF，并将 Admin API 严格内网化，即可构建可靠的网关层安全防线。