SearXNG pe un VPS: cum rulezi căutare privată fără să fie limitată până devine inutilă

Dacă instanța ta SearXNG merge impecabil în prima săptămână, apoi începe să întoarcă rezultate incomplete, să lovească CAPTCHA-uri, să piardă motoare de căutare pe rând sau să se transforme într-o interfață frumoasă care răspunde prost, problema nu este de obicei lipsa de CPU ori RAM. Problema reală este disciplina traficului. O instanță de căutare privată rămâne utilă doar dacă trei straturi sunt configurate corect în același timp: traficul utilizatorilor către aplicație, proxy-ul invers din față și traficul de ieșire către motoarele căutate în amonte. Dacă unul dintre aceste straturi este tratat superficial, instanța ta ajunge limitată până devine aproape inutilă.

Modelul sănătos pentru producție este simplu. Ții instanța privată în mod implicit. Transmiți corect IP-ul real al clientului prin proxy. Activezi limiterul SearXNG împreună cu Valkey. Pui rețelele tale de încredere pe listă de excepții în loc să dezactivezi protecția complet. Ții lista de motoare cât mai suplă. Reduci agresiv ritmul când furnizorii din amonte încep să răspundă cu blocări sau CAPTCHA. Dacă ai mai multe ieșiri legitime către internet, le folosești controlat. Dacă nu le ai, încetezi să te comporți ca și cum un singur IP public de VPS poate susține la nesfârșit un gateway de metacăutare pentru orice fel de trafic.

Ce face de obicei o instanță SearXNG să devină inutilă

Cele mai multe instalări eșuate de SearXNG nu mor pentru că aplicația ar fi slabă. Mor pentru că operatorul o tratează ca pe un site static cu o căsuță de căutare pusă deasupra.

• Proxy-ul invers transmite greșit IP-ul clientului, astfel încât toți utilizatorii par să fie chiar proxy-ul.
• Limiterul este dezactivat, configurat prost sau nu are Valkey, iar traficul abuziv ajunge să lovească din același IP public toate motoarele din amonte.
• Instanța este expusă mai larg decât ai fi dispus să recunoști, dar este tratată ca și cum ar fi doar pentru uz privat.
• Sunt activate prea multe motoare, iar o singură căutare se împrăștie în prea multe cereri de ieșire.
• Când apar răspunsuri de tip access denied sau CAPTCHA, instanța continuă să insiste în loc să se retragă.
• VPS-ul are un singur traseu de ieșire, dar este folosit de parcă ar susține fără probleme un serviciu public masiv.

Așa apare tiparul clasic: în prima lună pare excelent, în a doua devine enervant, iar în a treia nu mai ai încredere în el.

Prima regulă: hotărăște dacă instanța ta este cu adevărat privată

SearXNG face o distincție pe care mulți o ignoră prea ușor. O instanță privată și una publică nu trebuie tratate la fel. În setări, public_instance: true activează comportamente suplimentare gândite special pentru instanțe publice. Dacă îți construiești un motor de căutare pentru tine, pentru familie, pentru birou sau pentru utilizatori care intră doar prin VPN, nu-l trata ca pe o instanță publică doar pentru că este vizibilă pe internet.

Asta nu înseamnă că o lași neprotejată. Înseamnă că încetezi să te minți singur că „e publică, dar doar oamenii mei știu adresa” ar fi același lucru cu „e privată”. Nu este.

Un punct de plecare sănătos în settings.yml arată așa:

server:
  secret_key: "inlocuieste-cu-o-cheie-reala"
  limiter: true
  public_instance: false

valkey:
  url: valkey://127.0.0.1:6379/0

Asta face două lucruri importante. Ține limiterul activ și evită activarea unui comportament de instanță publică de care nu ai nevoie pe un serviciu privat autentic.

Dacă vrei hostul potrivit pentru o asemenea aplicație, un VPS KVM cu acces root complet este alegerea corectă. Acesta nu este genul de serviciu pe care îl pui într-un mediu constrâns și speri că stratul de rețea se va comporta frumos de la sine.

