SearXNG 429 Error সমাধান করার উপায়

কেন SearXNG 429 (429) এরর প্রদান করে

একটি self-hosted SearXNG ইনস্ট্যান্স দুটি ভিন্ন কারণে 429 (429) এরর প্রদান করতে পারে এবং যে rate limit-টি আপনার ঠিক করা প্রয়োজন, তা সাধারণত আপনার ধারণার চেয়ে ভিন্ন হয়। প্রথম কারণটি স্থানীয়: SearXNG-এর নিজস্ব লিমিটার সিদ্ধান্ত নেয় যে অনুরোধটি কোনো বট থেকে এসেছে এবং Too Many Requests এর মাধ্যমে 429 স্ট্যাটাস কোড প্রদান করে। দ্বিতীয় কারণটি আপস্ট্রিম: একটি সার্চ ইঞ্জিন আপনার সার্ভারের IP অ্যাড্রেস প্রত্যাখ্যান করেছে, যা আপনার ব্যবহারকারীদের কাছে ফলাফল পৃষ্ঠায় কিছু তথ্য অনুপস্থিত হিসেবে পৌঁছায়, 429 এরর হিসেবে নয়।

এই দুটি সমস্যার সমাধানের কোনো মিল নেই। লিমিটারটি আপনার নিজস্ব, তাই আপনি এটি পরিবর্তন করতে পারেন। আপস্ট্রিম ব্লকিং ঘটে Google-এর দিক থেকে, তাই আপনার settings.yml-এর কোনো কিছুই এটি সমাধান করতে পারবে না। লগ ফাইলটি পরীক্ষা করলে এক মিনিটের মধ্যেই আপনি বুঝতে পারবেন সমস্যাটি কোনটি, তাই সেখান থেকেই শুরু করুন।

এই নির্দেশিকাটি আপনার নিজস্ব VPS-এ একটি self-hosted SearXNG ইনস্ট্যান্স তৈরির প্রক্রিয়ার ওপর ভিত্তি করে লেখা। নিচে উল্লেখিত প্রতিটি সেটিংয়ের নাম বর্তমান আপস্ট্রিম ডকুমেন্টেশন এবং সোর্স থেকে নেওয়া হয়েছে, যা আগস্ট 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 লেখা থাকে, যার অর্থ হলো কোনো কিছুই গণনা করা হচ্ছে না।

প্রতিটি পৃথক bot check ডিবাগ লেভেলে লগ করা হয়, তাই ডিফল্টভাবে আপনি এটি দেখতে পাবেন না। একটি টেস্টের জন্য settings.yml-এ ডিবাগ চালু করুন:

general:
  debug: true

এরপর লগটিতে ক্লায়েন্ট নেটওয়ার্কের পাশে NOT OK (http_accept_language)-এর মতো লাইন যুক্ত হবে, যেখানে ব্যর্থ হওয়া চেকটির নাম থাকবে। কাজ শেষ হলে এটি আবার বন্ধ করে দিন, কারণ upstream থেকে পরামর্শ দেওয়া হয় যে, deployed instance-এ ডিবাগ চালু রাখা উচিত নয়।

ইঞ্জিন ব্যর্থতাগুলো দেখতে এমন হয় না। এগুলো IP-এর পরিবর্তে একটি ইঞ্জিনের নাম উল্লেখ করে এবং সবচেয়ে সাধারণ সমস্যাটি হলো টাইমআউট:

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

এর জন্য একটি আলাদা পেজও রয়েছে। enable_metrics-কে এর ডিফল্ট মান true-এ রেখে, আপনার instance /stats/errors-এ ইঞ্জিনের ত্রুটিগুলো রেকর্ড করে এবং /preferences-এ বর্তমানে কোন ইঞ্জিনগুলো সাড়া দিচ্ছে তার তালিকা থাকে। যদি /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

