SearXNG میں 429 Error اور Rate Limit کیسے ٹھیک کریں

SearXNG کی طرف سے 429 errors واپس آنے کی وجوہات

Self-hosted SearXNG instance دو غیر متعلقہ وجوہات کی بنا پر 429 errors واپس کرتا ہے، اور عموماً جس rate limit کو درست کرنا ہوتا ہے وہ وہ نہیں ہوتی جس کا آپ اندازہ لگاتے ہیں۔ پہلی وجہ مقامی ہے: SearXNG کے اپنے limiter نے فیصلہ کیا کہ request کسی bot کی طرف سے آئی ہے، اور اس نے Too Many Requests کو status 429 کے ساتھ جواب دیا۔ دوسری وجہ upstream ہے: کسی search engine نے آپ کے server کے IP address کو مسترد کر دیا، جس کا نتیجہ آپ کے users کو 429 کے بجائے ایسی results page کی صورت میں نظر آتا ہے جس میں کچھ چیزیں موجود نہیں ہوتیں۔

ان دونوں صورتوں کا حل ایک جیسا نہیں ہے۔ Limiter آپ کا اپنا ہے، اس لیے آپ اسے تبدیل کر سکتے ہیں۔ Upstream blocking Google کی طرف سے ہوتی ہے، اس لیے آپ کے settings.yml میں کوئی تبدیلی اسے ختم نہیں کرے گی۔ Log تقریباً ایک منٹ میں بتا دیتا ہے کہ آپ کو کون سا مسئلہ درپیش ہے، اس لیے وہیں سے شروع کریں۔

یہ guide اپنے VPS پر self-hosted SearXNG instance میں بیان کردہ container install کو فرض کرتی ہے۔ ذیل میں settings کے تمام نام موجودہ upstream documentation اور source سے لیے گئے ہیں، جن کی August 2026 میں جانچ کی گئی تھی۔

ترتیب تبدیل کرنے سے پہلے لاگ پڑھیں

لاگ window کھول کر مسئلہ دوبارہ پیدا کریں۔

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

Limiter کے پیغامات searx.limiter نامی logger سے آتے ہیں اور ان میں IP address درج ہوتا ہے۔ Blocklist hit اس طرح دکھائی دیتا ہے: BLOCK 203.0.113.10: matched BLOCKLIST، جبکہ allowlist hit اس طرح دکھائی دیتا ہے: PASS 203.0.113.10: matched PASSLIST۔ اگر limiter اپنے counter store تک نہیں پہنچ سکتا تو لاگ میں The limiter requires Valkey, please consult the documentation درج ہوتا ہے۔ اس کا مطلب ہے کہ کسی چیز کی counting نہیں ہو رہی۔

ہر bot check کو debug level پر log کیا جاتا ہے، اس لیے یہ پیغامات default طور پر نظر نہیں آئیں گے۔ settings.yml میں ایک test کے لیے debug فعال کریں:

general:
  debug: true

اس کے بعد لاگ client network کے ساتھ NOT OK (http_accept_language) جیسی lines شامل کرتا ہے اور ناکام ہونے والے check کا نام بتاتا ہے۔ بعد میں debug دوبارہ غیر فعال کریں، کیونکہ upstream ہدایت دیتا ہے کہ deployed instance کو debug فعال رکھ کر نہ چلائیں۔

Engine failures اس سے بالکل مختلف دکھائی دیتے ہیں۔ ان میں IP کے بجائے engine کا نام ہوتا ہے، اور سب سے عام failure timeout ہے:

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

اس کے لیے ایک page بھی موجود ہے۔ enable_metrics کو اس کی default value true پر رہنے دینے سے آپ کا instance engine errors کو /stats/errors پر record کرتا ہے، جبکہ /preferences میں موجودہ طور پر جواب دینے والے engines کی فہرست ہوتی ہے۔ اگر /stats/errors بھرا ہوا ہے اور لاگ میں searx.limiter lines موجود نہیں، تو مسئلہ limiter میں نہیں ہے۔

debug شروع کرنے سے پہلے version کو pin کریں

