Swoole外部访问控制列表配置方法

Swoole无内置外部ACL机制，因其是PHP扩展而非独立服务，所有访问控制须由PHP代码实现；外部规则需通过Redis/MySQL等主动加载，或交由Nginx、WAF等前置网关统一管控。

Swoole 本身不提供「外部 ACL 配置文件」或类似 Nginx 的 access_list 指令，所有访问控制逻辑必须由 PHP 代码实现，不存在加载 acl.conf 或读取系统级 ACL 表的机制。

为什么 Swoole 没有内置外部 ACL 支持

Swoole 是一个 PHP 扩展级网络引擎，不是独立服务进程（如 Nginx、Redis），它不解析配置文件中的访问策略，也不维护全局 ACL 规则表。它的权限模型完全依赖应用层编码——你写什么逻辑，就执行什么控制。

• 没有 swoole.acl 配置项，php.ini 和 swoole_server->set() 中均无相关参数
• 不会自动读取 /etc/hosts.allow、/etc/hosts.deny 或自定义 ACL 文件
• 所谓“外部 ACL”，在 Swoole 场景下只能指：把规则存到 Redis / MySQL / JSON 文件中，再由 PHP 主动加载判断

如何用 Redis 实现可热更新的 IP 白名单 ACL

这是最贴近“外部 ACL”需求的实用方案：规则存在 Redis，PHP 运行时动态拉取，无需重启服务。

• 用 SET 存白名单：redis-cli SADD acl:ip_whitelist "192.168.1.100" "203.0.113.0/24"
• 在 onRequest 中调用 $redis->sIsMember('acl:ip_whitelist', $ip) 判断是否放行
• 对 CIDR 段需额外解析：用 ip2long() + 位运算比对，不能直接用 SISMEMBER
• 注意连接复用：避免每次请求都 new Redis 实例，应使用连接池或协程客户端（如 coRedis）

用 MySQL 表模拟 ACL 规则时的典型陷阱

有人试图建一张 acl_rules 表来管理路径+角色+动作，但容易踩三个坑：

• 没加索引：WHERE path = ? AND role = ? 必须在 (path, role) 上建联合索引，否则高并发下查表变瓶颈
• 缓存缺失：每次请求都查 DB → 建议用 apcu_add() 缓存结果，TTL 设 10–30 秒，避免雪崩
• 规则优先级混乱：比如 GET /api/user/* → deny 和 GET /api/user/profile → allow 冲突，必须明确定义匹配顺序（前缀最长匹配 or 显式 priority 字段）

真正需要外部 ACL 时，应该交给前置网关

如果你的场景要求「不改代码就能开关某 IP 段访问」或「按小时粒度更新策略」，Swoole 不是合适位置——这类策略应下沉到更外层：

• Nginx 的 allow/deny 指令（配合 geo 模块或 Lua 脚本）
• 云厂商 WAF（如阿里云 Web 应用防火墙）的 IP 黑白名单功能
• Kubernetes Ingress 的 nginx.ingress.kubernetes.io/whitelist-source-range 注解

这些才是真正的「外部」且「声明式」ACL。Swoole 只负责处理已通过网关的合法请求，不该承担边界防护职责。