Node.js API में रेट लिमिटिंग कैसे लागू करें: संपूर्ण 2026 गाइड

दर सीमित करना आपके एपीआई को दुरुपयोग से बचाता है, आकस्मिक अधिभार को रोकता है, और ग्राहकों के बीच उचित उपयोग सुनिश्चित करता है। इसके बिना, एक भी क्लाइंट (या हमलावर) आपके सर्वर पर दबाव डाल सकता है। यह मार्गदर्शिका Node.js में सरल से उत्पादन-ग्रेड तक मजबूत दर सीमित लागू करती है।

दर सीमा क्यों?

• दुरुपयोग रोकें: Stop brute-force attacks and scraping
• निष्पक्षता सुनिश्चित करें: No single client monopolizes resources
• नियंत्रण लागत: महँगे परिचालनों को सीमित करें (एआई कॉल, डीबी क्वेरीज़)
• स्थिरता की रक्षा करें: आकस्मिक या दुर्भावनापूर्ण अधिभार को रोकें

मुख्य एल्गोरिदम

सरल: व्यक्त-दर-सीमा

npm install express-rate-limit

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,   // 15 minutes
  max: 100,                    // 100 requests per window per IP
  standardHeaders: true,       // return RateLimit-* headers
  legacyHeaders: false,
  message: { error: 'Too many requests, please try again later.' },
});

// Apply globally
app.use(limiter);

// Or stricter limits on specific routes
const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,   // only 5 login attempts per 15 min
});
app.post('/login', authLimiter, loginHandler);

Production: Redis-Backed Rate Limiting

इन-मेमोरी सीमाएँ एकाधिक सर्वर इंस्टेंसेस पर काम नहीं करतीं। Redis shares limits across all instances:

npm install rate-limit-redis ioredis

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');
const Redis = require('ioredis');

const redis = new Redis(process.env.REDIS_URL);

const limiter = rateLimit({
  store: new RedisStore({
    sendCommand: (...args) => redis.call(...args),
  }),
  windowMs: 15 * 60 * 1000,
  max: 100,
});

app.use(limiter);
// Now all server instances share the same rate-limit counters

रेडिस के साथ कस्टम टोकन बकेट

async function tokenBucket(key, maxTokens, refillRate) {
  const now = Date.now();
  const bucket = await redis.hgetall(`bucket:${key}`);

  let tokens = parseFloat(bucket.tokens ?? maxTokens);
  let lastRefill = parseInt(bucket.lastRefill ?? now);

  // Refill tokens based on elapsed time
  const elapsed = (now - lastRefill) / 1000;
  tokens = Math.min(maxTokens, tokens + elapsed * refillRate);

  if (tokens < 1) {
    return { allowed: false, retryAfter: (1 - tokens) / refillRate };
  }

  tokens -= 1;  // consume one token
  await redis.hset(`bucket:${key}`, { tokens, lastRefill: now });
  await redis.expire(`bucket:${key}`, 3600);

  return { allowed: true, remaining: Math.floor(tokens) };
}

// Middleware
async function rateLimitMiddleware(req, res, next) {
  const result = await tokenBucket(req.ip, 10, 1);  // 10 tokens, 1/sec refill
  if (!result.allowed) {
    res.setHeader('Retry-After', Math.ceil(result.retryAfter));
    return res.status(429).json({ error: 'Rate limit exceeded' });
  }
  res.setHeader('X-RateLimit-Remaining', result.remaining);
  next();
}

Per-User (Not Just Per-IP) Limiting

// Rate limit by authenticated user ID instead of IP
const userLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 60,
  keyGenerator: (req) => {
    // Use user ID if authenticated, fall back to IP
    return req.user?.id || req.ip;
  },
  store: new RedisStore({ sendCommand: (...args) => redis.call(...args) }),
});

// Tiered limits based on plan
function getLimitForUser(req) {
  const plan = req.user?.plan || 'free';
  return { free: 100, pro: 1000, enterprise: 10000 }[plan];
}

उचित प्रतिक्रिया शीर्षलेख सेट करना

// Standard rate-limit headers help clients back off gracefully
res.setHeader('RateLimit-Limit', limit);
res.setHeader('RateLimit-Remaining', remaining);
res.setHeader('RateLimit-Reset', resetTimestamp);