A doua regulă: proxy-ul invers trebuie să spună adevărul despre client

Aici apare una dintre cele mai frecvente defecțiuni tăcute. Limiterul SearXNG identifică clienții după IP. Dacă proxy-ul îi transmite date greșite despre client, limiterul devine inutil sau chiar dăunător.

Dacă toate cererile par să vină de la proxy, un singur utilizator nerăbdător poate declanșa limitări pentru toată lumea. Iar dacă mai adaugi și limitare în NGINX fără să repari mai întâi IP-ul real, doar dublezi prostia.

Pentru NGINX în fața lui SearXNG pe un subdomeniu dedicat, partea critică este simplă:

server {
    listen 443 ssl http2;
    server_name search.example.com;

    ssl_certificate     /etc/letsencrypt/live/search.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/search.example.com/privkey.pem;

    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;
    }
}

Dacă montezi SearXNG sub o subcale în loc de un subdomeniu dedicat, mai ai nevoie și de X-Script-Name. Sfatul operațional este totuși mai simplu: evită subcăile dacă poți. Un subdomeniu dedicat este mai ușor de înțeles și mai greu de stricat.

Dacă și NGINX este în spatele altui proxy sau al unui load balancer, repară mai întâi IP-ul real al clientului înainte să adaugi limitări pe IP:

set_real_ip_from 10.0.0.0/8;
set_real_ip_from 192.168.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Fără asta, orice limitare per IP este doar teatru.

A treia regulă: limiterul SearXNG nu este opțional pe o instanță expusă pe internet

Documentația SearXNG este foarte clară aici. Aplicația trimite interogările mai departe către motoare externe. Asta înseamnă că traficul abuziv împotriva instanței tale se transformă în trafic abuziv din IP-ul serverului tău către acele motoare. Rezultatul este previzibil. IP-ul serverului este tratat ca sursă suspectă, primește CAPTCHA sau este blocat direct.

Limiterul există exact ca să oprească această spirală înainte ca motoarele din amonte să te pedepsească. Dar limiterul are nevoie de Valkey. Fără el, lipsește tocmai componenta menită să împiedice un singur client prost sau abuziv să compromită instanța întreagă.

O configurație minimă și sănătoasă în /etc/searxng/limiter.toml ar trebui să definească măcar proxy-urile de încredere și, pentru rețelele tale legitime, o listă de excepții:

[botdetection]
trusted_proxies = [
  "127.0.0.0/8",
  "::1",
  "10.0.0.0/8",
  "192.168.0.0/16",
]

[botdetection.ip_lists]
pass_ip = [
  "10.8.0.0/24",
  "192.168.1.0/24",
]

Așa le dai spațiu utilizatorilor tăi de încredere, cum ar fi cei care intră prin VPN sau din LAN. Nu dezactivând complet protecția pentru toată instanța.

Un detaliu important este că logica de detectare a comportamentului abuziv nu tratează toate cererile la fel. Cererile automate și cele cu profil de API sunt judecate mai sever decât navigarea normală în interfață. Dacă atârni de instanță extensii, scripturi sau integrări care lovesc agresiv autocomplete-ul și căutarea, poți declanșa singur exact mecanismele de protecție pe care apoi le înjuri.

A patra regulă: limitarea din NGINX ajută, dar nu înlocuiește limiterul din SearXNG

NGINX poate limita rata de cereri per IP. Este util pentru a opri izbucnirile evidente înainte să ajungă în aplicație. Nu este însă un substitut pentru limiterul SearXNG, pentru că NGINX nu știe către câte motoare va fi împrăștiată o căutare și nici ce tip de presiune generează fiecare cerere în amonte.

O protecție practică la intrare poate arăta așa:

