SearXNG-এ 429 Error ও Rate Limit কীভাবে ঠিক করবেন

SearXNG কেন 429 error দেয়

Self-hosted SearXNG instance দুটি সম্পর্কহীন কারণে 429 error দিতে পারে। যে rate limit ঠিক করতে হবে, সেটি সাধারণত আপনি যে limit ভাবছেন সেটি নয়। প্রথম কারণটি local: SearXNG-এর নিজস্ব limiter কোনো request-কে bot থেকে এসেছে বলে শনাক্ত করে এবং status 429 সহ Too Many Requests উত্তর দেয়। দ্বিতীয় কারণটি upstream: কোনো search engine আপনার server-এর IP address প্রত্যাখ্যান করে। এর ফলে আপনার users এমন একটি results page পান, যেখানে কিছু ফল অনুপস্থিত থাকে; 429 নয়।

এই দুটি পরিস্থিতির সমাধান এক নয়। Limiter আপনার নিয়ন্ত্রণে, তাই এটি পরিবর্তন করতে পারেন। Upstream blocking Google-এর দিকে ঘটে, তাই আপনার settings.yml-এর কোনো পরিবর্তন এটি দূর করবে না। প্রায় এক মিনিটের মধ্যে log দেখে বোঝা যায় আপনি কোন পরিস্থিতিতে পড়েছেন। তাই সেখান থেকেই শুরু করুন।

এই নির্দেশিকায় নিজের VPS-এ self-hosted SearXNG instance-এ বর্ণিত container installation ধরে নেওয়া হয়েছে। নিচের প্রতিটি setting name বর্তমান upstream documentation ও source থেকে নেওয়া এবং August 2026-এ যাচাই করা হয়েছে।

পরিবর্তন করার আগে লগ পড়ুন

লগ উইন্ডো খোলা রেখে সমস্যাটি পুনরুৎপাদন করুন।

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 লেখা হয়। এর অর্থ, কোনো কিছুরই count করা হচ্ছে না।

প্রতিটি bot check debug level-এ লগ করা হয়। তাই default অবস্থায় এগুলো দেখা যাবে না। settings.yml-এ একটি পরীক্ষার জন্য debug চালু করুন:

general:
  debug: true

এরপর লগে client network-এর পাশে NOT OK (http_accept_language)-এর মতো গঠনের line যোগ হয়। সেখানে কোন check ব্যর্থ হয়েছে তা উল্লেখ থাকে। পরে debug আবার বন্ধ করুন, কারণ deployed instance-এ debug চালু রেখে চালানো যাবে না—upstream-এ এ বিষয়ে নির্দেশনা রয়েছে।

Engine-এর ব্যর্থতার চেহারা সম্পূর্ণ আলাদা। এতে IP-এর বদলে engine-এর নাম থাকে, এবং সবচেয়ে সাধারণ কারণ হলো timeout:

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

এটির জন্য একটি page-ও রয়েছে। enable_metrics-কে default true অবস্থায় রাখলে আপনার instance engine error /stats/errors level-এ record করে, আর /preferences বর্তমানে কোন engine উত্তর দিচ্ছে তা তালিকাভুক্ত করে। /stats/errors পূর্ণ থাকলেও লগে কোনো searx.limiter line না থাকলে সমস্যাটি limiter-এ নয়।

ডিবাগ করার আগে সংস্করণ নির্দিষ্ট করুন

Upstream container setup দুটি ফাইলে থাকে।

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} pull করে। Unset variable-এর অর্থ latest, আর latest-এর অর্থ পরবর্তী docker compose pull-এ instance আপনার নিয়ন্ত্রণের বাইরে পরিবর্তিত হবে। ফলে গত সপ্তাহে কাজ করা setting সেই code-এর সঙ্গে আর মেলেনি, যে code এটি পড়ে। SearXNG tag-এ একটি date এবং একটি commit থাকে। August 2026 অনুযায়ী upstream .env.example-এ উদাহরণ হিসেবে থাকা tag হলো 2026.3.25-541c6c3cb। তাই .env-এ একটি নির্দিষ্ট tag সেট করুন:

SEARXNG_VERSION=2026.3.25-541c6c3cb

প্রকাশিত tag-গুলো পরীক্ষা করে আপনি যে release সত্যিই পরীক্ষা করেছেন, সেটি pin করুন। এরপর একটি নির্দিষ্ট target ধরে debug করুন। একই .env file-এ আপনার secret key থাকে। তাই ওই directory কোথাও commit করার আগে Docker Compose-এ env file এবং secret কীভাবে কাজ করে তা পড়ুন।