কম্পোজ ফাইলটি docker.io/searxng/searxng:${SEARXNG_VERSION:-latest} পুল করে। একটি ভেরিয়েবল সেট করা না থাকলে তার অর্থ latest, এবং latest মানে হলো পরবর্তী docker compose pull-এর সময় ইনস্ট্যান্সটি আপনার অজান্তেই পরিবর্তিত হয়ে যাবে। ফলে গত সপ্তাহে যে সেটিংস কাজ করছিল, তা বর্তমান কোডের সাথে আর সামঞ্জস্যপূর্ণ নাও হতে পারে। SearXNG ট্যাগগুলোতে একটি তারিখ এবং একটি কমিট আইডি থাকে। আগস্ট 2026 অনুযায়ী আপস্ট্রিম .env.example-এর উদাহরণস্বরূপ ট্যাগটি হলো 2026.3.25-541c6c3cb, তাই .env-এ একটি নির্দিষ্ট ট্যাগ সেট করুন:

SEARXNG_VERSION=2026.3.25-541c6c3cb

প্রকাশিত ট্যাগগুলো যাচাই করুন এবং আপনি যে রিলিজটি পরীক্ষা করেছেন সেটি পিন করুন, তারপর একটি নির্দিষ্ট টার্গেটের বিপরীতে ডিবাগ করুন। একই .env ফাইলে আপনার সিক্রেট কি থাকে, তাই সেই ডিরেক্টরি কোথাও কমিট করার আগে Docker Compose-এ env ফাইল এবং সিক্রেট কীভাবে কাজ করে তা পড়ে নিন।

লিমিটারের জন্য Valkey প্রয়োজন, অন্যথায় এটি চলবে না

Limiter প্রতি client-এর অনুরোধের সংখ্যা গণনা করে। এই গণনাগুলো worker process-গুলোর মধ্যে ভাগ করে ব্যবহার করতে হয়। সেই store হলো Valkey, যা Redis-এর রক্ষণাবেক্ষণাধীন fork। পুরোনো SearXNG guide-গুলোতে এই setting-কে redis: বলা হয়েছে। বর্তমান release-গুলো valkey: পড়ে। তাই পুরোনো post থেকে নয়, বর্তমান documentation থেকে key-এর নাম কপি করুন। কিছু page আরও পুরোনো এবং সেখানে SearXNG-এর বদলে Searx বর্ণনা করা হয়েছে। এটি ভিন্ন codebase এবং ভিন্ন limiter ব্যবহার করে। তাই কোনো page থেকে config block কপি করার আগে page-টি কোন দুইটির একটি project-এর জন্য লেখা হয়েছে তা নির্ধারণ করুন।

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

আপস্ট্রিম compose ফাইলে ইতিমধ্যেই docker.io/valkey/valkey:9-alpine ইমেজে একটি searxng-valkey সার্ভিস চলে, তাই compose নেটওয়ার্কের ভেতরে এই হোস্ট নেমটি রিজলভ হয়। একই মান SEARXNG_VALKEY_URL এনভায়রনমেন্ট ভেরিয়েবলের মাধ্যমে সেট করা যায় এবং যখন SearXNG ও Valkey একই হোস্ট শেয়ার করে, তখন একটি Unix socket URL (unix:///path/to/socket.sock?db=0) কার্যকর হয়।

স্টোরটি অনুপস্থিত থাকলে কী ঘটবে তা অন্য একটি কী-এর ওপর নির্ভর করে। public_instance: false থাকলে, লিমিটার Valkey-এর ত্রুটি লগ করে এবং কাজ বন্ধ করে দেয়, ফলে ইনস্ট্যান্সটি কোনো রেট লিমিটিং ছাড়াই চলতে থাকে। public_instance: true থাকলে, প্রসেসটি পরিবর্তে sys.exit(1) কল করে, কারণ বট প্রোটেকশন ছাড়া একটি ওপেন ইনস্ট্যান্স একদিনের মধ্যেই প্রতিটি ইঞ্জিন থেকে CAPTCHA (কম্পিউটার ও মানুষের পার্থক্য করার জন্য সম্পূর্ণ স্বয়ংক্রিয় পাবলিক টুরিং টেস্ট) সংগ্রহ করে ফেলে। public_instance: true সেট করার পরপরই যে কন্টেইনারটি লুপে রিস্টার্ট হতে থাকে, সেটি মূলত এই কারণেই হয় এবং প্রতিটি এক্সিটের আগের শেষ লাইনে 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"
  }
]

