Skip to main content
Gateway कई स्वतंत्र दर सीमाएँ लागू करता है। वे अलग-अलग सीमाओं की रक्षा करती हैं, अलग-अलग पहचानों के आधार पर कुंजीबद्ध होती हैं और अलग-अलग त्रुटि प्रारूपों के साथ विफल होती हैं। यह पृष्ठ उन सभी का संदर्भ है। एक नज़र में:

​
प्रमाणीकरण प्रयास (प्रमाणीकरण-पूर्व)

किसी भी अनुरोध के प्रबंधन से पहले, विफल प्रमाणीकरण प्रयासों को प्रत्येक क्लाइंट IP के अनुसार सीमित किया जाता है। यह इंटरनेट पर उपलब्ध Gateways के लिए ब्रूट-फोर्स सुरक्षा है।
  • केवल गलत क्रेडेंशियल गिने जाते हैं। अनुपस्थित क्रेडेंशियल (ऐसा क्लाइंट जिसने कभी टोकन नहीं भेजा) और सफल प्रमाणीकरण बजट का उपयोग नहीं करते; सफल प्रमाणीकरण उस IP का काउंटर रीसेट कर देता है।
  • डिफ़ॉल्ट: 60 सेकंड में 10 विफलताएँ, फिर उस IP के लिए 5 मिनट का लॉकआउट।
  • लूपबैक (127.0.0.1 / ::1) को डिफ़ॉल्ट रूप से छूट प्राप्त है, ताकि स्थानीय CLI सत्रों को लॉक आउट न किया जा सके।
  • काउंटर प्रत्येक क्रेडेंशियल वर्ग के अनुसार सीमित होते हैं, इसलिए किसी एक सतह पर अनुरोधों की बाढ़ दूसरे को विस्थापित नहीं करती। दायरों में साझा Gateway टोकन/पासवर्ड, डिवाइस टोकन, Node युग्मन, युग्मित Node का पुनः अनुमोदन, डिवाइस बूटस्ट्रैप टोकन और watchOS चुनौती जारी करना शामिल हैं।
लॉकआउट के दौरान, कनेक्शन प्रयास इस त्रुटि के साथ विफल होते हैं:
लॉकआउट के दौरान अन्य IP (लूपबैक सहित) से किए गए प्रयास अप्रभावित रहते हैं। इसे openclaw.json में gateway.auth.rateLimit के अंतर्गत समायोजित करें:
Gateway लॉग में बार-बार आने वाली AUTH_RATE_LIMITED प्रविष्टियों का अर्थ है कि कोई क्रेडेंशियल का अनुमान लगा रहा है; एक्सपोज़र रनबुक देखें।

​
ब्राउज़र-मूल कनेक्शन

ब्राउज़र 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 को टॉगल करने से कॉन्फ़िगरेशन लेखन का बजट खर्च नहीं होता। सीमा पार होने पर, अनुरोध पुनः प्रयास योग्य त्रुटि के साथ विफल होता है:
क्लाइंट को retryAfterMs का पालन करना चाहिए। सीमा निश्चित है (कॉन्फ़िगर करने योग्य नहीं); बकेट अपने आप समाप्त हो जाते हैं और Gateway के रखरखाव द्वारा हटा दिए जाते हैं।

​
ACP सत्र निर्माण

ACP अनुवादक प्रत्येक अनुवादक इंस्टेंस के लिए 10 सेकंड की अवधि में अधिकतम 120 नए सत्र बनाने देता है। इसे पार करने पर अनुरोध ऐसी त्रुटि के साथ विफल होता है, जिसके संदेश में प्रतीक्षा समय होता है (इस पथ पर कोई संरचित retryAfterMs फ़ील्ड नहीं है):
यह लूप में सत्र बनाने वाले अनियंत्रित क्लाइंट को सीमित करता है; सामान्य IDE और एजेंट उपयोग इससे बहुत नीचे रहता है।

​
पुनः आरंभ कूलडाउन

Gateway पुनः आरंभ अनुरोधों को एकत्रित किया जाता है, फिर पुनः आरंभ चक्रों के बीच 30 सेकंड का कूलडाउन लागू किया जाता है। कूलडाउन के दौरान अनुरोध किया गया पुनः आरंभ अस्वीकार होने के बजाय उसकी समाप्ति के बाद निर्धारित किया जाता है। यह ऊपर दिए गए कंट्रोल-प्लेन सीमक से अलग है: gateway.restart.request कंट्रोल-प्लेन बजट के एक स्लॉट का उपयोग करता है और उससे होने वाला पुनः आरंभ कूलडाउन का पालन करता है।

​
परिचालन संबंधी टिप्पणियाँ

  • सभी सीमक इन-मेमोरी और प्रति-प्रक्रिया हैं तथा एकाधिक Gateways स्थिति साझा नहीं करते। Gateway प्रक्रिया को बदलने से Gateway के स्वामित्व वाले काउंटर (प्रमाणीकरण लॉकआउट, Webhook थ्रॉटल, कंट्रोल-प्लेन बकेट) साफ़ हो जाते हैं। पुनः आरंभ कूलडाउन जानबूझकर इन-प्रोसेस पुनः आरंभ चक्रों में बना रहता है — यह इन्हीं को सीमित करता है — और केवल प्रक्रिया के साथ रीसेट होता है। ACP सत्र सीमा उसके अनुवादक इंस्टेंस की होती है और उस इंस्टेंस को दोबारा बनाने पर रीसेट होती है, Gateway के पुनः आरंभ पर नहीं।
  • बकेट मैप सीमित होते हैं (सख्त प्रविष्टि सीमाएँ और आवधिक सफ़ाई), इसलिए विशिष्ट कुंजियों की बाढ़ मेमोरी को असीमित रूप से नहीं बढ़ा सकती।
  • जब कोई क्लाइंट रिवर्स प्रॉक्सी के पीछे होता है, तो प्रभावी IP समाधान किया गया क्लाइंट IP होता है; प्रॉक्सी हेडर के इसे प्रभावित करने से पहले उनके सत्यापन का तरीका जानने के लिए विश्वसनीय प्रॉक्सी प्रमाणीकरण देखें।
  • पुनः प्रयास संकेत सतह के अनुसार बदलता है: Gateway RPC सीमक retryable: true और retryAfterMs लौटाते हैं, Webhook इनग्रेस Retry-After हेडर के साथ HTTP 429 का उपयोग करता है और ACP प्रतीक्षा अवधि को त्रुटि संदेश में समाहित करता है। प्रत्येक स्थिति में तुरंत पुनः प्रयास करने के बजाय बताई गई अवधि तक प्रतीक्षा करें।