লিমিটার চালাতে Valkey প্রয়োজন; এটি ছাড়া লিমিটার চলে না

লিমিটার প্রতিটি client-এর অনুরোধ গণনা করে। এই গণনাগুলো worker process-গুলোর মধ্যে ভাগ করে ব্যবহার করতে হয়। এই data store হলো Valkey, যা Redis-এর রক্ষণাবেক্ষণাধীন fork। পুরোনো SearXNG guide-গুলোতে এই setting-কে redis: বলা হয়। বর্তমান release-গুলো valkey: পড়ে। তাই পুরোনো post থেকে নয়, বর্তমান 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 আগে থেকেই আছে। তাই compose network-এর ভেতরে ওই host name resolve হয়। একই value SEARXNG_VALKEY_URL environment variable দিয়েও সেট করা যায়। SearXNG এবং Valkey একই host-এ থাকলে Unix socket URL (unix:///path/to/socket.sock?db=0) কাজ করে।

store অনুপস্থিত থাকলে কী হবে, তা আরও একটি key-এর ওপর নির্ভর করে। public_instance: false থাকলে লিমিটার Valkey error log করে এবং কাজ বন্ধ করে দেয়। ফলে instance কোনো rate limiting ছাড়াই service চালিয়ে যায়। public_instance: true থাকলে process পরিবর্তে sys.exit(1) call করে। কারণ bot protection নষ্ট থাকা একটি উন্মুক্ত instance এক দিনের মধ্যে প্রতিটি engine থেকে CAPTCHA (সম্পূর্ণ স্বয়ংক্রিয়ভাবে computer ও মানুষের পার্থক্য নির্ণয়ের public turing test) সংগ্রহ করে। public_instance: true সেট করার পর কোনো container যদি সঙ্গে সঙ্গে বারবার restart হতে থাকে, সেটিই এর লক্ষণ। প্রতিবার exit করার আগে log-এর শেষ line-এ Valkey-এর নাম থাকবে।

লিমিটার আসলে কী গণনা করে

[
  {
    "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 second-এর burst window-এর মধ্যে 15টি request এবং 10 minute-এর window-এর মধ্যে 150টি request করতে পারে। কোনো request সন্দেহজনক হিসেবে চিহ্নিত হলে একই client প্রতি burst window-এ সর্বোচ্চ 2টি request করতে পারে। শেষের row-টি সবচেয়ে কঠোর: 30 day-এর window-এর মধ্যে 3টি flagged request হওয়ার পরে ওই address-কে search করার পরিবর্তে start page-এ redirect করা হয়, এবং log-এ BLOCK: too many request from ... in SUSPICIOUS_IP_WINDOW (redirect to /) লেখা হয়।

এই সংখ্যাগুলো searx/botdetection/ip_limit.py-এর constant। এগুলো setting নয়, এবং limiter.toml এগুলো প্রকাশ করে না। তাই এগুলো পরিবর্তন করতে source সম্পাদনা করতে হয়। /etc/searxng/limiter.toml যে বিষয়গুলো নিয়ন্ত্রণ করে, সেগুলো হলো client group করার জন্য ব্যবহৃত address prefix, trusted proxy-এর তালিকা, ঐচ্ছিক link token check, এবং pass ও block list।

Header check-এর ভিত্তিতে কোনো 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-এর মান close।
• http_user_agent: User-Agent অনুপস্থিত, অথবা এটি পরিচিত bot pattern-এর সঙ্গে মিলে যায়।
• http_sec_fetch: Sec-Fetch-Mode বা Sec-Fetch-Dest header-এর মান browser পাঠানো মানের মতো নয়।

একটি browser এগুলো সব পাঠায়। একটি সাধারণ curl call এগুলোর প্রায় কোনোটিই পাঠায় না। তাই হাতে লেখা test request প্রথম চেষ্টাতেই flagged হয়, অথচ একই search browser tab-এ কাজ করে। এজন্য “আমার browser-এ কাজ করে, কিন্তু আমার script 429 পায়”—এটাই স্বাভাবিক ফল; এটি কোনো রহস্য নয়।

Reverse proxy-এর পেছনে limiter সবাইকে একসঙ্গে block করছে

একটি সচল instance নষ্ট করার সবচেয়ে সাধারণ উপায় এটি। SearXNG প্রথমে X-Forwarded-For-এর প্রথম অবিশ্বস্ত IP থেকে client address নেয়, না পেলে X-Real-IP ব্যবহার করে, এবং সেখানেও না পেলে connection খোলা address ব্যবহার করে। এই header-গুলো আদৌ বিশ্বাস করা হবে কি না, তা limiter.toml-এ থাকা trusted_proxies নির্ধারণ করে।

আপনার proxy-এর address ওই তালিকায় না থাকলে header-গুলো উপেক্ষা করা হয় এবং প্রতিটি visitor proxy-এর address নিয়ে আসে। ফলে সবাই একই counter ভাগ করে নেয়। মোট অনুরোধ 10 মিনিটে 150 ছাড়ালে পুরো site একসঙ্গে block হয়ে যায়। একজন user results page কয়েকবার reload করলেই অন্য সবাইও access হারায়।

অতিরিক্ত trust করা আরও বিপজ্জনক। কোনো public range তালিকাভুক্ত থাকলে, যে visitor বিষয়টি জানে সে নিজের X-Forwarded-For header পাঠিয়ে প্রতিটি request-এর জন্য নতুন identity বেছে নিতে পারে। এতে limiter অকার্যকর হয়ে যায়। আপনার proxy যে address থেকে সংযোগ করে, শুধু সেই address তালিকাভুক্ত করুন। Docker-এ এটি সাধারণত 172.16.0.0/12-এর ভেতরের একটি bridge network, এবং ওই line-টি commented out অবস্থায় থাকে।

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48

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

Proxy-কে header-গুলো পাঠাতেও হবে। Nginx নিজে থেকে এগুলোর কোনোটি যোগ করে না:

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 header সেট করে। তাই এগুলোর ক্ষেত্রে আপনাকে শুধু trusted_proxies অংশটি সম্পন্ন করতে হবে। এই trade-off-গুলো self-hosted service-এর জন্য reverse proxy নির্বাচন-এ ব্যাখ্যা করা হয়েছে। যেকোনো setup যাচাই করতে debug চালু করুন, mobile data ব্যবহার করে ফোন থেকে একবার search করুন, এবং log line-এ থাকা network-টি proxy-এর address নয়, আপনার ফোনের address কি না নিশ্চিত করুন।

আপনার agent প্রতি ঘণ্টায় চারটি API request পায়

JSON output ডিফল্টভাবে disabled থাকে, তাই agent-এ এটি যোগ করতে হবে:

search:
  formats:
    - html
    - json

এখন আবার chart-এর row দেখুন। HTML ছাড়া অন্য format চাওয়া প্রতিটি request তার নিজস্ব window-এ গণনা হয়: প্রতি address-এ প্রতি 1 hour-এ 4 request। একটি research agent এক task-এই এই সীমা শেষ করে ফেলে, এবং এরপরের প্রতিটি call 429 ফিরিয়ে দেয়। Limit বাড়ানো যাবে না, কারণ সংখ্যাটি source code-এ নির্ধারিত।

পরিষ্কার সমাধান হলো limiter-কে জানানো যে এই client অপরিচিত নয়। limiter.toml-এর pass list-এ এর address যোগ করুন:

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip-এর priority অন্য সব method-এর চেয়ে বেশি। তাই allowlisted client header check-ও এড়িয়ে যায় এবং bare curl call কাজ করে। Range যতটা সম্ভব ছোট রাখুন। Routable যেকোনো network-এর বদলে VPN subnet বা container network ব্যবহার করুন। আরেকটি পরিষ্কার সমাধান হলো agent-কে পুরোপুরি public path-এর বাইরে রাখা। Internal network-এ container address ব্যবহার করে agent-কে proxy-তে পাঠান। সেখানে proxy এবং তার limiter এই traffic দেখতে পায় না। এই configuration AI agent-কে SearXNG search skill দেওয়া অংশে ব্যাখ্যা করা হয়েছে।

যে পদ্ধতিটি এড়াতে হবে, সেটি হলো অন্য কারও পরিচালিত public instance-এর দিকে agent-কে পাঠানো। এতে upstream engine-গুলোতে কোনো volunteer-এর IP address block হওয়ার ঝুঁকি সবচেয়ে বেশি। JSON format ডিফল্টভাবে disabled থাকার এটিই মূল কারণ।

যখন engine-গুলো পরিবর্তে আপনাকে বাধা দেয়

[
  {
    "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"
  }
]

কোনো engine নিজস্ব 429 উত্তর বা CAPTCHA page পাঠালে SearXNG একটি নামযুক্ত exception উত্থাপন করে এবং কিছু সময়ের জন্য ওই engine-কে আর অনুরোধ পাঠায় না। too-many-requests উত্তর এলে এটি 3600 সেকেন্ডের জন্য suspended হয়। সাধারণ CAPTCHA বা access-denied উত্তর এলে এটি 1 day সময়ের জন্য suspended হয়। Cloudflare-এর মাধ্যমে CAPTCHA পাঠানো হলে এটি 15 days সময়ের জন্য suspended হয়। তালিকায় এটিই দীর্ঘতম default, কারণ এই উত্তরটি বোঝায় যে block-টি edge-এ রয়েছে এবং আবার চেষ্টা করে লাভ হবে না।

সাধারণ failure-এর জন্য ভিন্ন setting ব্যবহৃত হয়। timeout বা parse error হলে search.ban_time_on_fail থেকে নির্ধারিত স্বল্প সময়ের জন্য engine suspended হয়। search.ban_time_on_fail-এর default 5 সেকেন্ড এবং search.max_ban_time_on_fail এটিকে সর্বোচ্চ 120 সেকেন্ডে সীমাবদ্ধ করে। তাই ধীর engine কয়েক মিনিটের মধ্যে নিজে থেকে পুনরুদ্ধার করে, কিন্তু blocked engine কয়েক ঘণ্টার জন্য অনুপস্থিত থাকে। এই পার্থক্যটি ব্যবহারকারীদের জানানো একটি আপাতদৃষ্টিতে random সমস্যার কারণ ব্যাখ্যা করে: প্রথমে ফলাফল স্বাভাবিক থাকে, তারপর বিকেলের বাকি সময় একটি engine-এর ফলাফল আর দেখা যায় না।

কাউকে দোষ দেওয়ার আগে timeout ঠিক করা উচিত। default request_timeout হলো 2.0 সেকেন্ড। কোনো engine-এর নিকটতম edge server থেকে দূরে থাকা ছোট VPS-এর জন্য এই সময়সীমা কম হতে পারে।

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

request_timeout হলো প্রতিটি engine-এর default, max_request_timeout হলো সর্বোচ্চ সীমা, এবং কোনো নির্দিষ্ট engine-এর নিজস্ব timeout থাকতে পারে। এগুলোর মান বাড়ালে page latency বাড়ার বিনিময়ে failure কমে। তাই সরাসরি 10 নির্ধারণ না করে অর্ধ সেকেন্ড করে বাড়ান এবং /stats/errors monitor করুন।

কোনো engine সত্যিই আপনার address block করলে সেটি সরিয়ে দিন। প্রতিটি search ধীরতম engine-এর জন্য অপেক্ষা করে। তাই স্থায়ীভাবে suspended engine রেখে দিলে latency বাড়ে এবং কোনো ফলাফল ফেরত আসে না।

use_default_settings:
  engines:
    remove:
      - google

docker compose restart searxng-core দিয়ে পরিবর্তন প্রয়োগ করুন। এরপর কয়েকটি search চালিয়ে /stats/errors reload করুন। বাস্তব ব্যবহারের 5 মিনিট পরেও page ফাঁকা থাকলে বুঝবেন পরিবর্তনটি কাজ করেছে।

ডেটাসেন্টারের IP-কে bot হিসেবে বিবেচনা করা হবে

আপনার VPS address একটি hosting range-এর অন্তর্ভুক্ত, এবং বড় search engine-গুলো এই range-গুলোকে automation হিসেবে স্কোর করে। কিছু engine এমন address থেকে আসা প্রতিটি request-এ CAPTCHA দেখায়, header যতই স্বাভাবিক হোক বা request-এর গতি যতই কম হোক। settings.yml-এর কোনো setting এই মূল্যায়ন পরিবর্তন করে না।

আপনি কোন engine-এ request পাঠাবেন এবং আপনার instance সর্বসাধারণের জন্য তালিকাভুক্ত থাকবে কি না, তা পরিবর্তন করতে পারেন। একটি household-এর ব্যবহারের জন্য private instance সাধারণত কোনো বাধার সম্মুখীন হয় না। hosting IP-তে থাকা public instance কঠোর engine-গুলোতে suspension পেতে থাকবে। এটি আপনার config-এর ত্রুটি নয়; software-এর স্বাভাবিক আচরণ। SearXNG outgoing.proxies বা outgoing.using_tor_proxy ব্যবহার করে proxy-এর মাধ্যমে engine request পাঠাতে পারে। এতে network traffic অন্য address থেকে যাবে। Exit node এবং সস্তা proxy pool-কে hosting range-এর চেয়েও খারাপভাবে স্কোর করা হয়। তাই এই পরিবর্তনে ফলাফল আরও খারাপ হওয়ার সম্ভাবনা রয়েছে।

ইনস্ট্যান্সটি মনিটর করুন, যাতে আগে জানতে পারেন

প্রতিটি engine suspended থাকলেও SearXNG তার port-এ উত্তর দেয়। তাই শুধু status code পর্যবেক্ষণ করা uptime check সবুজ দেখাতে থাকে, যদিও instance কোনো ফলাফল ফেরত দেয় না। এর পরিবর্তে content পরীক্ষা করুন: একটি বাস্তব search request পাঠান এবং response body-তে প্রত্যাশিত একটি শব্দ খুঁজুন। Uptime Kuma keyword monitoring কোনো অতিরিক্ত tooling ছাড়াই ঠিক এটি করে। প্রতিটি version bump-এর পরেও /stats/errors monitor করুন, কারণ engine-এর HTML পরিবর্তিত হতে পারে এবং কোনো rate limit ছাড়াই parser ভেঙে যেতে পারে।

FAQ

SearXNG-কে reverse proxy-এর পেছনে রাখার পর কেন প্রত্যেক visitor-এর জন্য 429 ফেরত আসে?

কারণ limiter proxy-কে client হিসেবে গণনা করছে। সংযোগকারী address trusted_proxies-এ /etc/searxng/limiter.toml হিসেবে তালিকাভুক্ত থাকলেই SearXNG X-Forwarded-For পড়ে। এটি তালিকাভুক্ত না থাকলে প্রত্যেক visitor একই counter ভাগ করে ব্যবহার করে এবং সবাই মিলে 10 মিনিটে 150 requests-এর সীমা অতিক্রম করে। আপনার proxy যে address থেকে সংযোগ করে, সেটি যোগ করুন। Docker-এ এটি সাধারণত bridge range 172.16.0.0/12 হয়। Proxy যেন X-Real-IP এবং X-Forwarded-For পাঠায়, তাও নিশ্চিত করুন। আপনি নিয়ন্ত্রণ করেন না এমন কোনো range কখনো তালিকাভুক্ত করবেন না। কারণ trusted network থাকলে যেকোনো visitor ওই header সেট করে প্রতিটি request-এর জন্য নতুন identity বেছে নিতে পারে।

SearXNG limiter প্রতি ঘণ্টায় কত API request অনুমোদন করে?

প্রতি IP address-এর জন্য প্রতি ঘণ্টায় 4টি। HTML ছাড়া অন্য format চাওয়া প্রতিটি request আলাদা এক ঘণ্টার window-এ গণনা হয়। এই limit limiter.toml-এর পরিবর্তে searx/botdetection/ip_limit.py-এ সেট করা থাকে, তাই config থেকে এটি বাড়ানো যায় না। কোনো agent বা script একটি task-এর মধ্যেই এই সীমা অতিক্রম করতে পারে। Client-এর address limiter.toml-এর pass_ip-এ যোগ করুন। অথবা এমন internal network দিয়ে instance-এ পৌঁছান, যেখানে limiter request দেখতে পায় না।

429 error ছাড়াই আমার search result খালি আসে কেন?

সমস্যাটি আপনার user-দের নয়; engine-গুলো আপনার server-কে প্রত্যাখ্যান করছে। নিজের instance-এ /stats/errors খুলুন। সেখানে কোন engine ব্যর্থ হয়েছে এবং কেন হয়েছে, তা দেখানো হয়। CAPTCHA বা access-denied entry থাকলে বুঝতে হবে ওই engine আপনার server-এর IP address block করেছে। too-many-requests উত্তর পাওয়ার পর SearXNG engine-টিকে এক ঘণ্টার জন্য suspend করে। CAPTCHA পাওয়ার পর এক দিনের জন্য suspend করে। কোনো local setting upstream block তুলে দিতে পারে না। তাই যে engine-গুলো আপনার address block করে সেগুলো সরিয়ে দিন এবং যে engine-গুলো উত্তর দেয় সেগুলো রাখুন।

Private instance-এ কি limiter enable করা উচিত?

আপনি ছাড়া আর কেউ instance-এ পৌঁছাতে না পারলে limiter: false অবস্থায় রাখুন। এটি Valkey dependency যোগ করে এবং আপনার নিজের script block করে। আপনি যে traffic-এর মুখোমুখি হন না, এটি তার বিরুদ্ধে সুরক্ষা দেয়। Instance-টি public address পাওয়ার সঙ্গে সঙ্গে public_instance: true-এর পাশাপাশি limiter enable করুন। এই জোড়াটি ইচ্ছাকৃত। public_instance: true সক্রিয় থাকা অবস্থায় কার্যকর Valkey না থাকলে process সুরক্ষা ছাড়া চলার পরিবর্তে status 1 দিয়ে exit করে।