একজন সাধারণ ক্লায়েন্ট 20 সেকেন্ডের একটি বার্স্ট উইন্ডোর মধ্যে 15 টি অনুরোধ এবং 10 মিনিটের উইন্ডোর মধ্যে 150 টি অনুরোধ করতে পারে। কোনো অনুরোধ সন্দেহজনক হিসেবে চিহ্নিত হলে, সেই একই ক্লায়েন্টের সীমা প্রতি বার্স্ট উইন্ডোতে 2 এ নেমে আসে। শেষ সারিটি সবচেয়ে কঠোর: 30 দিনের উইন্ডোর মধ্যে 3 টি অনুরোধ সন্দেহজনক হিসেবে চিহ্নিত হলে, সেই অ্যাড্রেসটিকে সার্চ করার পরিবর্তে স্টার্ট পেজে রিডাইরেক্ট করা হয় এবং লগে BLOCK: too many request from ... in SUSPICIOUS_IP_WINDOW (redirect to /) বার্তাটি দেখা যায়।

এই সংখ্যাগুলো searx/botdetection/ip_limit.py এ ধ্রুবক হিসেবে থাকে। এগুলো কোনো সেটিংস নয় এবং limiter.toml এগুলো পরিবর্তন করার সুযোগ দেয় না, তাই এগুলো পরিবর্তন করতে হলে সোর্স কোড এডিট করতে হবে। /etc/searxng/limiter.toml যা নিয়ন্ত্রণ করে তা হলো ক্লায়েন্টদের গ্রুপ করার জন্য ব্যবহৃত অ্যাড্রেস প্রিফিক্স, ট্রাস্টেড প্রক্সির তালিকা, ঐচ্ছিক লিঙ্ক টোকেন চেক এবং পাস ও ব্লক লিস্ট।

হেডার চেকের মাধ্যমে একটি অনুরোধ সন্দেহজনক হিসেবে চিহ্নিত হয় এবং প্রতিটি চেকের একটি নাম থাকে যা আপনি ডিবাগ লগে দেখতে পাবেন:

• http_accept: Accept হেডারে text/html নেই।
• http_accept_encoding: Accept-Encoding হেডারে gzip বা deflate কোনোটিরই নাম নেই।
• http_accept_language: কোনো Accept-Language হেডার নেই।
• http_connection: Connection হেডারটি close এ সেট করা আছে।
• http_user_agent: User-Agent অনুপস্থিত অথবা এটি কোনো পরিচিত বট প্যাটার্নের সাথে মিলে যায়।
• http_sec_fetch: Sec-Fetch-Mode বা Sec-Fetch-Dest হেডারটি ব্রাউজার যা পাঠায় তার সাথে মেলে না।

একটি ব্রাউজার এই সবগুলোই পাঠায়। একটি সাধারণ curl কল এগুলোর প্রায় কোনটিই পাঠায় না, তাই হাতে লেখা একটি টেস্ট রিকোয়েস্ট প্রথমবারই ফ্ল্যাগ হয়ে যায়, অথচ ব্রাউজার ট্যাবে একই সার্চ কাজ করে। এই কারণেই "আমার ব্রাউজারে কাজ করছে, কিন্তু আমার স্ক্রিপ্ট 429 এরর পাচ্ছে" - এটি কোনো রহস্য নয়, বরং একটি স্বাভাবিক ফলাফল।

রিভার্স প্রক্সির পেছনে লিমিটার সবাইকে একসাথে ব্লক করে দেয়

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

যদি আপনার প্রক্সির ঠিকানা সেই তালিকায় না থাকে, তবে হেডারগুলো উপেক্ষা করা হয় এবং প্রতিটি ভিজিটর প্রক্সির ঠিকানা নিয়েই আসে। ফলে তারা একটি কাউন্টার শেয়ার করে এবং মোট অনুরোধের সংখ্যা 10 মিনিটে 150 অতিক্রম করলেই পুরো সাইট ব্লক হয়ে যায়। একজন ব্যবহারকারী কয়েকবার রেজাল্ট পেজ রিলোড করলেই সবার জন্য সাইটটি বন্ধ হয়ে যায়।

