Paano Mag-self-host ng SearXNG sa Sarili Mong VPS

Ang binubuo mo

Ang self-hosting ng SearXNG ay nagbibigay sa iyo ng private search engine na tumatakbo sa sarili mong server. Ang SearXNG ay isang metasearch engine: ipinapadala nito ang query mo sa iba pang engine tulad ng Google, Bing, DuckDuckGo at Wikipedia, pagkatapos ay pinagsasama ang mga resulta sa isang result page. Walang profile na ginagawa at walang tracking cookie na sine-set, dahil ang tanging machine na nagtatago ng query mo ay ang sa iyo.

Maliit ang stack. Dalawang container, isang settings file at isang reverse proxy. Ang pangunahing desisyon ay kung private ang instance, ibig sabihin ikaw at ang sarili mong scripts lang ang makaka-access dito, o public, ibig sabihin kahit sino sa internet ay maaaring mag-query dito. Binabago ng desisyong iyon ang security settings, kaya gawin ito bago ka mag-type ng anuman. Ang default na sagot ay private.

May isa pang dahilan para magpatakbo nito. JSON ang ginagamit na interface ng isang SearXNG instance, kaya makakakuha ang anumang script o AI agent na gagawin mo ng search API na pagmamay-ari mo, na walang key, walang per-query billing at walang quota mail.

I-install ang SearXNG gamit ang Docker Compose

Naglalabas ang proyekto ng container image at Compose file. I-download ang dalawang ito sa bagong Ubuntu 24.04 server na mayroon nang Docker Engine at Compose plugin. Kung bago sa iyo ang Docker, magsimula sa Mga pangunahing kaalaman sa Docker Compose sa isang VPS at bumalik dito.

sudo install -d -o "$USER" -g "$USER" -m 750 /opt/searxng
cd /opt/searxng
mkdir -p core-config
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

Tinutukoy ng Compose file ang dalawang serbisyo. Ang core ang mismong SearXNG, at ang valkey ay isang in-memory data store na ginagamit para sa rate limiting at panandaliang state. Naka-mount ang ./core-config/ sa /etc/searxng/ sa loob ng container, kaya nasa iisang directory lang sa host ang lahat ng kino-configure mo.

I-edit ngayon ang .env. Naka-comment out ang bawat linya sa halimbawang kasama sa package. Dahil dito, nagsisimula ang container sa port 8080 sa lahat ng address. I-uncomment at itakda ang tatlong ito.

SEARXNG_VERSION=latest
SEARXNG_HOST=127.0.0.1
SEARXNG_PORT=8080

Ang SEARXNG_HOST=127.0.0.1 ang pinakamahalaga. Itinatakda nito ang published port bilang 127.0.0.1:8080:8080 sa halip na [::]:8080:8080, kaya loopback address lang ang sinasagot ng container at hindi ito direktang maa-access ng internet. Kapag nilaktawan mo ito, exposed ang container agad pag-start nito, dahil inilalagay ang published Docker port bago ang iyong firewall rules. Basahin nang buo ang mahalagang pitfall na ito: nilalampasan ng published Docker ports ang ufw.

Ayos ang SEARXNG_VERSION=latest habang nag-aaral ka. Sa server na mahalaga sa iyo, i-pin ang tag. Noong July 2026, date-based ang mga release tag at ganito ang anyo ng 2026.3.25-541c6c3cb, kaya mag-a-upgrade ang pinned deployment kapag ikaw ang nagpasya, hindi kapag nagbago ang registry nang hindi mo inaasahan.

settings.yml: mga bahaging mahalaga

Gawin ang core-config/settings.yml bago ang unang start. Sinasabi ng use_default_settings: true sa SearXNG na i-load ang sarili nitong inilabas na default at ilapat lamang ang mga key na isinulat mo. Dahil dito, maikli ang file at mananatili itong gumagana sa mga upgrade na nagdaragdag ng mga bagong option.

