--- read_when: - क्लाइंट को `rate limit exceeded for `, `AUTH_RATE_LIMITED`, या लॉकआउट त्रुटियाँ दिखाई देती हैं - आप `gateway.auth.rateLimit` को ट्यून करना चाहते हैं - आप सार्वजनिक रूप से उपलब्ध Gateway पर ब्रूट-फोर्स सुरक्षा के बारे में विचार कर रहे हैं - आपको यह जानना आवश्यक है कि Gateway की किन सतहों पर थ्रॉटलिंग लागू है और उसकी सीमाएँ क्या हैं summary: 'हर Gateway दर सीमा के लिए संदर्भ: प्रमाणीकरण-पूर्व लॉकआउट, ब्राउज़र और Webhook थ्रॉटलिंग, कंट्रोल-प्लेन लेखन सुरक्षा सीमा, ACP सत्र सीमाएँ और पुनः आरंभ कूलडाउन' title: दर सीमित करना x-i18n: generated_at: "2026-07-19T08:51:26Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 7aa37b65347610bedfb1db8f661e7ba75ef3cdfed0ba73c4ce53d80acace1e48 source_path: gateway/security/rate-limiting.md workflow: 16 --- Gateway कई स्वतंत्र दर सीमाएँ लागू करता है। वे अलग-अलग सीमाओं की रक्षा करती हैं, अलग-अलग पहचानों के आधार पर कुंजीबद्ध होती हैं, और अलग-अलग त्रुटि स्वरूपों के साथ विफल होती हैं। यह पृष्ठ उन सभी के लिए संदर्भ है। एक नज़र में: | सतह | सीमा (डिफ़ॉल्ट) | इसके आधार पर कुंजीबद्ध | कॉन्फ़िगर करने योग्य | | ----------------------------------- | -------------------------------- | -------------------------------- | ------------------------ | | विफल प्रमाणीकरण (टोकन/पासवर्ड/डिवाइस) | 60s में 10 विफलताएँ, 5 min लॉकआउट | IP + क्रेडेंशियल दायरा | `gateway.auth.rateLimit` | | ब्राउज़र-मूल WS प्रमाणीकरण विफलताएँ | समान, लूपबैक को **छूट नहीं** | IP, या लूपबैक से पृष्ठ का मूल | `gateway.auth.rateLimit` | | Webhook (`/hooks`) प्रमाणीकरण विफलताएँ | 60s में 20 विफलताएँ, 60s लॉकआउट | IP | नहीं | | नियंत्रण-प्लेन लेखन RPC | प्रति विधि 60s में 30 अनुरोध | विधि + डिवाइस + IP | नहीं | | ACP सत्र निर्माण | 10s में 120 सत्र | अनुवादक इंस्टेंस | आंतरिक | | Gateway पुनरारंभ चक्र | पुनरारंभों के बीच 30s कूलडाउन | प्रक्रिया | नहीं | ## प्रमाणीकरण प्रयास (पूर्व-प्रमाणीकरण) किसी भी अनुरोध के प्रबंधन से पहले, विफल प्रमाणीकरण प्रयासों को प्रति क्लाइंट IP सीमित किया जाता है। यह सार्वजनिक रूप से उपलब्ध Gateways के लिए ब्रूट-फोर्स सुरक्षा है। - केवल _गलत_ क्रेडेंशियल गिने जाते हैं। अनुपलब्ध क्रेडेंशियल (ऐसा क्लाइंट जिसने कभी टोकन नहीं भेजा) और सफल प्रमाणीकरण बजट का उपयोग नहीं करते; एक सफल प्रमाणीकरण उस IP के काउंटर को रीसेट कर देता है। - डिफ़ॉल्ट: प्रति 60 सेकंड में 10 विफलताएँ, फिर उस IP के लिए 5 मिनट का लॉकआउट। - लूपबैक (`127.0.0.1` / `::1`) को डिफ़ॉल्ट रूप से छूट है, ताकि स्थानीय CLI सत्र लॉक न हो सकें। - काउंटर प्रत्येक क्रेडेंशियल वर्ग के दायरे में होते हैं, इसलिए एक सतह पर अनुरोधों की बाढ़ दूसरी सतह को विस्थापित नहीं करती। दायरों में साझा Gateway टोकन/पासवर्ड, डिवाइस टोकन, Node पेयरिंग, पेयर किए गए Node का पुनः-अनुमोदन, डिवाइस बूटस्ट्रैप टोकन और watchOS चुनौती जारी करना शामिल हैं। लॉकआउट के दौरान, कनेक्शन प्रयास इसके साथ विफल होते हैं: ```json { "code": "INVALID_REQUEST", "message": "unauthorized: too many failed authentication attempts (retry later)", "retryable": true, "retryAfterMs": 297000, "details": { "code": "AUTH_RATE_LIMITED", "authReason": "rate_limited", "recommendedNextStep": "wait_then_retry" } } ``` लॉकआउट के दौरान अन्य IP (लूपबैक सहित) से आने वाले प्रयास अप्रभावित रहते हैं। इसे `openclaw.json` में `gateway.auth.rateLimit` के अंतर्गत समायोजित करें: ```json { "gateway": { "auth": { "rateLimit": { "maxAttempts": 10, "windowMs": 60000, "lockoutMs": 300000, "exemptLoopback": true } } } } ``` Gateway लॉग में बार-बार आने वाली `AUTH_RATE_LIMITED` प्रविष्टियों का अर्थ है कि कोई क्रेडेंशियल का अनुमान लगा रहा है; [एक्सपोज़र रनबुक](/hi/gateway/security/exposure-runbook) देखें। ### ब्राउज़र-मूल कनेक्शन ब्राउज़र `Origin` हेडर ले जाने वाले WebSocket कनेक्शन समान सीमाओं का उपयोग करते हैं, लेकिन लूपबैक छूट **हमेशा बंद** रहती है — स्थानीय ब्राउज़र में कोई दुर्भावनापूर्ण पृष्ठ फिर भी एक अविश्वसनीय क्लाइंट है, इसलिए उस पथ पर localhost को कोई विशेष छूट नहीं मिलती। जब ऐसा कनेक्शन किसी लूपबैक पते _से_ आता है, तो उसकी विफलताएँ साझा लूपबैक IP के बजाय सामान्यीकृत पृष्ठ मूल (उदाहरण के लिए `browser-origin:https://evil.example`) के आधार पर कुंजीबद्ध होती हैं, ताकि प्रत्येक मूल को अपना बकेट मिले; गैर-लूपबैक पतों से आने पर कुंजी क्लाइंट IP ही रहती है। इसे कॉन्फ़िगर नहीं किया जा सकता। ### Webhooks HTTP `/hooks` प्रवेश का अपना विफलता सीमक है: प्रति क्लाइंट IP प्रति 60 सेकंड में 20 विफल प्रमाणीकरण, फिर 60 सेकंड का लॉकआउट। लूपबैक को छूट नहीं है। सफल हुक प्रमाणीकरण काउंटर को रीसेट कर देता है। सीमित किए गए अनुरोधों को `Retry-After` हेडर (सेकंड) के साथ सामान्य HTTP `429 Too Many Requests` प्राप्त होता है। सीमाएँ निश्चित हैं; यदि कोई वैध एकीकरण इसकी सीमा पार करता है, तो अधिक आक्रामक पुनः प्रयास करने के बजाय उसके क्रेडेंशियल ठीक करें। ## नियंत्रण-प्लेन लेखन (प्रमाणीकरण-पश्चात सुरक्षा सीमा) लेखन-पक्ष के एडमिन RPC (`config.apply`, `config.patch`, `plugins.install`, `plugins.setEnabled`, `plugins.uninstall`, `update.run`, `worktrees.*`, `gateway.restart.request`, ...) पर प्राधिकरण के **बाद** अतिरिक्त दर सीमा लागू होती है: प्रति `deviceId+clientIp`, प्रति विधि, प्रति 60 सेकंड में 30 अनुरोध। यह कोई सुरक्षा सीमा नहीं है — कॉलर के पास पहले से `operator.admin` है — यह एक सुरक्षा उपाय है जो महँगे ऑपरेशनों पर लगातार प्रहार करने वाले अनियंत्रित क्लाइंट या एजेंट लूप को सीमित करता है। इंटरैक्टिव उपयोग कभी इसकी सीमा तक नहीं पहुँचता; प्रत्येक विधि का अपना बकेट होता है, इसलिए किसी Plugin को टॉगल करने से कॉन्फ़िगरेशन लेखन का बजट खर्च नहीं होता। सीमा पार होने पर, अनुरोध पुनः प्रयास योग्य त्रुटि के साथ विफल होता है: ```json { "code": "UNAVAILABLE", "message": "rate limit exceeded for config.patch; retry after 35s", "retryable": true, "retryAfterMs": 34539, "details": { "method": "config.patch", "limit": "30 per 60s" } } ``` क्लाइंट को `retryAfterMs` का पालन करना चाहिए। सीमा निश्चित है (कॉन्फ़िगर करने योग्य नहीं); बकेट अपने आप समाप्त हो जाते हैं और Gateway रखरखाव द्वारा हटाए जाते हैं। ## ACP सत्र निर्माण ACP अनुवादक प्रत्येक अनुवादक इंस्टेंस के लिए 10 सेकंड की विंडो में सत्र निर्माण को 120 नए सत्रों तक सीमित करता है। इससे अधिक होने पर अनुरोध ऐसी त्रुटि के साथ विफल होता है जिसके संदेश में प्रतीक्षा समय होता है (इस पथ पर कोई संरचित `retryAfterMs` फ़ील्ड नहीं है): ``` के लिए ACP सत्र निर्माण दर सीमा पार हो गई; s के बाद पुनः प्रयास करें। ``` यह लूप में सत्र बनाने वाले अनियंत्रित क्लाइंट को सीमित करता है; सामान्य IDE और एजेंट उपयोग इससे बहुत नीचे रहता है। ## पुनरारंभ कूलडाउन Gateway पुनरारंभ अनुरोधों को एकत्रित किया जाता है, फिर पुनरारंभ चक्रों के बीच 30 सेकंड का कूलडाउन लागू किया जाता है। कूलडाउन के दौरान अनुरोधित पुनरारंभ को अस्वीकार करने के बजाय उसकी अवधि समाप्त होने के बाद शेड्यूल किया जाता है। यह ऊपर दिए गए नियंत्रण-प्लेन सीमक से अलग है: `gateway.restart.request` नियंत्रण-प्लेन बजट का एक स्लॉट उपयोग करता है _और_ परिणामी पुनरारंभ कूलडाउन का पालन करता है। ## परिचालन संबंधी टिप्पणियाँ - सभी सीमक इन-मेमोरी और प्रति-प्रक्रिया होते हैं, और एकाधिक Gateways स्थिति साझा नहीं करते। Gateway प्रक्रिया बदलने से Gateway के स्वामित्व वाले काउंटर (प्रमाणीकरण लॉकआउट, webhook थ्रॉटल, नियंत्रण-प्लेन बकेट) साफ़ हो जाते हैं। पुनरारंभ कूलडाउन जानबूझकर प्रक्रिया के भीतर होने वाले पुनरारंभ चक्रों में बना रहता है — यह उन्हीं को सीमित करता है — और केवल प्रक्रिया के साथ रीसेट होता है। ACP सत्र सीमा उसके अनुवादक इंस्टेंस की होती है और उस इंस्टेंस के पुनः बनाए जाने पर रीसेट होती है, Gateway पुनरारंभ पर नहीं। - बकेट मैप सीमित होते हैं (कठोर प्रविष्टि सीमाएँ और आवधिक सफ़ाई), इसलिए अद्वितीय-कुंजी अनुरोधों की बाढ़ मेमोरी को असीमित रूप से नहीं बढ़ा सकती। - जब कोई क्लाइंट रिवर्स प्रॉक्सी के पीछे होता है, तो प्रभावी IP समाधान किया गया क्लाइंट IP होता है; प्रॉक्सी हेडर के इसे प्रभावित करने से पहले उनके सत्यापन की प्रक्रिया के लिए [विश्वसनीय प्रॉक्सी प्रमाणीकरण](/hi/gateway/trusted-proxy-auth) देखें। - पुनः प्रयास संकेत सतह के अनुसार अलग होता है: Gateway RPC सीमक `retryable: true` के साथ `retryAfterMs` लौटाते हैं, webhook प्रवेश `Retry-After` हेडर के साथ HTTP 429 का उपयोग करता है, और ACP प्रतीक्षा अवधि को त्रुटि संदेश में समाहित करता है। हर स्थिति में, तुरंत पुनः प्रयास करने के बजाय बताई गई अवधि तक प्रतीक्षा करें।