缓存清理接口必须实施“身份+来源”双重校验：白名单限定可信ip（办公网、跳板机、ci/cd服务器），禁用0.0.0.0/0；黑名单动态拦截异常请求；应用层二次校验ip与权限；配套限流、otp令牌、审计日志及https全链路防护。
缓存清理接口（如 /api/clear-cache）属于高危管理类接口，一旦暴露或未加防护，极易被恶意调用导致缓存雪崩、服务抖动甚至业务中断。仅靠鉴权（如 token）不够——攻击者可能窃取凭证或利用弱口令暴力破解。必须叠加基于 IP 的黑白名单机制，形成“身份+来源”双重校验。核心思路是：白名单优先、黑名单兜底、动静结合、日志可溯。
明确白名单范围，只放行可信运维入口
缓存清理操作应严格限制在内部网络或指定运维通道：
- 允许公司办公网出口 IP 段（如
10.20.0.0/16）、跳板机固定 IP、CI/CD 发布服务器 IP； - 禁止使用
0.0.0.0/0或开放公网段（如114.114.114.0/24）作为白名单； - 若使用云厂商 SLB/Nginx 网关，需确认真实客户端 IP 是否已通过
X-Forwarded-For正确透传，并在白名单规则中匹配该头字段（而非直接匹配 SLB 内网 IP）； - 白名单配置后，务必关闭默认放行逻辑——例如 Nginx 中先写
deny all;，再逐条allow，顺序不可颠倒。
动态维护黑名单，自动拦截异常调用行为
单靠静态黑名单易滞后，需结合实时行为识别：
- 对非白名单 IP 访问该接口的请求，全部记录到独立审计日志（含时间、IP、User-Agent、响应码）；
- 用脚本或工具（如 fail2ban）扫描日志：5 分钟内触发 ≥3 次 401/403 或 ≥1 次 200 响应，即自动将该 IP 加入黑名单；
- 黑名单规则应限定在路径级，例如只对
location /api/clear-cache { deny 1.2.3.4; }生效，避免误封整个站点； - 设置自动过期机制（如 2 小时后自动移出），防止长期误封影响合作方临时调试。
在应用层（Spring Boot）做二次校验
网关层拦截是第一道防线，但业务代码中仍需兜底校验，防绕过：
- 自定义
@CacheClearPermission注解，在对应 Controller 方法上标注； - 通过
HandlerInterceptor获取真实客户端 IP（建议复用知识库中IpUtils类，兼容代理场景）； - 查询内存缓存（如 Caffeine）或 Redis 中的白名单集合，比对当前 IP 是否命中；
- 若不匹配且非管理员账号，直接返回
403 Forbidden并记录告警事件，不执行后续清理逻辑。
配套加固措施不能少
黑白名单不是孤立策略，需与其它机制联动提升整体水位：
- 为该接口单独配置限流：白名单 IP 允许 5 次/分钟，非白名单 IP 仅 1 次/小时；
- 强制要求携带一次性操作令牌（OTP），由运维平台生成并限时 5 分钟，避免 token 复用；
- 所有成功清理操作必须写入审计数据库，包含操作人、IP、清理范围（如 “user:*”）、耗时，供事后追溯；
- 禁用 HTTP 协议访问，确保 HTTPS server 块中同样配置了相同黑白名单规则（HTTP 和 HTTPS 是两个独立 server，常被遗漏）。