// On limit exceeded, always include Retry-After
res.status(429)
   .setHeader('Retry-After', secondsUntilReset)
   .json({ error: 'Too many requests' });

सर्वोत्तम अभ्यास

• Use Redis for multi-instance apps — इन-मेमोरी सीमाएं सर्वरों में सिंक नहीं होतीं
• Stricter limits on sensitive endpoints — लॉगिन, पासवर्ड रीसेट, और भुगतान समापन बिंदुओं के लिए सख्त सीमा की आवश्यकता है
• स्पष्ट हेडर लौटाएँ — रेटलिमिट-* और रिट्री-आफ्टर से ग्राहकों को अच्छा व्यवहार करने में मदद मिलती है
• प्रमाणित होने पर उपयोगकर्ता द्वारा दर सीमा – केवल आईपी (साझा आईपी, प्रॉक्सी) से अधिक निष्पक्ष
• स्तरीय सीमाओं पर विचार करें — different limits for free vs paid users
• Combine with other defenses — दर सीमित करना एक परत है, पूर्ण सुरक्षा समाधान नहीं

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: मुझे किस एल्गोरिदम का उपयोग करना चाहिए?
ए: लचीलेपन के लिए टोकन बकेट (नियंत्रित विस्फोट की अनुमति देता है), चिकनाई के लिए स्लाइडिंग विंडो, सरलता के लिए निश्चित विंडो। अधिकांश एपीआई के लिए, एक्सप्रेस-रेट-लिमिट का डिफ़ॉल्ट (फिक्स्ड/स्लाइडिंग विंडो) ठीक है। टोकन बकेट एपीआई के लिए उपयुक्त है जहां कभी-कभार विस्फोट स्वीकार्य हैं।

प्रश्न: क्या मुझे आईपी या उपयोगकर्ता द्वारा सीमा निर्धारित करनी चाहिए?
ए: प्रमाणित होने पर उपयोगकर्ता आईडी द्वारा (निष्पक्ष, साझा आईपी को संभालता है), अनाम अनुरोधों के लिए आईपी पर वापस आना। आईपी-केवल सीमित करने से साझा NAT या कॉर्पोरेट प्रॉक्सी के पीछे उपयोगकर्ताओं पर गलत प्रभाव पड़ सकता है।

प्रश्न: मेरी दर सीमा अप्रत्याशित रूप से रीसेट क्यों हो जाती है?
A: With in-memory limiting across multiple instances, each server has its own counter — a client hitting different instances sees inconsistent limits. सभी उदाहरणों में स्थिति साझा करने के लिए रेडिस का उपयोग करें।

प्रश्न: मुझे कौन सा स्टेटस कोड लौटाना चाहिए?
A: 429 बहुत सारे अनुरोध,Retry-Afterके साथ हेडर क्लाइंट को बताता है कि कितनी देर तक इंतजार करना है। यह मानक है और अच्छे व्यवहार वाले ग्राहक इसका सम्मान करते हैं।

प्रश्न: क्या दर सीमित करने से DDoS हमले रुक सकते हैं?
उत्तर: यह एप्लिकेशन-लेयर के दुरुपयोग के विरुद्ध मदद करता है लेकिन संपूर्ण DDoS सुरक्षा नहीं है। बड़े पैमाने पर हमलों के लिए, एप्लिकेशन दर सीमित करने के अलावा नेटवर्क किनारे पर CDN/WAF (क्लाउडफ्लेयर, AWS शील्ड) का उपयोग करें।

निष्कर्ष

आपके Node.js API को दुरुपयोग और अधिभार से बचाने के लिए दर सीमित करना आवश्यक है।से प्रारंभ करें एक्सप्रेस-दर-सीमा साधारण मामलों के लिए, औरपर जाएँ रेडिस-समर्थित सीमित मल्टी-इंस्टेंस प्रोडक्शन ऐप्स के लिए यह सर्वरों में सिंक को सीमित करता है। संवेदनशील समापन बिंदुओं (लॉगिन, भुगतान) पर कड़ी सीमाएं लागू करें, प्रमाणित होने पर उपयोगकर्ता द्वारा दर सीमा लागू करें, और हमेशा स्पष्ट रिटर्न देंRateLimit-* औरRetry-After हेडर ताकि ग्राहक शालीनता से पीछे हट जाएं। गहराई से रक्षा के लिए इसे CDN/WAF के साथ संयोजित करें।