upstream container setup دو files پر مشتمل ہے۔

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 file docker.io/searxng/searxng:${SEARXNG_VERSION:-latest} حاصل کرتی ہے۔ unset variable کا مطلب latest ہے، اور latest کا مطلب ہے کہ اگلے docker compose pull پر instance آپ کے علم کے بغیر تبدیل ہو جائے گا۔ اس لیے جو setting گزشتہ ہفتے کام کر رہی تھی، وہ اس code کے ساتھ مطابقت ختم کر سکتی ہے جو اسے پڑھتا ہے۔ SearXNG tags میں date اور commit شامل ہوتے ہیں۔ August 2026 تک upstream .env.example میں مثال کے طور پر tag 2026.3.25-541c6c3cb ہے، اس لیے .env میں حقیقی version مقرر کریں:

SEARXNG_VERSION=2026.3.25-541c6c3cb

published tags چیک کریں اور وہ release pin کریں جسے آپ نے حقیقت میں test کیا ہے۔ اس کے بعد fixed target کے خلاف debug کریں۔ اسی .env file میں آپ کی secret key بھی موجود ہے۔ اس لیے اس directory کو کہیں commit کرنے سے پہلے Docker Compose میں env files اور secrets کے کام کرنے کا طریقہ پڑھیں۔

Limiter کو Valkey درکار ہے، ورنہ یہ نہیں چلتا

Limiter ہر client کی requests شمار کرتا ہے، اور یہ شمار worker processes کے درمیان مشترک ہونے چاہییں۔ یہ store Valkey ہے، جو Redis کا maintained fork ہے۔ SearXNG کی پرانی guides اس setting کو redis: کہتی ہیں۔ موجودہ releases valkey: پڑھتی ہیں، اس لیے key name کسی پرانی post کے بجائے موجودہ documentation سے copy کریں۔

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 پہلے ہی searxng-valkey service کو docker.io/valkey/valkey:9-alpine image پر چلاتی ہے، اس لیے یہ host name compose network کے اندر resolve ہو جاتا ہے۔ یہی value SEARXNG_VALKEY_URL environment variable کے ذریعے بھی set کی جا سکتی ہے۔ جب 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 کے requests فراہم کرتا رہتا ہے۔ public_instance: true کے ساتھ process اس کے بجائے sys.exit(1) کو call کرتا ہے، کیونکہ bot protection کے بغیر کھلا instance ایک دن کے اندر ہر engine سے CAPTCHAs (completely automated public turing test to tell computers and humans apart) جمع کرتا ہے۔ public_instance: true set کرنے کے فوراً بعد اگر کوئی container loop میں restart ہو تو یہی وجہ ہے، اور ہر exit سے پہلے آخری line میں 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 کو مشتبہ قرار دیا جائے تو اسی client کی حد ہر burst window میں 2 requests رہ جاتی ہے۔ آخری row سب سے سخت ہے: 30 دن کی window میں 3 flagged requests کے بعد اس address کو search کرنے کے بجائے start page پر redirect کر دیا جاتا ہے، اور log میں BLOCK: too many request from ... in SUSPICIOUS_IP_WINDOW (redirect to /) لکھا جاتا ہے۔

یہ numbers searx/botdetection/ip_limit.py میں constants کے طور پر موجود ہیں۔ یہ settings نہیں ہیں، اور limiter.toml انہیں expose نہیں کرتا؛ اس لیے انہیں تبدیل کرنے کے لیے source میں ترمیم کرنا ضروری ہے۔ /etc/searxng/limiter.toml جن چیزوں کو control کرتا ہے وہ clients کو group کرنے کے لیے استعمال ہونے والے address prefixes، trusted proxies کی list، optional link token check، اور pass اور block lists ہیں۔

Header checks کی بنیاد پر کسی request کو مشتبہ قرار دیا جاتا ہے، اور ہر 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 کی value close ہے۔
• http_user_agent: User-Agent غائب ہے یا معروف bot pattern سے match کرتا ہے۔
• http_sec_fetch: Sec-Fetch-Mode یا Sec-Fetch-Dest header کی value وہ نہیں ہے جو browser بھیجتا ہے۔

Browser یہ تمام headers بھیجتا ہے۔ ایک سادہ curl call ان میں سے تقریباً کوئی header نہیں بھیجتا، اس لیے ہاتھ سے لکھی گئی test request پہلی کوشش ہی میں flag ہو جاتی ہے، جبکہ یہی search browser tab میں کامیابی سے کام کرتی ہے۔ اسی وجہ سے "میرے browser میں کام کرتا ہے، لیکن میری script کو 429 ملتا ہے" کوئی راز نہیں بلکہ معمول کا نتیجہ ہے۔

ریورس پراکسی کے پیچھے limiter سب کو ایک ساتھ روک دیتا ہے

