--- 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-27T18:17:02Z" 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 प्रतीक्षा अवधि को त्रुटि संदेश में समाहित करता है। प्रत्येक स्थिति में तुरंत पुनः प्रयास करने के बजाय बताई गई अवधि तक प्रतीक्षा करें।