অতিরিক্ত বিশ্বাস করা আরও বিপজ্জনক। যদি কোনো পাবলিক রেঞ্জ তালিকায় থাকে, তবে যেকোনো ভিজিটর তাদের নিজস্ব X-Forwarded-For হেডার পাঠাতে পারে এবং প্রতিটি অনুরোধের জন্য নতুন পরিচয় বেছে নিতে পারে, যা এই কৌশলটি জানা সবার জন্য লিমিটারকে অকার্যকর করে দেয়। শুধুমাত্র আপনার প্রক্সি যে ঠিকানা থেকে সংযোগ করে সেটিই তালিকায় রাখুন। ডকারে এটি সাধারণত 172.16.0.0/12-এর ভেতরে একটি ব্রিজ নেটওয়ার্ক হয় এবং সেই লাইনটি ডিফল্টভাবে কমেন্ট করা থাকে।

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48

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

প্রক্সিকে অবশ্যই হেডারগুলো পাঠাতে হবে। 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 আপনার জন্য ফরওয়ার্ডেড হেডারগুলো সেট করে দেয়, তাই সেগুলোর ক্ষেত্রে আপনার শুধুমাত্র trusted_proxies অংশটি সম্পন্ন করলেই চলে। এর সুবিধা ও অসুবিধাগুলো choosing a reverse proxy for a self-hosted service-এ আলোচনা করা হয়েছে। যেকোনো সেটআপ যাচাই করতে debug চালু করুন, মোবাইল ডেটা ব্যবহার করে আপনার ফোন থেকে একবার সার্চ করুন এবং লগ লাইনে থাকা নেটওয়ার্কটি প্রক্সির ঠিকানার পরিবর্তে আপনার ফোনের ঠিকানা কি না তা নিশ্চিত করুন।

আপনার এজেন্ট প্রতি ঘণ্টায় চারটি API অনুরোধ পায়

JSON আউটপুট ডিফল্টভাবে নিষ্ক্রিয় থাকে, তাই এজেন্টের জন্য এটি যুক্ত করা প্রয়োজন:

search:
  formats:
    - html
    - json

এখন চার্টের সারিটি পুনরায় পড়ুন। HTML ছাড়া অন্য কোনো ফরম্যাটের অনুরোধ তার নিজস্ব উইন্ডোতে গণনা করা হয়: প্রতি ঠিকানায় প্রতি 1 hour সময়ে 4 টি অনুরোধ। একটি রিসার্চ এজেন্ট একটি টাস্কেই এই সীমা শেষ করে ফেলে এবং এরপর প্রতিটি কলের উত্তরে 429 ত্রুটি দেখায়। সীমা বাড়ানো কোনো সমাধান নয়, কারণ এই সংখ্যাটি সোর্স কোডের ভেতরে থাকে।

এর সঠিক সমাধান হলো লিমিটারকে জানানো যে এই ক্লায়েন্ট অপরিচিত কেউ নয়। limiter.toml-এ এর ঠিকানাটি pass তালিকায় যুক্ত করুন:

[botdetection.ip_lists]
block_ip = []

pass_ip = [
  '10.8.0.0/24',
]

pass_searxng_org = true

pass_ip অন্য যেকোনো পদ্ধতির চেয়ে বেশি অগ্রাধিকার পায়, তাই একটি allowlist-ভুক্ত ক্লায়েন্ট হেডার চেক এড়িয়ে যায় এবং একটি সাধারণ 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"
  }
]

কোনো 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 স্তরে রয়েছে এবং retry করে লাভ হবে না। আপনি যে তিনটি CAPTCHA row-এর কোনটিতে পৌঁছেছেন, তার ওপর পরবর্তী পদক্ষেপ নির্ভর করে। আপনার instance কোন exception record করেছে তা জানার পর CAPTCHA error-এর জন্য আলাদা কিছু সমাধান রয়েছে।

সাধারণ ব্যর্থতার ক্ষেত্রে ভিন্ন সেটিংস ব্যবহৃত হয়। টাইমআউট বা পার্সিং এরর হলে ইঞ্জিনটিকে search.ban_time_on_fail থেকে প্রাপ্ত স্বল্প সময়ের জন্য স্থগিত রাখা হয়, যার ডিফল্ট মান 5 সেকেন্ড এবং search.max_ban_time_on_fail অনুযায়ী সর্বোচ্চ সীমা 120 সেকেন্ড। ফলে একটি ধীরগতির ইঞ্জিন কয়েক মিনিটের মধ্যেই নিজে থেকে সচল হয়ে যায়, কিন্তু ব্লক হওয়া ইঞ্জিন ঘণ্টার পর ঘণ্টা বন্ধ থাকে। এই পার্থক্যের কারণেই ব্যবহারকারীরা মাঝেমধ্যে এমন সমস্যার কথা জানান যেখানে সার্চ রেজাল্ট ঠিকঠাক আসে, কিন্তু হঠাৎ একটি ইঞ্জিনের রেজাল্ট পুরো দুপুরের জন্য অদৃশ্য হয়ে যায়।

