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