http {
    limit_req_zone $binary_remote_addr zone=searxng_search:10m rate=2r/s;

    server {
        listen 443 ssl http2;
        server_name search.example.com;

        location = /search {
            limit_req zone=searxng_search burst=8 nodelay;

            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;
        }
    }
}

Pe o instanță privată, limitarea asta nu trebuie să fie exagerat de agresivă. Scopul ei este să oprească izbucnirile stupide, nu să transforme propriul tău motor de căutare într-un obstacol.

A cincea regulă: ține lista de motoare cât mai suplă

Fiecare motor activat îți mărește amprenta de trafic către exterior. O singură interogare se poate transforma într-un pachet mare de cereri dacă ai activat prea multe surse doar „ca să fie”.

Asta este una dintre cele mai puțin spectaculoase, dar cele mai eficiente optimizări pentru SearXNG. Fii selectiv. Păstrează doar motoarele pe care chiar le folosești și le consideri utile. O instanță privată de căutare nu trebuie să fie o colecție completă a tuturor conectorilor existenți.

Dacă anumite motoare trebuie să fie disponibile doar pentru utilizatori de încredere, folosește mecanismele dedicate din SearXNG pentru asta, în loc să le expui tuturor permanent.

A șasea regulă: tratează traficul de ieșire ca pe o decizie de arhitectură

Multe ghiduri despre SearXNG discută aproape exclusiv traficul de intrare și spun foarte puțin despre cel de ieșire. Este exact invers față de ce contează în practică. Utilitatea reală a instanței tale depinde enorm de modul în care iese spre motoarele externe.

SearXNG suportă proxy-uri de ieșire și alegerea explicită a adreselor sursă. Dacă ai mai multe trasee legitime de ieșire, cererile pot fi distribuite între ele, iar reîncercările pot folosi alt traseu. Asta ajută atunci când unul dintre furnizorii din amonte începe să considere un singur IP prea zgomotos sau suspect.

Un exemplu practic arată așa:

outgoing:
  request_timeout: 4.0
  retries: 1
  source_ips:
    - 198.51.100.10
    - 2001:db8:10::10
  proxies:
    https:
      - socks5://127.0.0.1:9050
      - socks5://127.0.0.1:9051
  useragent_suffix: "contact: admin@example.com"

Folosește asta responsabil. Mai multe adrese sursă sau mai multe proxy-uri sunt un mecanism de reziliență pentru o instanță privată legitimă. Nu sunt o invitație să transformi un VPS într-o fermă de scraping. Dacă împingi mai tare în amonte, tot blocat ajungi. Doar ceva mai distribuit.

Detaliul cu useragent_suffix merită menționat. Dacă pui acolo o informație de contact reală, unele blocări devin mai ușor de înțeles sau de tratat. Nu este o garanție, dar este mai bine decât să apari ca o cutie neagră anonimă.

A șaptea regulă: când motoarele din amonte încep să se plângă, te retragi

Dacă un motor începe să răspundă cu access denied sau CAPTCHA, nu continua să-l lovești ca un script încăpățânat. SearXNG oferă deja mecanisme de retragere temporară. Folosește-le.

Setările de căutare permit suspendarea temporară a motoarelor după eșecuri, iar valorile pentru SearxEngineAccessDenied și SearxEngineCaptcha sunt severe tocmai pentru că au sens. Când un furnizor ți-a provocat deja IP-ul cu o provocare de tip CAPTCHA, mai multe încercări nu sunt curaj. Sunt autosabotaj.

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 86400
    SearxEngineCaptcha: 86400

Poți ajusta valorile, dar principiul rămâne același: o instanță sănătoasă știe să se retragă atunci când motoarele sursă încep să respingă traficul.

Ce faci când IP-ul VPS-ului este deja provocat cu CAPTCHA

După ce un motor ți-a aruncat deja un CAPTCHA către IP-ul serverului, ai două sarcini. Prima este să oprești comportamentul care te-a adus acolo. A doua este să cureți provocarea pentru identitatea publică a acelui IP, dacă furnizorul îți permite asta.

