核心接口白名单鉴权是重构访问信任模型，只放行明确声明的合法请求，其余一律拒绝；关键在于将“谁可以调用”从后端代码抽离为可配置、可审计、可联动的安全策略，需锁定真实入口点、分层组合IP/Token/域名/证书等维度，并在网关层统一拦截与动态验证。
核心接口白名单鉴权不是加一层“开关”，而是重构访问信任模型：只放行明确声明的合法请求，其余一律拒绝。关键在于把“谁可以调用”这件事，从后端代码逻辑里抽出来，变成可配置、可审计、可联动的安全策略。
锁定真正需要保护的入口点
很多团队一上来就改业务代码，结果加固了前端登录页，却漏掉了后端 Gateway 或模型推理 API。必须先定位真实攻击面：
- 查服务监听地址——比如 ClawdBot 的 18780 端口 是 gateway 入口，不是 7860 前端端口；
- 识别协议类型——HTTP、WebSocket、gRPC 需分别设防；
- 区分内部调用与外部暴露——K8s Service 内部通信通常走 DNS 名称，公网访问才需 IP 白名单。
分层设置白名单，避免单点失效
单一维度（如只靠 IP）容易被绕过，推荐组合使用：
- IP + Token 绑定：允许特定内网段（如 192.168.1.0/24）发起请求，但必须携带有效 JWT；
- 域名 + Referer 校验：仅放行来自可信前端域名（如 app.yourcompany.com）且 Referer 匹配的请求；
- 客户端证书 + 用户角色：对高权限操作（如模型重载、日志导出）强制双向 TLS，并在 JWT Payload 中嵌入 role 字段做二次校验。
用网关层统一拦截，别依赖业务代码
把鉴权逻辑下沉到 API 网关或反向代理（如 Nginx、Spring Cloud Gateway、Traefik），好处是：
- 所有流量必经之路，无遗漏；
- 配置热更新，无需重启服务；
- 可结合 Redis 实现动态白名单——例如运维后台提交新 IP，5 秒内生效。
示例（Nginx 配置片段）：
location /api/v1/inference {allow 192.168.1.100;
allow 10.0.0.5;
deny all;
auth_request /auth/jwt;
}
持续验证白名单有效性
白名单不是“设完就放心”。要主动验证它是否真起作用：
- 定期扫描：用 nmap 或 curl 模拟未授权 IP 访问，确认返回 403 而非 200；
- 日志审计：开启网关 access log，筛选被拒绝请求，分析是否出现误拦或漏放；
- 行为基线比对：如果某白名单 IP 突然每秒发 50 次请求，应触发告警而非放行——白名单管“身份”，不管“行为”。