I-generate muna ang secret, dahil direktang ilalagay ang value sa file.

openssl rand -hex 32

use_default_settings: true

general:
  instance_name: "search.example.com"

server:
  base_url: "https://search.example.com/"
  secret_key: "paste-the-openssl-output-here"
  limiter: false
  public_instance: false
  image_proxy: true

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

search:
  safe_search: 0
  autocomplete: "duckduckgo"
  formats:
    - html
    - json

Pinipirmahan ng secret_key ang session at token data. Ang inilabas na default ay ang literal na string na ultrasecretkey. Kung iiwan ito, maaaring gumawa ng huwad na token ang sinumang nakaaalam ng default na iyon. Palitan ito nang isang beses, pagkatapos ay huwag nang baguhin: kapag binago mo ito sa ibang pagkakataon, mabubura ang lahat ng naka-save na preference.

Ang base_url ay dapat ang pampublikong HTTPS address, kasama ang trailing slash. Ito ang ginagamit ng SearXNG sa mga link na ginagawa nito. Kung mananatili itong nakaturo sa localhost, ang link na “next page” sa remote browser ay tuturo sa sariling machine ng user at mabibigo.

Tinutukoy ng formats kung aling output type ang gagawin ng web endpoint. Wala ang json sa default list, kaya magbabalik ng 403 ang JSON request hanggang idagdag mo ito. Niruruta ng image_proxy: true ang mga thumbnail ng resulta sa iyong server, kaya hindi makikita ng mga site na nagho-host ng mga larawang iyon ang mga address ng iyong mga visitor.

Ginagamit ng valkey.url ang hostname na valkey dahil iyon ang service name sa Compose file. Inilalagay ng Compose ang dalawang container sa iisang network kung saan nagre-resolve ang mga service name. Ituro ito sa localhost at mabibigo ang limiter, dahil sa loob ng core container, ang localhost ay ang container mismo.

Nasa plain file ang secret, kaya protektahan ang directory na kinalalagyan nito sa halip na ang file mismo. Pinipigilan ng chmod 750 /opt/searxng ang ibang host user na makapasok. Huwag gawing mode 600 ang core-config/settings.yml: tumatakbo ang container bilang sarili nitong unprivileged user, at kapag hindi nito nabasa ang file, hindi talaga mag-i-start ang SearXNG.

I-start ang stack at suriin ito.

cd /opt/searxng
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080/

Dapat ipakita ng docker compose ps ang dalawang container na nasa state na running. Dapat sumagot ang curl ng HTTP/1.1 200 OK. Kung wala itong isagot, basahin ang docker compose logs core, dahil lalabas doon bilang parse error na tumutukoy sa line ang YAML mistake sa settings.yml.

Ilagay sa likod ng nginx na may TLS

Ang container ay nakikinig lamang sa loopback, kaya nginx ang nagpapahintulot na ma-access ito. Ito rin ang nagdaragdag ng transport layer security (TLS). Isulat ang /etc/nginx/sites-available/searxng.

