SearXNG 429 Error कैसे ठीक करें: Rate Limit का समाधान

SearXNG 429 errors क्यों देता है

एक self-hosted SearXNG instance दो असंबंधित कारणों से 429 errors देता है, और जिस rate limit को आपको ठीक करने की आवश्यकता है, वह आमतौर पर वह नहीं होती जिसे आप मान रहे होते हैं। पहला कारण स्थानीय है: SearXNG के स्वयं के limiter ने यह निर्णय लिया कि अनुरोध एक bot से आया है और status 429 के साथ Too Many Requests उत्तर दिया। दूसरा कारण upstream है: एक search engine ने आपके server के IP address को अस्वीकार कर दिया है, जो आपके users तक 429 के रूप में नहीं, बल्कि परिणाम पृष्ठ पर गायब जानकारी के साथ पहुँचता है।

इन दोनों स्थितियों का समाधान एक नहीं है। Limiter आपका है, इसलिए आप इसे बदल सकते हैं। Upstream blocking Google की तरफ से होती है, इसलिए आपके settings.yml में मौजूद कोई भी चीज़ इसे नहीं हटाएगी। Log आपको लगभग एक मिनट में बता देता है कि आपके साथ क्या हो रहा है, इसलिए वहीं से शुरुआत करें।

यह मार्गदर्शिका अपने VPS पर self-hosted SearXNG instance में वर्णित container install को आधार मानती है। नीचे दिए गए प्रत्येक setting का नाम वर्तमान upstream documentation और source से लिया गया है, जिसे अगस्त 2026 में जाँचा गया है।

सेटिंग बदलने से पहले लॉग पढ़ें

एक लॉग विंडो खुली रखकर समस्या को फिर से उत्पन्न करें।

cd ./searxng/
docker compose logs -f searxng-core

Limiter संदेश searx.limiter नामक लॉगर से आते हैं और उनमें एक IP address का उल्लेख होता है। Blocklist हिट होने पर BLOCK 203.0.113.10: matched BLOCKLIST दिखाई देता है, और allowlist हिट होने पर PASS 203.0.113.10: matched PASSLIST दिखाई देता है। यदि limiter अपने counter store तक नहीं पहुँच पाता है, तो लॉग में The limiter requires Valkey, please consult the documentation दिखाई देता है, जिसका अर्थ है कि कुछ भी count नहीं किया जा रहा है।

प्रत्येक व्यक्तिगत bot check को debug level पर लॉग किया जाता है, इसलिए आप इसे डिफ़ॉल्ट रूप से नहीं देख पाएंगे। एक परीक्षण के लिए settings.yml में debug को चालू करें:

general:
  debug: true

इसके बाद लॉग में client network के बगल में NOT OK (http_accept_language) जैसी लाइनें जुड़ जाती हैं, जिनमें विफल हुए check का नाम होता है। बाद में इसे फिर से बंद कर दें, क्योंकि upstream आपको debug चालू रखकर deployed instance न चलाने की सलाह देता है।

Engine की विफलताएं ऐसी नहीं दिखती हैं। वे IP के बजाय एक engine का नाम बताती हैं, और सबसे आम समस्या timeout है:

HTTP requests timeout (search duration : 3.1 s, timeout: 3.0 s)

इसके लिए एक पेज भी है। यदि enable_metrics को इसके डिफ़ॉल्ट true पर छोड़ दिया जाए, तो आपका instance /stats/errors पर engine errors को रिकॉर्ड करता है, और /preferences यह सूचीबद्ध करता है कि कौन से engines वर्तमान में उत्तर दे रहे हैं। यदि /stats/errors भरा हुआ है और लॉग में कोई searx.limiter लाइनें नहीं हैं, तो समस्या limiter के साथ नहीं है।

किसी भी चीज को डीबग करने से पहले वर्जन को पिन करें

अपस्ट्रीम कंटेनर सेटअप दो फाइलों में होता है।

mkdir -p ./searxng/core-config/
cd ./searxng/

curl -fsSL \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/docker-compose.yml \
    -O https://raw.githubusercontent.com/searxng/searxng/master/container/.env.example

cp -i .env.example .env