কাউকে দোষারোপ করার আগে টাইমআউটের সমস্যাগুলো সমাধান করা উচিত। ডিফল্ট request_timeout হলো 2.0 সেকেন্ড, যা ইঞ্জিনের নিকটতম এজ সার্ভার থেকে দূরে অবস্থিত ছোট কোনো VPS-এর জন্য বেশ কম।

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

request_timeout হলো প্রতিটি ইঞ্জিনের জন্য ডিফল্ট মান, max_request_timeout হলো সর্বোচ্চ সীমা, এবং প্রতিটি ইঞ্জিন নিজস্ব timeout বহন করতে পারে। এই মানগুলো বাড়ালে পেজ লোড হওয়ার সময় কিছুটা বেড়ে যায় কিন্তু ব্যর্থতার হার কমে। তাই সরাসরি 10-এ না গিয়ে অর্ধেক সেকেন্ড করে বাড়িয়ে দেখুন এবং /stats/errors পর্যবেক্ষণ করুন।

যে ইঞ্জিনটি আপনার আইপি অ্যাড্রেসকে স্থায়ীভাবে ব্লক করে রেখেছে, সেটিকে সরিয়ে ফেলাই ভালো। প্রতিটি সার্চ তার সবচেয়ে ধীরগতির ইঞ্জিনের জন্য অপেক্ষা করে, তাই স্থায়ীভাবে স্থগিত থাকা ইঞ্জিন রেখে দিলে তা কেবল ল্যাটেন্সি বাড়ায় কিন্তু কোনো ফলাফল দেয় না।

use_default_settings:
  engines:
    remove:
      - google

পরিবর্তনগুলো কার্যকর করতে docker compose restart searxng-core ব্যবহার করুন, তারপর কয়েকটি সার্চ চালিয়ে /stats/errors রিলোড করুন। পাঁচ মিনিট ব্যবহারের পর যদি পেজটি খালি না দেখায়, তবে বুঝতে হবে পরিবর্তনটি সফল হয়েছে।

একটি ডেটাসেন্টার IP-কে বট হিসেবে গণ্য করা হবে

আপনার VPS-এর ঠিকানাটি একটি হোস্টিং রেঞ্জের অন্তর্ভুক্ত, এবং বড় সার্চ ইঞ্জিনগুলো এই রেঞ্জগুলোকে অটোমেশন হিসেবে চিহ্নিত করে। এদের মধ্যে কিছু ইঞ্জিন এমন ঠিকানা থেকে আসা প্রতিটি অনুরোধের জন্য CAPTCHA প্রদর্শন করে, তা আপনার হেডার যতই মার্জিত হোক বা অনুরোধের গতি যতই ধীর হোক না কেন। settings.yml-এ এমন কোনো সেটিং নেই যা এই সিদ্ধান্ত পরিবর্তন করতে পারে। সার্চ ইঞ্জিনগুলো আপনার সার্ভারকে দেখছে, কোনো ব্যক্তিকে নয়—এটিই সেই গোপনীয়তার বিনিময় যা আপনি সেলফ-হোস্টিংয়ের মাধ্যমে করেছেন। আপনি ধরে নেওয়ার আগে যে এটি সবকিছু আড়াল করে, SearXNG আসলে কতটা আড়াল করে তা পড়ে দেখা জরুরি।