server {
    listen 80;
    server_name search.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo ln -s /etc/nginx/sites-available/searxng /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d search.example.com

Ipinapakita ng nginx -t ang syntax is ok at test is successful bago ka mag-reload. Muling isinusulat ng Certbot ang parehong file upang makinig sa 443 gamit ang certificate, at nagdaragdag ito ng redirect mula sa port 80. Dapat nakaturo na sa server na ito ang DNS record para sa search.example.com, dahil pinatutunayan ng certificate authority ang pagmamay-ari sa pamamagitan ng pagkuha ng file gamit ang HTTP. Nasa gabay sa Certbot at nginx para sa Ubuntu 24.04 ang kumpletong walkthrough, kasama ang renewal.

Hindi palamuti ang dalawang forwarding header. Kung wala ang X-Forwarded-For at X-Real-IP, dala ng bawat request na dumarating sa SearXNG ang address ng proxy. Dahil dito, nakikita ng rate limiter na iisang client ang gumagawa ng lahat ng traffic at hindi nito matukoy ang pagkakaiba ng mga visitor.

Bakit nangangailangan ang mga script at agent ng JSON search API

Kapag may json sa formats, ang parehong endpoint na nagre-render ng page ay nagbabalik ng structured data.

curl -s 'http://127.0.0.1:8080/search?q=wireguard+mtu&format=json' \
  | jq -r '.results[0:5][] | .url'

Makakakuha ka ng object na may results array. Bawat entry ay naglalaman ng url, title, content, at engine na nagbigay nito, kasama ang answers, infoboxes, at suggestions. Sapat na ito para gamitin sa summariser, link checker, o research loop.

Mahalaga ito para sa anumang agent-shaped na workflow. May training cutoff ang language model, kaya kailangan nito ng live search upang makasagot sa mga tanong tungkol sa kasalukuyang panahon. Samantala, naniningil ang commercial search API sa bawat query at mahigpit na naglalapat ng rate limit. Ang local instance ay nangangailangan lamang ng isang container sa server na binabayaran mo na, at hindi lumalabas dito ang mga query. Kung nagkakabit ka ng tools sa isang model, ito rin ang dahilan kung bakit kapaki-pakinabang ang pagpapatakbo ng MCP servers sa isang VPS, kung saan karaniwang unang idinadagdag ang search tool.

Dalawang panuntunan para sa paggamit ng API. Panatilihing private ang instance. I-bind ang API side sa loopback address o sa private network, at payagan lamang ang sarili mong hosts na maka-access dito. Pagkatapos, dahan-dahan itong i-query. Ipinapasa ng SearXNG ang request mo sa mga tunay na search engine. Kaya kung nagpapatakbo ang script ng 100 query bawat segundo, hinihiling nito sa Google na i-block ang server mo.

Ang limiter at ang mga pagbabago para sa public instance

Ang limiter ang depensa ng SearXNG laban sa mga bot. Sinusubaybayan nito ang mga request header, address, at rate ng mga request, at ibinabagsak nito ang traffic na mukhang awtomatiko. Kailangan nito ng Valkey para iimbak ang state na iyon, kaya kasama ito sa Compose file.

Para sa private instance, panatilihing limiter: false. Awtomatikong traffic ang sarili mong mga script, kaya iba-block ng limiter ang mismong mga JSON call na ginawa mo para sa instance. Sa halip, trabaho ng reverse proxy ang access control: isang allow at deny na pares sa nginx location, HTTP basic authentication, o firewall na tumatanggap lamang ng koneksyon mula sa iba mo pang server.

Kung ilalabas mo ang instance para magamit ng ibang tao, i-on ang dalawang switch.

server:
  limiter: true
  public_instance: true

Makikita ang mas detalyadong control sa core-config/limiter.toml, na binabasa ng container mula sa /etc/searxng/limiter.toml. Isulat lamang ang mga key na gusto mong baguhin. Kung nasa likod ito ng proxy, kailangan mong ideklara ang proxy. Kung hindi, ituturing ng limiter na ang address ng nginx mo ang iisang abusadong client.

[botdetection]
trusted_proxies = [
  '127.0.0.0/8',
  '::1',
]

[botdetection.ip_limit]
link_token = true

Ginagawa ng link_token = true na maglabas ang SearXNG ng token na makukuha lamang ng isang lehitimong browser session. Pinipigilan nito ang karamihan sa mga simpleng scraper. Asahan mong dadagsa ang mga ito sa loob ng ilang araw kapag public ang instance. Asahan din ang mga error mula sa mga search engine, dahil habang mas maraming traffic ang ipinapasa mo, mas maagang magsisimulang magbalik ang mga upstream engine ng CAPTCHA sa address ng server mo. Tuloy-tuloy na gawain ang pagpapatakbo ng public SearXNG instance. Hindi ito ganito para sa private instance, kaya kabilang ito sa karamihan ng maiikling listahan ng mga sulit i-self-host sa 2026.

Bakit walang ibinabalik ang mga search

Buksan ang /stats sa iyong instance. Inililista nito ang bawat engine kasama ang error rate at response time nito. Ito ang unang dapat tingnan kapag kakaunti ang mga resulta.

Ang engine na may mga error na "Access denied" o "CAPTCHA" ay nag-block sa address ng iyong server. Karaniwan ito sa mga address na nasa data centre ranges, dahil ipinapalagay ng mga search engine na pagmamay-ari ang mga ito ng mga scraper. Pagkatapos, sinususpinde ng SearXNG ang engine na nagfa-fail sa loob ng isang yugto ng panahon sa halip na ulitin ang request. Dahil dito, tahimik na nawawala sa mga resulta ang isang naka-block na engine. I-disable ito sa settings.yml o tanggapin ang pagkawala nito. Sasagot pa rin ang natitirang mga engine.

Kung sabay-sabay na nagfa-fail ang lahat ng engine, walang gumaganang outbound name resolution ang container o wala itong route papunta sa internet. I-test ito mula sa loob ng container.

docker compose exec core wget -qO- https://duckduckgo.com > /dev/null && echo ok

FAQ

Ginagawa bang anonymous ng SearXNG ang mga paghahanap ko?

Itinatago nito ang iyong pagkakakilanlan sa mga engine na tinatanong nito, dahil server mo ang nakikita nilang gumagawa ng request sa halip na browser mo. Hindi nito itinatago ang query mula sa server mo, at hindi rin nito itinatago ang server mo mula sa mga engine. Sa isang instance na iisang user lang ang gumagamit, lahat ng traffic mula sa address na iyon ay sa iyo, kaya nagiging identifier ang address mismo. Pinoprotektahan ng TLS certificate ang traffic sa pagitan ng browser mo at ng instance mo.

Bakit nagbabalik ng 403 Forbidden ang isang JSON request?

May 2 sanhi, at parehong configuration ang pinagmumulan. Maaaring nawawala ang json sa listahan ng formats sa ilalim ng search: sa settings.yml, na siyang default na estado, o naka-on ang limiter at nauri nito ang script mo bilang bot. Idagdag muna ang format, mag-restart gamit ang docker compose restart core, pagkatapos ay subukan muli. Kung mabigo pa rin, itakda ang limiter: false at kontrolin ang access sa reverse proxy sa halip.

Kailangan ko ba ang Valkey container kung naka-off ang limiter?

Panatilihin itong tumatakbo. Gumagana ang SearXNG kahit wala ito, ngunit hindi maaaring i-on ang limiter sa hinaharap nang wala ito, at nag-iimbak din ito ng iba pang panandaliang state. Maliit ang container at cached data lang ang iniimbak nito, kaya kaunti lang ang matitipid sa pagtanggal nito at mawawala sa iyo ang opsyong gamitin ito.

Paano ko ia-update ang SearXNG?

Patakbuhin ang docker compose pull at pagkatapos ang docker compose up -d sa /opt/searxng. Muling ginagawa ng Compose ang anumang container na nagbago ang image at hindi nito ginagalaw ang core-config/ directory mo, kaya nananatili ang settings.yml. Dahil pinagsasama ng use_default_settings: true ang iyong mga key sa mga default na inilabas kasama ng software, dumarating ang mga option na idinagdag upstream na may angkop na values sa halip na masira ang file.

Maaari bang magbahagi ng isang instance ang ilang tao?

Oo, at ito ang sitwasyong dapat mong i-on ang limiter at itakda ang public_instance: true. Naka-store ang mga preference sa sariling browser ng bawat bisita, kaya walang accounts na kailangang pamahalaan. I-monitor ang /stats sa loob ng isang linggo pagkatapos itong buksan sa ibang user, dahil magsisimulang tanggihan ng upstream engines ang server mo bago mo pa mapansin na may nawawalang resulta.