Compose फाइल docker.io/searxng/searxng:${SEARXNG_VERSION:-latest} को पुल करती है। एक unset वेरिएबल का मतलब latest होता है, और latest का मतलब है कि अगले docker compose pull पर इंस्टेंस आपके नियंत्रण के बिना बदल जाएगा, इसलिए जो सेटिंग पिछले हफ्ते काम कर रही थी, वह उस कोड के साथ मेल खाना बंद कर सकती है जो उसे पढ़ता है। SearXNG टैग्स में एक तारीख और एक कमिट होता है। अगस्त 2026 तक अपस्ट्रीम .env.example में उदाहरण टैग 2026.3.25-541c6c3cb है, इसलिए .env में एक वास्तविक टैग सेट करें:

SEARXNG_VERSION=2026.3.25-541c6c3cb

पब्लिश किए गए टैग्स की जाँच करें और जिस रिलीज को आपने वास्तव में टेस्ट किया है उसे पिन करें, फिर एक फिक्स्ड टारगेट के खिलाफ डीबग करें। उसी .env फाइल में आपकी सीक्रेट की (secret key) होती है, इसलिए उस डायरेक्टरी को कहीं भी कमिट करने से पहले Docker Compose में env फाइलें और सीक्रेट्स कैसे काम करते हैं पढ़ें।

Limiter को Valkey की आवश्यकता है, अन्यथा यह नहीं चलेगा

Limiter प्रत्येक client के लिए requests की गिनती करता है, और इन counts को worker processes के बीच साझा किया जाना चाहिए। यह store Valkey है, जो Redis का maintained fork है। पुराने SearXNG guides इस setting को redis: कहते हैं। वर्तमान releases valkey: का उपयोग करते हैं, इसलिए किसी पुरानी पोस्ट के बजाय वर्तमान documentation से key का नाम कॉपी करें।

use_default_settings: true
server:
  secret_key: "change-this-value"
  limiter: true
  public_instance: false
valkey:
  url: valkey://searxng-valkey:6379/0

