IP 允许列表或拒绝列表是否可靠，取决于 API 网关所判断的地址是否可信。应先建立可信代理路径，只接受已知跳点提供的转发地址，然后再应用列表。对于规模小且受控、适合默认拒绝的调用群体，可以使用允许列表；拒绝列表则应作为有针对性的响应层，而不能当作完整的身份或授权机制。
IP 规则只是网络上下文，不能证明具体是哪位用户、哪个工作负载或租户发起请求。在 NAT、运营商网络、正向代理、IPv6 隐私地址以及不断变化的云地址范围下，其精度还会降低。
核心要点
- 不能因为
X-Forwarded-For存在就信任它。 - 让第一个可信代理覆盖不可信转发请求头，并配置准确的可信代理范围。
- 私有管理和固定合作方入口优先使用允许列表；拒绝列表应服务于有负责人和到期时间的明确威胁。
- 将 CIDR 变更视为生产变更，执行审查、预发布、回滚和审计留痕。
- IP 策略必须与认证、授权、限流和监控结合。
建立地址信任边界
直接 TCP 对端可能是 CDN、负载均衡器、入口代理、服务网格边车（Sidecar），也可能就是客户端。转发请求头可以携带原始地址，但直接连接到未受保护监听器的客户端同样能写入该请求头。
Apache APISIX 的安全威胁模型将请求头视为攻击者可控输入，除非部署明确建立了信任。安全设计应回答：
- 哪个组件是第一个可信跳点？
- 它是否先删除传入的转发请求头，再写入自己的值？
- 该组件能从哪些准确地址范围连接？
- 如何解释多个代理跳点？
- 流量能否绕过代理直接到达 APISIX？
如果绕过路径仍然开放，再正确的请求头解析规则也无法恢复信任。
选择允许列表还是拒绝列表
| 策略 | 最适合的场景 | 主要故障模式 |
|---|---|---|
| 允许列表 | 管理 API、私有服务、固定 B2B 合作方、已知边缘范围 | 地址范围变化后阻断合法调用方 |
| 拒绝列表 | 短期事故响应、已知恶意基础设施、法律或政策封禁 | 攻击者轮换地址，过期条目不断累积 |
允许列表只包含少量已知良好网络，其他网络默认拒绝。只有调用方群体可控时，这种强默认策略才可行。公共 API 通常无法枚举所有合法的移动或家庭网络地址。
拒绝列表保持公共可达性，但本质上是被动响应。每个条目都应有原因、证据、负责人、范围和到期时间。庞大且永久的列表会增加运维复杂度，却仍可能漏掉分布式滥用。
在 APISIX 中恢复客户端地址
APISIX real-ip 插件可以从指定请求头派生客户端地址，但只有可信代理地址才能影响该结果。Apache APISIX 3.18 的实现要求所用构建包含 APISIX-Runtime，才能修改请求处理中的客户端地址；如果缺少该运行时支持，插件会返回 501。如果所用发行版不包含 APISIX-Runtime，应先在可信代理或受支持的 NGINX real-IP 配置中恢复地址，再应用 ip-restriction。
以下 Apache APISIX 3.18 配置片段假设已满足该运行时要求，并且 10.20.0.0/16 和 192.0.2.10 是当前部署中准确的内部代理来源：
1{
2 "plugins": {
3 "real-ip": {
4 "source": "http_x_forwarded_for",
5 "trusted_addresses": [
6 "10.20.0.0/16",
7 "192.0.2.10"
8 ],
9 "recursive": true
10 },
11 "ip-restriction": {
12 "whitelist": [
13 "198.51.100.0/24",
14 "2001:db8:1200::/48"
15 ],
16 "message": "Source network is not allowed"
17 }
18 }
19}文档解释了 recursive 如何沿转发链查找地址。不要把这些文档专用网段复制到生产环境。请盘点实际代理拓扑，并使用自己的内部范围。如果只有一个可信代理提供单个地址，应选择与该拓扑匹配的最简单配置。
ip-restriction 插件支持 whitelist 和 blacklist。一条路由应选择一个策略方向，避免重叠意图造成歧义。如果客户端可能使用 IPv4 和 IPv6，应同时测试两者。
选择正确的作用范围
应将 IP 策略附加到拥有该需求的最小对象：
- 在网络层保护 APISIX Admin API，使其不与公共数据面共用监听器；
- 将合作方允许列表设置在对应路由或服务，而不是所有公共路由；
- 对敏感操作先认证，再将源网络作为附加条件；
- 在源站边界允许经过批准的边缘服务地址范围，防止直接绕过；
- 将应急封禁与永久架构策略分开管理。
IP 策略不能取代对象级授权。即使请求来自办公网络，也可能由错误用户、受感染设备或不可信进程发出。
安全运维列表变更
使用单一事实来源
存储 CIDR 时，应记录负责人、业务目的、工单或事故、创建时间和到期时间。对于服务商地址范围，应从有文档且可认证的来源获取并验证其结构。不要让生产节点在请求路径上抓取任意 URL。
部署前验证
将每个条目解析为 IP 或 CIDR，拒绝重复项和意外的宽泛网段，并检测允许与拒绝意图重叠。对 0.0.0.0/0、::/0、私有网段和单主机掩码进行显式审查，因为一个字符就可能大幅改变范围。
原子发布
服务商计划轮换地址时，应先增加新范围，再删除旧范围。使用金丝雀路由或网关组验证预期调用方，并保留不受本次策略影响的已知恢复路径。避免在单个节点上手工编辑而造成集群漂移。
记录决策但不泄露数据
记录策略标识、路由、可信派生地址、执行结果和变更版本。IP 地址可能属于个人或安全敏感数据，因此要限制保留时间和访问权限。不要为了说明拒绝原因而记录认证令牌或完整请求体。
让被动封禁到期
每个事故拒绝条目都应设置到期或复查时间。如果某项封禁必须永久保留，应迁移到单独审查且记录理由的正式策略。
需要测试的故障模式
- 客户端向所有可达监听器直接发送伪造的
X-Forwarded-For。 - 请求经过一个、两个以及超出预期数量的代理。
- 第一个可信代理遗漏、追加或重复地址请求头。
- 服务商在轮换中增加新的 IPv4 或 IPv6 范围。
- 合法调用方处于已被封禁地址的共享 NAT 后。
- 一个 APISIX 节点收到过期策略，其他节点收到新版本。
- 应急规则阻断运维访问或健康检查。
- 策略存储或配置分发不可用。
预期结果应包括派生地址、匹配规则、响应状态、日志事件、告警和回滚路径。测试环境应复制真实代理链；本地直接请求无法验证转发地址信任。
管理检查清单
- 所判断的是 TCP 对端地址还是转发值？
- 哪些准确代理范围有权提供该值？
- 客户端能否绕过可信代理路径？
- 是否适合使用允许列表，还是拒绝列表只能作为临时缓解？
- 规则是否只作用于最小范围的路由或服务？
- 是否考虑 IPv4、IPv6、NAT 和共享代理？
- 条目是否有负责人、原因、时间戳和到期时间？
- 更新是否经过解析、审查、金丝雀、原子发布并可回滚？
- 策略阻断运维人员时能否恢复？
- IP 规则是否辅以身份和授权？
总结
可靠的 IP 限制始于可信地址派生，而不是一张 CIDR 列表。先关闭绕过路径并配置准确代理链，再为受控调用群体使用允许列表，为明确的响应动作使用拒绝列表。每次变更都应像代码一样管理，具备范围、负责人、到期、测试和回滚。最后，让 IP 上下文与认证和授权共同发挥其应有作用。
常见问题
X-Forwarded-For 能安全用于 IP 允许列表吗？
只有当第一个可信跳点删除不可信输入并写入该请求头，而且 APISIX 只接受已配置可信代理地址提供的值时才安全。否则客户端可以自行选择表面来源。
公共 API 应使用 IP 允许列表吗？
通常不适合覆盖所有调用方，因为合法地址动态变化且可能共享。但允许列表仍可保护管理路径、固定合作方或源站到边缘的边界。
应多久复查一次拒绝列表？
应在每个条目创建时设置的到期或复查时间进行检查。不能仅仅因为无人删除，就让事故封禁变成永久规则。