আপনি যা পরিবর্তন করতে পারেন তা হলো, আপনি কোন ইঞ্জিনগুলোকে অনুরোধ করছেন এবং আপনার ইনস্ট্যান্সটি সর্বজনীনভাবে তালিকাভুক্ত কি না। একটি পরিবার দ্বারা ব্যবহৃত ব্যক্তিগত ইনস্ট্যান্স খুব কমই কোনো সমস্যার সম্মুখীন হয়। হোস্টিং IP-তে থাকা একটি পাবলিক ইনস্ট্যান্স কঠোর ইঞ্জিনগুলোর কাছ থেকে বারবার নিষেধাজ্ঞা পেতে পারে, এবং এটি সফটওয়্যারের একটি স্বাভাবিক অবস্থা, আপনার কনফিগারেশনের কোনো ত্রুটি নয়। SearXNG outgoing.proxies বা outgoing.using_tor_proxy ব্যবহার করে প্রক্সির মাধ্যমে ইঞ্জিনের অনুরোধগুলো পাঠাতে পারে, যা ট্রাফিককে অন্য একটি ঠিকানায় সরিয়ে নেয়। এক্সিট নোড এবং সস্তা প্রক্সি পুলের স্কোর হোস্টিং রেঞ্জের চেয়েও খারাপ হয়, তাই এই পদক্ষেপের ফলে সার্চ রেজাল্ট আরও খারাপ হওয়ার আশঙ্কা থাকে।

ইনস্ট্যান্সটি পর্যবেক্ষণ করুন যাতে আপনি সবার আগে জানতে পারেন

SearXNG-এর সব ইঞ্জিন সাসপেন্ড করা থাকলেও এটি তার পোর্টে রেসপন্স দেয়, তাই শুধুমাত্র স্ট্যাটাস কোড চেক করে আপটাইম মনিটর করলে সেটি সবসময় গ্রিন দেখাবে, যদিও ইনস্ট্যান্সটি আসলে কোনো ফলাফল দিচ্ছে না। এর পরিবর্তে কন্টেন্ট চেক করুন: একটি রিয়েল সার্চ রিকোয়েস্ট পাঠান এবং রেসপন্স বডিতে প্রত্যাশিত কোনো শব্দ আছে কি না তা যাচাই করুন। Uptime Kuma keyword monitoring কোনো অতিরিক্ত টুল ছাড়াই ঠিক এই কাজটি করে। প্রতিটি ভার্সন আপডেটের পর /stats/errors পর্যবেক্ষণ করুন, কারণ ইঞ্জিনগুলো তাদের HTML পরিবর্তন করলে কোনো রেট লিমিট ছাড়াই পার্সার কাজ করা বন্ধ করে দিতে পারে।

FAQ

আমার reverse proxy-এর পেছনে SearXNG সেটআপ করার পর কেন এটি প্রতিটি ভিজিটরকে 429 error দিচ্ছে?

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

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

প্রতি IP ঠিকানায় প্রতি ঘণ্টায় চারটি। HTML ছাড়া অন্য কোনো ফরম্যাটের অনুরোধ একটি আলাদা এক ঘণ্টার উইন্ডোতে গণনা করা হয় এবং সেই সীমাটি limiter.toml-এর পরিবর্তে searx/botdetection/ip_limit.py-এ সেট করা থাকে, তাই কনফিগ থেকে এটি বাড়ানো সম্ভব নয়। একটি agent বা script এটি একটি টাস্কেই সম্পন্ন করে। ক্লায়েন্টের ঠিকানাটি limiter.toml ফাইলের pass_ip-এ যোগ করুন, অথবা এমন একটি internal network-এর মাধ্যমে instance-এ পৌঁছান যেখানে limiter অনুরোধটি দেখতে পায় না।

কেন আমার সার্চ রেজাল্ট কোনো 429 error ছাড়াই খালি আসছে?

ইঞ্জিনগুলো আপনার ব্যবহারকারীদের নয়, বরং আপনার সার্ভারকেই প্রত্যাখ্যান করছে। আপনার নিজের instance-এ /stats/errors খুলুন: এটি প্রতিটি ব্যর্থ ইঞ্জিনের নাম এবং কারণ দেখাবে। CAPTCHA বা access-denied এন্ট্রি মানে হলো সেই ইঞ্জিন আপনার সার্ভারের IP ঠিকানা ব্লক করেছে। SearXNG তখন সেই ইঞ্জিনটিকে স্থগিত করে দেয়—too-many-requests উত্তরের পর এক ঘণ্টার জন্য এবং CAPTCHA-এর পর এক দিনের জন্য। কোনো local setting upstream block সরাতে পারে না, তাই যে ইঞ্জিনগুলো আপনার ঠিকানা ব্লক করছে সেগুলোকে সরিয়ে ফেলুন এবং যেগুলো উত্তর দিচ্ছে সেগুলোকে রাখুন।

আমার কি একটি private instance-এ limiter চালু করা উচিত?

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