SearXNG documentează o metodă practică pentru acest caz printr-un tunel SOCKS peste SSH:

ssh -q -N -D 8080 user@vps-ul-tau.example.com

Apoi îți configurezi browserul să iasă prin socks5://127.0.0.1:8080, verifici că folosește IP-ul serverului și rezolvi CAPTCHA-ul ca și cum ai fi chiar serverul. Asta este prim ajutor, nu strategie pe termen lung. Dacă nu repari cauza, provocarea revine.

Arhitectura pe care chiar am avea încredere să o lăsăm în producție

Pentru o instanță privată SearXNG care trebuie să rămână utilă și peste câteva luni, configurația de bază pe care am considera-o sănătoasă este aceasta:

• Debian 12 sau Ubuntu 24.04
• SearXNG în Docker Compose sau instalare nativă curată
• Valkey local pe același host
• NGINX în față, cu IP real transmis corect
• un subdomeniu dedicat, de exemplu search.example.com
• o listă mică și atent aleasă de motoare
• limiter activ, iar lista de excepții rezervată doar rețelelor cu adevărat de încredere

Nu este o arhitectură spectaculoasă. Perfect. Infrastructura pentru căutare privată ar trebui să fie liniștită și previzibilă, nu „creativă”.

Dacă ridici un stack self-hosted mai mare pe același host, merită să citești și gestionarea Docker și a containerelor pe un VPS. Dacă încă îți proiectezi hostul și nu ai ajuns la faza de întărire operațională, ghidul de self-hosting pentru website în 2026 este complementul bun la nivel de infrastructură. Iar dacă vrei mediul potrivit pentru această clasă de aplicații încă de la început, serverele virtuale ServerSpan sunt pagina-părinte corectă pentru articolul ăsta, pentru că îți dau exact stratul de control de care această aplicație are nevoie.

Checklist când instanța începe să se degradeze

• Verifică dacă proxy-ul invers transmite corect IP-ul real al clientului.
• Verifică dacă limiterul este activ și dacă Valkey răspunde cu adevărat.
• Verifică dacă proxy-urile de încredere sunt definite corect în limiter.toml.
• Verifică dacă rețelele tale private sau VPN-ul sunt pe lista de excepții, dacă asta îți dorești pentru ele.
• Elimină motoarele pe care nu le folosești.
• Vezi dacă motoarele din amonte sunt deja suspendate din cauza CAPTCHA-urilor sau a blocărilor.
• Dacă folosești mai multe ieșiri către internet, verifică dacă sunt folosite cu adevărat.

Primele comenzi care merită rulate sunt banale, dar utile:

curl -I https://search.example.com/
docker compose ps
docker compose logs --tail 200 searxng
redis-cli ping
valkey-cli ping

Dacă limiterul este „activ” doar pe hârtie, dar Valkey lipsește, este configurat pe adresa greșită sau nu răspunde, instanța ta doar mimează protecția.

Răspunsul practic

Căutarea privată pe un VPS nu devine inutilă pentru că SearXNG ar fi defect. Devine inutilă pentru că operatorii ignoră exact disciplina de trafic de care depinde. Dacă proxy-ul minte despre IP-ul clientului, limiterul nu te poate proteja corect. Dacă limiterul nu are Valkey, nu poate face ceea ce a fost construit să facă. Dacă lista de motoare este umflată, amprenta ta de trafic crește fără motiv. Dacă ignori semnalele de tip access denied și CAPTCHA, îți consumi singur reputația IP-ului serverului.

Rulează SearXNG ca pe un serviciu privat, nu ca pe o poartă hobby expusă internetului cu setări optimiste. Ține proxy-ul sincer. Ține limiterul real. Ține lista de motoare scurtă. Tratează traficul de ieșire ca pe parte din design. Așa rămâne utilă căsuța ta de căutare, în loc să se transforme într-o interfață frumoasă în care motoarele externe nu mai au încredere.