یہ کسی درست چلنے والے instance کو خراب کرنے کا سب سے عام طریقہ ہے۔ SearXNG کلائنٹ کا address X-Forwarded-For میں موجود پہلے untrusted IP سے لیتا ہے، پھر X-Real-IP پر fallback کرتا ہے، اور اس کے بعد اس address پر fallback کرتا ہے جس نے connection کھولا تھا۔ ان headers پر اعتماد کیا بھی جائے یا نہیں، اس کا فیصلہ limiter.toml میں موجود trusted_proxies کرتا ہے۔

اگر آپ کے proxy کا address اس فہرست میں شامل نہ ہو تو headers نظرانداز کر دیے جاتے ہیں، اور ہر visitor proxy کا address لے کر آتا ہے۔ اس کے بعد سب ایک ہی counter شیئر کرتے ہیں، لہٰذا 10 منٹ میں کل درخواستوں کی تعداد 150 سے بڑھتے ہی پوری site ایک ساتھ block ہو جاتی ہے۔ کوئی ایک user results page کو چند بار reload کرے تو سب کے لیے سروس بند ہو جاتی ہے۔

ضرورت سے زیادہ اعتماد اس سے بھی زیادہ خطرناک ہے۔ اگر کوئی public range فہرست میں شامل ہو تو ہر visitor اپنا X-Forwarded-For header بھیج کر ہر request کے لیے نئی identity منتخب کر سکتا ہے۔ اس طرح جو شخص یہ طریقہ جانتا ہو، وہ limiter کو غیر فعال کر سکتا ہے۔ صرف وہی address شامل کریں جس سے آپ کا اپنا proxy connect کرتا ہے۔ Docker میں یہ عموماً 172.16.0.0/12 کے اندر موجود bridge network ہوتا ہے، اور وہ line default طور پر comment out ہوتی ہے۔