Upstream compose file पहले से ही docker.io/valkey/valkey:9-alpine image पर एक searxng-valkey service चलाती है, इसलिए वह host name compose network के भीतर resolve हो जाता है। यही मान SEARXNG_VALKEY_URL environment variable के साथ सेट किया जा सकता है, और जब SearXNG और Valkey एक ही host साझा करते हैं, तो Unix socket URL (unix:///path/to/socket.sock?db=0) काम करता है।

Store के न होने पर क्या होगा, यह एक अन्य key पर निर्भर करता है। public_instance: false के साथ, limiter Valkey error को log करता है और प्रयास छोड़ देता है, इसलिए instance बिना किसी rate limiting के काम करना जारी रखता है। public_instance: true के साथ, process इसके बजाय sys.exit(1) को call करती है, क्योंकि broken bot protection वाला एक open instance एक दिन के भीतर हर engine से CAPTCHAs (कंप्यूटर और इंसानों के बीच अंतर करने के लिए पूरी तरह से स्वचालित सार्वजनिक ट्यूरिंग परीक्षण) एकत्र कर लेता है। public_instance: true सेट करने के तुरंत बाद जो container loop में restart होता है, वह यही स्थिति है, और प्रत्येक exit से पहले की अंतिम पंक्ति Valkey का नाम बताती है।

limiter वास्तव में क्या गिनता है

[
  {
    "label": "Burst, normal client",
    "max_requests": 15,
    "window": "20 seconds"
  },
  {
    "label": "Burst, flagged client",
    "max_requests": 2,
    "window": "20 seconds"
  },
  {
    "label": "Sustained, normal client",
    "max_requests": 150,
    "window": "10 minutes"
  },
  {
    "label": "Sustained, flagged client",
    "max_requests": 10,
    "window": "10 minutes"
  },
  {
    "label": "Any non-HTML format",
    "max_requests": 4,
    "window": "1 hour"
  },
  {
    "label": "Flagged requests before block",
    "max_requests": 3,
    "window": "30 days"
  }
]

एक सामान्य client को 20 सेकंड की burst window के भीतर 15 requests और 10 मिनट की window के भीतर 150 requests की अनुमति मिलती है। एक बार जब किसी request को संदिग्ध (suspicious) के रूप में चिह्नित किया जाता है, तो वही client प्रति burst window 2 पर आ जाता है। अंतिम पंक्ति सबसे कठोर है: 30 दिनों की window के भीतर 3 चिह्नित requests के बाद, उस address को search करने के बजाय start page पर redirect कर दिया जाता है और log में BLOCK: too many request from ... in SUSPICIOUS_IP_WINDOW (redirect to /) दिखाई देता है।

ये संख्याएँ searx/botdetection/ip_limit.py में constants हैं। ये settings नहीं हैं, और limiter.toml इन्हें expose नहीं करता है, इसलिए इन्हें बदलने का अर्थ है source code को edit करना। /etc/searxng/limiter.toml जो नियंत्रित करता है, वह है clients को group करने के लिए उपयोग किए जाने वाले address prefixes, trusted proxies की सूची, वैकल्पिक link token check, और pass तथा block सूचियाँ।

एक request को header checks द्वारा संदिग्ध के रूप में चिह्नित किया जाता है, और प्रत्येक check का एक नाम होता है जिसे आप debug log में देखेंगे:

• http_accept: Accept header में text/html शामिल नहीं है।
• http_accept_encoding: Accept-Encoding header में न तो gzip है और न ही deflate।
• http_accept_language: कोई Accept-Language header मौजूद नहीं है।
• http_connection: Connection header को close पर set किया गया है।
• http_user_agent: User-Agent गायब है या किसी ज्ञात bot pattern से मेल खाता है।
• http_sec_fetch: Sec-Fetch-Mode या Sec-Fetch-Dest header वह नहीं है जो एक browser भेजता है।

एक browser ये सभी भेजता है। एक साधारण curl call इनमें से लगभग कुछ भी नहीं भेजती है, इसलिए एक hand-written test request अपने पहले प्रयास में ही चिह्नित हो जाती है, जबकि वही search एक browser tab में काम करती है। यही कारण है कि "यह मेरे browser में काम करता है, लेकिन मेरी script को 429 मिलता है" एक रहस्य के बजाय एक सामान्य परिणाम है।

Reverse proxy के पीछे होने पर limiter सभी को एक साथ ब्लॉक कर देता है

यह एक कार्यशील instance को खराब करने का सबसे सामान्य तरीका है। SearXNG क्लाइंट का पता X-Forwarded-For में मौजूद पहले untrusted IP से लेता है, फिर X-Real-IP पर वापस जाता है, और अंत में उस पते पर वापस जाता है जिसने connection खोला था। इन headers पर भरोसा करना है या नहीं, इसका निर्णय limiter.toml में मौजूद trusted_proxies द्वारा लिया जाता है।

यदि आपके proxy का पता उस सूची में नहीं है, तो headers को अनदेखा कर दिया जाता है और हर visitor proxy के पते के साथ आता है। वे सभी एक ही counter साझा करते हैं, इसलिए जब कुल संख्या 10 मिनट में 150 requests को पार कर जाती है, तो पूरी साइट एक साथ ब्लॉक हो जाती है। एक user द्वारा results page को कुछ बार reload करने से सभी का access बंद हो जाता है।

बहुत अधिक भरोसा करना और भी बुरा है। यदि कोई public range सूची में है, तो कोई भी visitor अपना खुद का X-Forwarded-For header भेज सकता है और हर request के लिए एक नई पहचान चुन सकता है, जिससे यह limiter उन सभी के लिए बंद हो जाता है जो ऐसा करना जानते हैं। केवल उसी पते को सूचीबद्ध करें जहाँ से आपका अपना proxy connect होता है। Docker में यह आमतौर पर 172.16.0.0/12 के अंदर एक bridge network होता है, और वह line comment की हुई आती है।

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48

trusted_proxies = [
  '127.0.0.0/8',
  '::1',
  '172.16.0.0/12',
]

Proxy को भी headers भेजने होंगे। Nginx अपने आप इनमें से कोई भी header नहीं जोड़ता है:

location / {
    proxy_pass http://127.0.0.1:8080;

    proxy_set_header Host              $host;
    proxy_set_header Connection        $http_connection;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
}

Caddy और Traefik आपके लिए forwarded headers सेट कर देते हैं, इसलिए उनके साथ आपको केवल काम का trusted_proxies वाला हिस्सा करने की आवश्यकता है। इसके फायदे और नुकसान self-hosted service के लिए reverse proxy चुनना में बताए गए हैं। किसी भी setup को verify करने के लिए, debug को on करें, अपने फोन पर mobile data का उपयोग करके एक बार search करें, और log line में यह पुष्टि करें कि network आपके फोन का पता है, न कि proxy का।

आपका एजेंट प्रति घंटे चार API अनुरोध प्राप्त करता है

JSON आउटपुट डिफ़ॉल्ट रूप से अक्षम होता है, इसलिए एजेंट के लिए इसे जोड़ना आवश्यक है:

search:
  formats:
    - html
    - json

अब चार्ट की पंक्ति को फिर से पढ़ें। HTML के अलावा किसी अन्य प्रारूप के लिए किया गया कोई भी अनुरोध अपनी स्वयं की विंडो में गिना जाता है: प्रति पता, प्रति 1 hour, 4 अनुरोध। एक रिसर्च एजेंट एक ही कार्य में इसे समाप्त कर देता है, और उसके बाद की प्रत्येक कॉल 429 त्रुटि लौटाती है। सीमा बढ़ाना कोई विकल्प नहीं है, क्योंकि यह संख्या सोर्स कोड में निर्धारित है।

इसका सही समाधान लिमिटर को यह बताना है कि यह क्लाइंट कोई अनजान व्यक्ति नहीं है। इसके पते को limiter.toml में पास लिस्ट में जोड़ें:

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip की प्राथमिकता अन्य सभी विधियों से अधिक है, इसलिए एक अलाउलिस्टेड क्लाइंट हेडर जांच को भी छोड़ देता है और एक सामान्य curl कॉल काम करती है। रेंज को जितना संभव हो उतना छोटा रखें, और किसी भी सार्वजनिक रूप से रूट करने योग्य नेटवर्क के बजाय VPN सबनेट या कंटेनर नेटवर्क को प्राथमिकता दें। दूसरा सही समाधान एजेंट को सार्वजनिक पथ से पूरी तरह दूर रखना है: इसे आंतरिक नेटवर्क पर कंटेनर पते पर निर्देशित करें, जहाँ प्रॉक्सी और उसका लिमिटर ट्रैफ़िक को नहीं देख पाते हैं। इसे सेटअप करने की प्रक्रिया AI एजेंट को SearXNG सर्च स्किल देना में शामिल है।

जिस विकल्प से बचना चाहिए, वह है एजेंट को किसी ऐसे सार्वजनिक इंस्टेंस पर निर्देशित करना जिसे कोई और चला रहा हो। यह किसी स्वयंसेवक के IP पते को अपस्ट्रीम इंजन द्वारा ब्लॉक करवाने का सबसे तेज़ तरीका है, और यही कारण है कि JSON प्रारूप डिफ़ॉल्ट रूप से अक्षम रखा गया है।

जब सर्च इंजन आपको ब्लॉक कर दें

[
  {
    "label": "SearxEngineTooManyRequests",
    "suspended_seconds": 3600,
    "roughly": "1 hour"
  },
  {
    "label": "SearxEngineAccessDenied",
    "suspended_seconds": 86400,
    "roughly": "1 day"
  },
  {
    "label": "SearxEngineCaptcha",
    "suspended_seconds": 86400,
    "roughly": "1 day"
  },
  {
    "label": "recaptcha_SearxEngineCaptcha",
    "suspended_seconds": 604800,
    "roughly": "7 days"
  },
  {
    "label": "cf_SearxEngineCaptcha",
    "suspended_seconds": 1296000,
    "roughly": "15 days"
  }
]

जब कोई सर्च इंजन अपने स्वयं के 429 रिस्पॉन्स या CAPTCHA पेज के साथ जवाब देता है, तो SearXNG एक named exception उत्पन्न करता है और कुछ समय के लिए उस इंजन से पूछना बंद कर देता है। 'too-many-requests' वाला जवाब इसे 3600 सेकंड के लिए निलंबित (suspend) कर देता है। एक सामान्य CAPTCHA या 'access-denied' जवाब इसे 1 day के लिए निलंबित कर देता है। Cloudflare के माध्यम से परोसा गया CAPTCHA इसे 15 days के लिए निलंबित करता है, जो सूची में सबसे लंबी डिफ़ॉल्ट अवधि है, क्योंकि इस जवाब का मतलब है कि ब्लॉक 'edge' पर लगा है और दोबारा प्रयास करने से कोई लाभ नहीं होगा।

सामान्य विफलताएं अलग सेटिंग्स का उपयोग करती हैं। टाइमआउट या पार्स एरर इंजन को search.ban_time_on_fail से प्राप्त थोड़े समय के लिए निलंबित कर देते हैं, जो डिफ़ॉल्ट रूप से 5 सेकंड है और search.max_ban_time_on_fail द्वारा अधिकतम 120 सेकंड तक सीमित है। इसलिए, एक धीमा इंजन कुछ ही मिनटों में अपने आप ठीक हो जाता है, जबकि एक ब्लॉक किया गया इंजन घंटों तक अनुपलब्ध रहता है। यह अंतर उस लक्षण की व्याख्या करता है जिसे लोग रैंडम बताते हैं: परिणाम ठीक आते हैं, फिर एक इंजन के परिणाम दोपहर के बाकी समय के लिए गायब हो जाते हैं।

किसी और को दोष देने से पहले टाइमआउट को ठीक करना उचित है। डिफ़ॉल्ट request_timeout 2.0 सेकंड है, जो इंजन के निकटतम 'edge server' से दूर स्थित एक छोटे VPS के लिए बहुत कम है।

outgoing:
  request_timeout: 3.0
  max_request_timeout: 10.0
engines:
  - name: bing
    timeout: 5.0

request_timeout हर इंजन के लिए डिफ़ॉल्ट है, max_request_timeout अधिकतम सीमा है, और एक अकेला इंजन अपना स्वयं का timeout रख सकता है। इन्हें बढ़ाने से पेज की लेटेंसी (latency) बढ़ती है लेकिन विफलताएं कम होती हैं, इसलिए सीधे 10 पर जाने के बजाय आधे सेकंड के अंतराल में बदलाव करें और /stats/errors पर नज़र रखें।

जो इंजन वास्तव में आपके एड्रेस को ब्लॉक कर रहा है, उसे हटा दें। हर सर्च अपने सबसे धीमे इंजन पर निर्भर करती है, इसलिए स्थायी रूप से निलंबित इंजन को बनाए रखने से लेटेंसी बढ़ती है और कुछ भी हासिल नहीं होता।

use_default_settings:
  engines:
    remove:
      - google

बदलावों को docker compose restart searxng-core के साथ लागू करें, फिर कुछ सर्च चलाएं और /stats/errors को रिलोड करें। पांच मिनट के वास्तविक उपयोग के बाद खाली पेज न दिखने का मतलब है कि बदलाव सफल रहा।

Datacentre IP को bot माना जाएगा

आपका VPS address एक hosting range का हिस्सा है, और बड़े search engines ऐसी ranges को automation के रूप में चिन्हित करते हैं। इनमें से कुछ engines ऐसे address से आने वाली हर request पर CAPTCHA दिखाते हैं, चाहे आपके headers कितने भी सही हों या request की गति कितनी भी धीमी क्यों न हो। settings.yml में कोई भी setting इस निर्णय को नहीं बदल सकती।

आप केवल यह बदल सकते हैं कि आप किन engines से query कर रहे हैं और क्या आपका instance सार्वजनिक रूप से सूचीबद्ध है। एक household द्वारा उपयोग किया जाने वाला private instance शायद ही कभी किसी समस्या का सामना करता है। Hosting IP पर चल रहा एक public instance सबसे सख्त engines पर suspension प्राप्त करेगा, और यह software की सामान्य स्थिति है, न कि आपके config में कोई त्रुटि। SearXNG, outgoing.proxies या outgoing.using_tor_proxy का उपयोग करके engine requests को एक proxy के माध्यम से route कर सकता है, जो traffic को एक अलग address पर ले जाता है। Exit nodes और सस्ते proxy pools की score hosting ranges से भी खराब होती है, इसलिए उम्मीद करें कि इस बदलाव से परिणाम और भी खराब हो सकते हैं।

इंस्टेंस पर नज़र रखें ताकि आपको सबसे पहले पता चले

SearXNG अपने पोर्ट पर तब भी जवाब देता है जब सभी इंजन सस्पेंड (suspended) हों, इसलिए एक ऐसा अपटाइम चेक जो केवल स्टेटस कोड देखता है, वह 'green' ही रहता है जबकि इंस्टेंस कोई परिणाम नहीं दे रहा होता। इसके बजाय कंटेंट की जाँच करें: एक वास्तविक सर्च रिक्वेस्ट भेजें और रिस्पॉन्स बॉडी में किसी अपेक्षित शब्द का मिलान करें। Uptime Kuma कीवर्ड मॉनिटरिंग बिना किसी अतिरिक्त टूल के ठीक यही काम करती है। हर वर्जन अपडेट के बाद भी /stats/errors पर नज़र रखें, क्योंकि इंजन अपना HTML बदलते रहते हैं और बिना किसी रेट लिमिट के भी पार्सर (parser) काम करना बंद कर सकता है।

FAQ

SearXNG को reverse proxy के पीछे रखने के बाद यह हर visitor को 429 error क्यों देता है?

ऐसा इसलिए होता है क्योंकि limiter proxy को ही client मानकर गिनती करता है। SearXNG केवल तभी X-Forwarded-For को पढ़ता है जब connecting address को /etc/searxng/limiter.toml में trusted_proxies के अंतर्गत सूचीबद्ध किया गया हो। यदि यह सूचीबद्ध नहीं है, तो सभी visitors एक ही counter साझा करते हैं और वे सभी मिलकर 10 मिनट में 150 requests की सीमा पार कर लेते हैं। उस address को जोड़ें जहाँ से आपका proxy connect होता है, जो Docker में आमतौर पर bridge range 172.16.0.0/12 होती है, और सुनिश्चित करें कि proxy X-Real-IP और X-Forwarded-For भेजता है। ऐसी किसी range को कभी सूचीबद्ध न करें जिसे आप नियंत्रित नहीं करते, क्योंकि एक trusted network किसी भी visitor को वह header सेट करने और हर request के लिए एक नई पहचान चुनने की अनुमति देता है।

SearXNG limiter प्रति घंटे कितनी API requests की अनुमति देता है?

प्रति IP address प्रति घंटे चार। HTML के अलावा किसी अन्य format की मांग करने वाली कोई भी request एक अलग एक घंटे की window में गिनी जाती है, और वह सीमा limiter.toml के बजाय searx/botdetection/ip_limit.py में सेट होती है, इसलिए इसे config से नहीं बढ़ाया जा सकता। एक agent या script इसे एक ही task में पास करता है। client के address को limiter.toml में pass_ip में जोड़ें, या instance तक ऐसे internal network के माध्यम से पहुँचें जहाँ limiter कभी request न देख सके।

मेरे search results बिना किसी 429 error के खाली क्यों आ रहे हैं?

engines आपके server को मना कर रहे हैं, आपके users को नहीं। अपने instance पर /stats/errors खोलें: यह उन सभी engines के नाम बताता है जो विफल रहे और क्यों, और CAPTCHA या access-denied entry का मतलब है कि उस engine ने आपके server के IP address को block कर दिया है। SearXNG फिर उस engine को निलंबित कर देता है, too-many-requests उत्तर के बाद एक घंटे के लिए और CAPTCHA के बाद एक दिन के लिए। कोई भी local setting upstream block को नहीं हटा सकती, इसलिए उन engines को हटा दें जो आपके address को block करते हैं और केवल उन्हीं को रखें जो उत्तर देते हैं।

क्या मुझे private instance पर limiter enable करना चाहिए?

यदि instance तक आपके अलावा कुछ नहीं पहुँचता है, तो limiter: false को रहने दें। यह एक Valkey dependency जोड़ता है और आपकी अपनी scripts को block करता है, और यह ऐसे traffic से सुरक्षा देता है जो आपके पास है ही नहीं। जिस क्षण instance को public address मिले, इसे public_instance: true के साथ enable कर दें। यह जोड़ी जानबूझकर बनाई गई है: public_instance: true के साथ और बिना काम करने वाले Valkey के, process असुरक्षित चलने के बजाय status 1 के साथ exit हो जाती है।