.NET6使用AspNetCoreRateLimit时X-Real-IP变更致限流重置如何防范限流攻击？

架构老林

2026-8-26

问题原因

你当前配置直接将X-Real-IP作为客户端IP提取来源，AspNetCoreRateLimit默认会直接信任该请求头携带的值作为限流计数的唯一标识，没有对请求来源做可信校验。攻击者只要篡改该请求头的值，库就会将请求判定为来自全新的客户端，原有计数直接失效，自然可以绕开限流规则。

修复配置步骤

第一步：前置转发头中间件，仅信任可信代理传递的IP头
如果你服务前面部署了Nginx、CDN等反向代理，必须在Program.cs中最先注册转发头中间件，明确指定可信代理的IP段，拒绝所有非可信来源传递的X-Real-IP、X-Forwarded-For头：

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedRealIp;
    // 清空默认信任的网段，按需添加自己的代理IP/网段
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
    // 示例：添加本地代理、内网代理网段、CDN回源IP段
    options.KnownProxies.Add(IPAddress.Parse("127.0.0.1"));
    options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("10.0.0.0"), 8));
});
// 该中间件必须放在所有其他中间件（包括限流中间件）之前注册
app.UseForwardedHeaders();

如果你的服务直接暴露在公网、没有前置任何反向代理，直接删除配置中的RealIpHeader项即可，库会默认读取TCP连接的真实对端IPHttpContext.Connection.RemoteIpAddress作为限流依据，客户端自行传递的X-Real-IP不会被采信。

第二步：调整限流基础配置，封堵绕过空间
修改IpRateLimitOptions的以下配置项：

将StackBlockedRequests从false改为true，被限流拦截的请求也会计入计数，避免攻击者靠触发拦截重置计数窗口
在IpWhitelist中添加所有可信反向代理、CDN的回源IP段，只有来自这些IP的请求，库才会解析RealIpHeader中的用户真实IP，其余请求直接使用连接IP作为限流标识
若服务不对外返回限流相关头可以保留DisableRateLimitHeaders: true，否则建议设为false方便合法客户端适配限流规则
修正后的配置参考：

"IpRateLimitOptions": {
  "EnableEndpointRateLimiting": false,
  "DisableRateLimitHeaders": true,
  "StackBlockedRequests": true,
  "RealIpHeader": "X-Real-IP",
  "ClientIdHeader": "X-ClientId",
  // 替换为你实际的可信代理IP/IP段
  "IpWhitelist": [ "127.0.0.1", "::1", "10.0.0.0/8" ],
  "EndpointWhitelist": [ "get:/js/*", "get:/lib/*", "get:/fonts/*", "get:/favicon.ico" ],
  "HttpStatusCode": 429,
  "QuotaExceededMessage": "API calls quota exceeded",
  "GeneralRules": [
    {
      "Endpoint": "*",
      "Period": "1s",
      "Limit": 5
    },
    {
      "Endpoint": "*",
      "Period": "15m",
      "Limit": 100
    },
    {
      "Endpoint": "*",
      "Period": "12h",
      "Limit": 1000
    },
    {
      "Endpoint": "*",
      "Period": "7d",
      "Limit": 10000
    }
  ]
}

第三步：多层限流兜底
对于需要登录认证的接口，不要仅依赖IP作为限流标识，同时开启客户端限流，将用户的唯一标识（如JWT中的用户ID）作为ClientId提取依据，IP+用户ID双层限流，即使攻击者篡改IP头也无法绕过针对账号的限流规则。
第四步：源站访问控制
如果服务前置了CDN或高防代理，必须配置源站防火墙规则，仅允许CDN/高防的回源IP段访问源站端口，避免攻击者直接连接源站伪造请求头绕开代理校验。

内容的提问来源于stack exchange，提问作者raul