[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 خود set کر دیتے ہیں، اس لیے ان کے ساتھ آپ کو صرف trusted_proxies والا کام کرنا ہوتا ہے۔ اس کے فوائد اور نقصانات self-hosted service کے لیے reverse proxy کا انتخاب میں بیان کیے گئے ہیں۔ دونوں setups کی تصدیق کے لیے debug کو فعال کریں، mobile data پر اپنے phone سے ایک بار search کریں، اور log line میں موجود network کی تصدیق کریں کہ وہ proxy کے بجائے آپ کے phone کا address ہے۔

آپ کے agent کو فی گھنٹہ چار API requests ملتی ہیں

JSON output پہلے سے disabled ہوتی ہے، اس لیے agent کو اسے شامل کرنا ہوگا:

search:
  formats:
    - html
    - json

اب chart row دوبارہ پڑھیں۔ HTML کے علاوہ کسی format کی request اپنے الگ window میں شمار ہوتی ہے: ہر address کے لیے فی 1 hour 4 requests۔ ایک research agent ایک task میں یہ حد پوری کر دیتا ہے، اور اس کے بعد ہر call 429 واپس کرتی ہے۔ limit بڑھانا ممکن نہیں، کیونکہ یہ number source میں موجود ہے۔

درست حل یہ ہے کہ limiter کو بتایا جائے کہ یہ client نامعلوم نہیں ہے۔ اس کا address limiter.toml میں pass list میں شامل کریں:

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip کو ہر دوسرے method پر ترجیح حاصل ہے، اس لیے allowlisted client header checks بھی bypass کرتا ہے اور سادہ curl call کام کرتی ہے۔ range کو حتیٰ ممکن کم رکھیں، اور کسی بھی routable range کے بجائے VPN subnet یا container network کو ترجیح دیں۔ دوسرا درست حل یہ ہے کہ agent کو public path سے مکمل طور پر دور رکھا جائے: اسے internal network پر موجود container address کی طرف point کریں، جہاں proxy اور اس کا limiter traffic دیکھ ہی نہیں سکتے۔ اس کی configuration AI agent کو SearXNG search skill دینا میں بیان کی گئی ہے۔

جس option سے گریز کرنا چاہیے، وہ کسی دوسرے شخص کے چلائے ہوئے public instance کی طرف agent کو point کرنا ہے۔ upstream engines کے ذریعے کسی volunteer کا IP address block ہونے کا یہ تیز ترین طریقہ ہے، اور اسی وجہ سے JSON format پہلے سے disabled ہوتا ہے۔

جب انجن آپ کو بلاک کرنے لگیں

[
  {
    "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 ایک نام زدہ exception اٹھاتا ہے اور کچھ دیر کے لیے اس انجن کو مزید درخواستیں بھیجنا روک دیتا ہے۔ too-many-requests جواب انجن کو 3600 سیکنڈ کے لیے معطل کر دیتا ہے۔ عام CAPTCHA یا access-denied جواب اسے 1 day کے لیے معطل کرتا ہے۔ Cloudflare کے ذریعے پیش کیا گیا CAPTCHA اسے 15 days کے لیے معطل کرتا ہے۔ یہ فہرست میں موجود طویل ترین default مدت ہے، کیونکہ اس جواب کا مطلب ہے کہ block edge پر موجود ہے اور دوبارہ کوشش کرنے سے فائدہ نہیں ہوگا۔

عام failures کے لیے مختلف settings استعمال ہوتی ہیں۔ timeout یا parse error انجن کو search.ban_time_on_fail سے حاصل کردہ مختصر مدت کے لیے معطل کرتا ہے۔ search.ban_time_on_fail کی default قدر 5 seconds ہے، اور search.max_ban_time_on_fail اسے 120 seconds تک محدود رکھتا ہے۔ اس لیے سست انجن چند منٹ میں خود بحال ہو جاتا ہے، جبکہ blocked انجن کئی گھنٹوں کے لیے دستیاب نہیں رہتا۔ یہی فرق اس علامت کی وضاحت کرتا ہے جسے لوگ random کہتے ہیں: نتائج درست آتے ہیں، پھر ایک انجن کے نتائج باقی دوپہر کے لیے غائب ہو جاتے ہیں۔

کسی کو موردِ الزام ٹھہرانے سے پہلے timeouts درست کرنا بہتر ہے۔ default request_timeout قدر 2.0 seconds ہے، جو کسی ایسے چھوٹے VPS کے لیے کم ہے جو انجن کے قریب ترین edge server سے بہت دور ہو۔

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

request_timeout ہر انجن کے لیے default ہے، max_request_timeout زیادہ سے زیادہ حد ہے، اور ایک انجن اپنی timeout قدر رکھ سکتا ہے۔ ان settings کو بڑھانے سے page latency کے بدلے failures کم ہوتے ہیں۔ اس لیے قدر کو آدھے seconds کے increments میں بڑھائیں اور /stats/errors کو monitor کریں، بجائے اس کے کہ فوراً 10 مقرر کر دیں۔

اگر کوئی انجن واقعی آپ کے address کو block کر رہا ہے تو اسے ہٹا دیں۔ ہر search اپنے سب سے سست انجن کا انتظار کرتی ہے، اس لیے مستقل طور پر suspended انجن latency بڑھاتا ہے اور کوئی نتیجہ واپس نہیں کرتا۔

use_default_settings:
  engines:
    remove:
      - google

docker compose restart searxng-core کے ذریعے changes نافذ کریں، پھر چند searches چلائیں اور /stats/errors کو reload کریں۔ حقیقی استعمال کے 5 minutes بعد اگر page خالی ہو تو اس کا مطلب ہے کہ change کامیاب رہا۔

ڈیٹا سینٹر کے IP کو bot سمجھا جائے گا

آپ کے VPS کا address hosting range سے تعلق رکھتا ہے، اور بڑے search engines ایسی ranges کو automation کے طور پر score کرتے ہیں۔ ان میں سے کچھ engines ایسے address سے آنے والی ہر request کے لیے CAPTCHA دکھاتے ہیں، چاہے headers کتنے ہی درست ہوں یا requests کتنی ہی سست رفتاری سے بھیجی جائیں۔ settings.yml کی کوئی setting اس تشخیص کو تبدیل نہیں کرتی۔

آپ یہ تبدیل کر سکتے ہیں کہ کن engines سے درخواست کی جائے اور آپ کا instance public طور پر listed ہے یا نہیں۔ ایک household کے زیرِ استعمال private instance عموماً کسی رکاوٹ کا باعث نہیں بنتا۔ hosting IP پر موجود public instance کو سخت ترین engines پر suspensions کا سامنا ہوگا۔ یہ عموماً آپ کی config کی خرابی نہیں بلکہ software کی معمول کی حالت ہے۔ SearXNG، outgoing.proxies یا outgoing.using_tor_proxy کے ذریعے engine requests کو proxy سے route کر سکتا ہے، جس سے traffic کسی مختلف address سے جائے گا۔ Exit nodes اور سستے proxy pools کو hosting ranges کے مقابلے میں زیادہ منفی score دیا جاتا ہے، اس لیے توقع رکھیں کہ اس تبدیلی سے results مزید خراب ہو سکتے ہیں۔

مثالے کی نگرانی کریں تاکہ مسئلہ سب سے پہلے آپ کے علم میں آئے

SearXNG اس وقت بھی اپنے port پر جواب دیتا ہے جب تمام engines معطل ہوں۔ اس لیے صرف status code کی نگرانی کرنے والا uptime check سبز رہتا ہے، جبکہ instance کوئی نتیجہ واپس نہیں کرتا۔ اس کے بجائے content چیک کریں: حقیقی search request بھیجیں اور response body میں متوقع لفظ تلاش کریں۔ Uptime Kuma میں keyword monitoring اضافی tooling کے بغیر یہی کام کرتا ہے۔ ہر version bump کے بعد بھی /stats/errors کی نگرانی کریں، کیونکہ engines کا HTML تبدیل ہو سکتا ہے اور parser ٹوٹ سکتا ہے، جبکہ اس میں rate limit کا کوئی تعلق نہیں ہوتا۔

FAQ

SearXNG کو reverse proxy کے پیچھے رکھنے کے بعد ہر visitor کو 429 کیوں ملتا ہے؟

کیونکہ limiter proxy کو client سمجھ کر requests شمار کر رہا ہے۔ SearXNG صرف X-Forwarded-For پڑھتا ہے جب connecting address، /etc/searxng/limiter.toml میں trusted_proxies کی فہرست میں شامل ہو۔ اگر یہ address شامل نہ ہو تو تمام visitors ایک ہی counter share کرتے ہیں، اور وہ سب مل کر 10 minutes میں 150 requests کی حد پار کر دیتے ہیں۔ وہ address شامل کریں جس سے proxy connect کرتا ہے۔ Docker میں یہ عموماً bridge range 172.16.0.0/12 ہوتی ہے۔ یہ بھی یقینی بنائیں کہ proxy X-Real-IP اور X-Forwarded-For بھیجتا ہے۔ ایسی range کبھی شامل نہ کریں جس پر آپ کا control نہ ہو، کیونکہ trusted network کے ذریعے کوئی بھی visitor یہ header set کر کے ہر request کے لیے نئی identity منتخب کر سکتا ہے۔

SearXNG کا limiter فی hour کتنی API requests کی اجازت دیتا ہے؟

ہر IP address کے لیے فی hour 4 requests۔ HTML کے علاوہ کسی format کی درخواست الگ one hour 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 کے بغیر خالی کیوں آتے ہیں؟

مسئلہ آپ کے users کا نہیں، بلکہ engines آپ کے server کو reject کر رہے ہیں۔ اپنی instance پر /stats/errors کھولیں۔ یہ ہر failed engine اور failure کی وجہ دکھاتا ہے۔ CAPTCHA یا access-denied entry کا مطلب ہے کہ اس engine نے آپ کے server کا IP address block کر دیا ہے۔ Too-many-requests جواب کے بعد SearXNG engine کو ایک hour کے لیے، اور CAPTCHA کے بعد ایک day کے لیے suspend کر دیتا ہے۔ کوئی local setting upstream block ختم نہیں کر سکتی۔ اس لیے وہ engines ہٹا دیں جو آپ کے address کو block کرتے ہیں، اور صرف وہ engines رکھیں جو جواب دیتے ہیں۔

کیا private instance پر limiter enable کرنا چاہیے؟

اگر instance تک آپ کے علاوہ کوئی نہیں پہنچتا تو limiter: false رہنے دیں۔ اس سے Valkey dependency شامل ہوتی ہے اور آپ کے اپنے scripts block ہو جاتے ہیں، جبکہ یہ ایسے traffic سے تحفظ فراہم کرتا ہے جو آپ کے پاس موجود ہی نہیں۔ Instance کو public address ملتے ہی اسے public_instance: true کے ساتھ enable کریں۔ یہ جوڑا دانستہ طور پر اس طرح رکھا گیا ہے: public_instance: true اور working Valkey نہ ہونے کی صورت میں process status 1 کے ساتھ exit ہو جاتا ہے، بجائے اس کے کہ بغیر تحفظ کے چلتا رہے۔