最直接方式是自定义IPFilterAttribute继承ActionFilterAttribute，在OnActionExecuting中校验RemoteIpAddress，配合UseForwardedHeaders处理代理场景，并用IOptionsMonitor支持CIDR与热更新。
WebAPI 中用 IPFilterAttribute 做白名单最直接
ASP.NET Core WebAPI 没内置 IP 白名单机制，但用自定义 ActionFilterAttribute 是最轻量、最可控的方式。它在 Action 执行前拦截请求，能快速拒绝非授权 IP，不污染业务逻辑。
常见错误是把校验写在 Controller 里——每次都要重复写、漏写、或误放在 OnActionExecuted（太晚，资源已消耗）。
- 继承
ActionFilterAttribute，重写OnActionExecuting - 从
HttpContext.Connection.RemoteIpAddress取真实客户端 IP（注意代理场景，后文会提） - 白名单列表建议用
HashSet<ipaddress></ipaddress>，查找 O(1)，别用 List.Contains - 记得处理 IPv4 映射 IPv6 地址（如
::ffff:192.168.1.100），否则本地测试常失败
如何正确获取客户端真实 IP（Nginx / Cloudflare 下不翻车）
直接读 RemoteIpAddress 在有反向代理时大概率拿到的是 Nginx 或 LB 的内网 IP，白名单立刻失效。
必须依赖 X-Forwarded-For 或 X-Real-IP，但不能无条件信任——这些头可被客户端伪造，必须配合 ForwardedHeadersOptions 做可信源验证。
- Startup 中调用
UseForwardedHeaders()，并配置KnownProxies或KnownNetworks（比如 Nginx 所在内网段10.0.0.0/8） - 启用后，
HttpContext.Connection.RemoteIpAddress会被自动替换为可信的原始 IP - Cloudflare 用户需额外加
KnownProxies列表（官方提供 IP 段，如173.245.48.0/20），否则仍取到 Cloudflare 节点 IP - 开发环境（Kestrel 直连）无需代理配置，但代码要兼容——别硬编码判断环境
IPFilterAttribute 支持 CIDR 和配置热更新
纯 IP 列表太僵硬，生产环境基本都要支持网段（如 192.168.1.0/24），且白名单常需动态调整，重启服务不可接受。
硬编码数组或 JSON 配置文件 + IOptionsMonitor 是平衡简洁与灵活性的做法。
- 用
IPAddress.TryParse和IPNetwork.Parse（推荐 NuGet 包IPNetwork2）解析 CIDR - 白名单数据存在
IOptionsMonitor<ipfilteroptions></ipfilteroptions>中，配置文件变更自动生效 - 避免在
OnActionExecuting里每次解析 CIDR 字符串——提前在 Options 初始化时转成IPNetwork实例集合 - 注意线程安全：
IPNetwork实例本身是只读的，可安全共享
黑名单和白名单共存时的优先级陷阱
很多人想“白名单放行，其余再查黑名单”，结果写出 if (inWhitelist) return; if (inBlacklist) reject; ——这逻辑错在：白名单用户也可能在黑名单里，该以谁为准？
安全策略必须明确优先级。行业惯例是「黑名单优先」（deny-by-default + exception），但业务要求可能是「白名单严格优先」（allow-only-this + deny-all）。
- 务必在文档或配置项里显式声明策略，例如
Policy = "WhitelistFirst" - 代码中不要隐含顺序，用明确分支：
if (isInBlacklist) { reject; return; }→if (!isInWhitelist) { reject; return; } - 日志必须记录决策依据：比如 “
1.2.3.4rejected: not in whitelist, and not in blacklist” - 测试用例至少覆盖三种情况：仅白名单、仅黑名单、两者都含同一 IP
IP 过滤真正难的不是写几行代码，而是搞清流量路径上每个环节对 IP 头的修改，以及策略语义是否被所有人理解一致。配错一个 KnownProxy，整个白名单就形同虚设。
