วิธีติดตั้ง SearXNG บน VPS ด้วย Docker Compose

สิ่งที่คุณกำลังสร้าง

การทำ self-host SearXNG ช่วยให้คุณมีเครื่องมือค้นหาข้อมูลส่วนตัวที่ทำงานบนเซิร์ฟเวอร์ของคุณเอง SearXNG เป็น metasearch engine ที่จะรับคำค้นหาของคุณไปสอบถามยังเครื่องมือค้นหาอื่น เช่น Google, Bing, DuckDuckGo และ Wikipedia จากนั้นจึงรวมผลลัพธ์ที่ได้มาแสดงในหน้าเดียว ระบบไม่มีการสร้างโปรไฟล์และไม่มีการตั้งค่า tracking cookie เนื่องจากเครื่องเดียวที่เก็บข้อมูลคำค้นหาของคุณคือเครื่องของคุณเอง หากคุณเคยพบคำแนะนำเก่าๆ สำหรับโปรเจกต์ที่เรียกว่า Searx เฉยๆ นั่นคือโปรเจกต์ต้นทางที่ SearXNG แยกตัวออกมา ซึ่งโปรเจกต์ดังกล่าวไม่มีการดูแลรักษามาตั้งแต่เดือนกันยายน 2023 โดย repository ของโปรเจกต์ได้ประกาศว่า Searx ไม่ได้รับการดูแลรักษาอีกต่อไป และการ commit เพียงครั้งเดียวหลังจากนั้นซึ่งเป็นบันทึกเอกสารในเดือนพฤษภาคม 2026 ก็ไม่ได้เปลี่ยนแปลงสถานะดังกล่าว ดังนั้น โปรดตรวจสอบสถานะของทั้งสองโปรเจกต์ก่อนที่คุณจะปฏิบัติตามคำแนะนำใดๆ

stack ของระบบนี้มีขนาดเล็ก ประกอบด้วย container สองตัว, ไฟล์ตั้งค่าหนึ่งไฟล์ และ reverse proxy หนึ่งตัว มันสามารถทำงานร่วมกับ VPS ขนาดเล็กได้อย่างราบรื่น ซึ่งไม่ใช่ทุกบริการแบบ self-hosted ที่จะทำได้ เช่น คลังรูปภาพที่เปรียบเทียบไว้ใน PhotoPrism กับ Immich ซึ่งกำหนดการใช้ RAM ขั้นต่ำไว้ที่ตัว indexer ไม่ใช่ตัว web app การตัดสินใจที่สำคัญคือ instance ของคุณจะเป็นแบบส่วนตัว (private) ซึ่งหมายถึงมีเพียงคุณและสคริปต์ของคุณเท่านั้นที่เข้าถึงได้ หรือเป็นแบบสาธารณะ (public) ซึ่งหมายถึงใครก็ตามบนอินเทอร์เน็ตสามารถเข้ามาค้นหาข้อมูลได้ ทางเลือกนี้จะส่งผลต่อการตั้งค่าความปลอดภัย ดังนั้นควรตัดสินใจให้แน่ชัดก่อนเริ่มพิมพ์คำสั่งใดๆ โดยค่าเริ่มต้นที่แนะนำคือแบบส่วนตัว

เหตุผลประการที่สองในการรัน instance นี้คือ SearXNG สามารถสื่อสารด้วย JSON ได้ ดังนั้นสคริปต์หรือ AI agent ใดๆ ที่คุณเขียนขึ้นจะมี search API เป็นของตัวเอง โดยไม่ต้องใช้ key, ไม่มีการเรียกเก็บเงินต่อการค้นหา และไม่มีอีเมลแจ้งเตือนเรื่องโควตาการใช้งาน

การติดตั้ง SearXNG ด้วย Docker Compose

โปรเจกต์นี้มีการเผยแพร่ container image และไฟล์ Compose ให้ดึงข้อมูลทั้งสองส่วนลงบนเซิร์ฟเวอร์ Ubuntu 24.04 ที่ติดตั้ง Docker Engine และปลั๊กอิน Compose ไว้เรียบร้อยแล้ว หากคุณยังไม่คุ้นเคยกับ Docker ให้เริ่มต้นที่ พื้นฐาน Docker Compose บน VPS แล้วจึงกลับมาดำเนินการต่อ

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

ไฟล์ Compose กำหนดบริการไว้สองรายการ core คือตัว SearXNG เอง และ valkey คือที่เก็บข้อมูลในหน่วยความจำที่ใช้สำหรับการจำกัดอัตราการเข้าถึง (rate limiting) และสถานะชั่วคราว โดยจะทำการ mount ./core-config/ ไปยัง /etc/searxng/ ภายใน container ดังนั้นทุกการตั้งค่าของคุณจะถูกเก็บไว้ในไดเรกทอรีนั้นบนเครื่องโฮสต์

จากนั้นให้แก้ไขไฟล์ .env ทุกบรรทัดในตัวอย่างที่ให้มาจะถูกใส่เครื่องหมายคอมเมนต์ไว้ ซึ่งเป็นสาเหตุที่ทำให้ container เริ่มทำงานที่พอร์ต 8080 บนทุกแอดเดรส ให้เอาเครื่องหมายคอมเมนต์ออกและตั้งค่าสามรายการนี้

SEARXNG_VERSION=latest
SEARXNG_HOST=127.0.0.1
SEARXNG_PORT=8080

SEARXNG_HOST=127.0.0.1 เป็นส่วนที่สำคัญ โดยจะทำให้พอร์ตที่เปิดใช้งานเป็น 127.0.0.1:8080:8080 แทนที่จะเป็น 8080:8080 แบบปกติ ซึ่ง Docker จะเปิดใช้งานบนทุกแอดเดรส ดังนั้น container จะตอบสนองเฉพาะบน loopback address เท่านั้น และอินเทอร์เน็ตจะไม่สามารถเข้าถึงได้โดยตรง หากข้ามขั้นตอนนี้ไป container จะถูกเปิดเผยทันทีที่เริ่มทำงาน เนื่องจากพอร์ตที่เผยแพร่โดย Docker จะถูกแทรกไว้ก่อนกฎ firewall ของคุณ ควรศึกษาเรื่องนี้ให้ละเอียด: พอร์ต Docker ที่เผยแพร่จะข้าม ufw

SEARXNG_VERSION=latest สามารถใช้งานได้ในระหว่างการเรียนรู้ แต่สำหรับเซิร์ฟเวอร์ที่คุณให้ความสำคัญ ควรระบุเวอร์ชัน (pin) ของ tag ไว้ ณ เดือนตุลาคม 2026 tag ของรุ่นจะอ้างอิงตามวันที่ในรูปแบบ 2026.10.4-d48c4b555 ดังนั้นการระบุเวอร์ชันไว้จะทำให้การอัปเกรดเกิดขึ้นเมื่อคุณตัดสินใจ ไม่ใช่เมื่อมีการเปลี่ยนแปลงใน registry วินัยแบบเดียวกันนี้ยังใช้ได้กับบริการอื่น ๆ ที่ทำงานต่อเนื่องบนเครื่อง ซึ่งเป็นเหตุผลว่าทำไม การทำ self-hosted RustDesk relay จึงต้องระบุ tag ของ image ไว้เช่นกัน เพราะการอัปเกรดอัตโนมัติของบริการรีโมทเข้าถึงเครื่องอาจสร้างปัญหาในเวลาที่ไม่เหมาะสมที่สุดได้

settings.yml: ส่วนประกอบที่สำคัญ

สร้าง core-config/settings.yml ก่อนการเริ่มทำงานครั้งแรก use_default_settings: true จะสั่งให้ SearXNG โหลดค่าเริ่มต้นที่มากับซอฟต์แวร์ แล้วจึงนำเฉพาะค่าที่คุณระบุไปทับ ทำให้ไฟล์ของคุณสั้นและยังคงใช้งานได้แม้มีการอัปเกรดที่เพิ่มตัวเลือกใหม่เข้ามา

สร้าง secret ก่อน เนื่องจากค่านี้ต้องนำไปใส่ในไฟล์โดยตรง

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

secret_key ใช้สำหรับลงนามข้อมูล session และ token ค่าเริ่มต้นที่มากับซอฟต์แวร์คือข้อความ ultrasecretkey หากปล่อยไว้ ใครก็ตามที่ทราบค่าเริ่มต้นนี้จะสามารถปลอมแปลง token ดังกล่าวได้ ให้เปลี่ยนค่านี้เพียงครั้งเดียวแล้วไม่ต้องแก้ไขอีก เพราะการเปลี่ยนภายหลังจะทำให้การตั้งค่าที่บันทึกไว้ทั้งหมดสูญหาย

base_url ต้องเป็นที่อยู่ HTTPS แบบสาธารณะ พร้อมเครื่องหมาย slash ปิดท้าย นี่คือสิ่งที่ SearXNG จะเขียนลงในลิงก์ที่แสดงผล หากปล่อยให้ชี้ไปที่ localhost ลิงก์ "หน้าถัดไป" ในเบราว์เซอร์ของผู้ใช้จะชี้กลับมาที่เครื่องของผู้ใช้เองและใช้งานไม่ได้

formats เป็นตัวกำหนดประเภทผลลัพธ์ที่ web endpoint จะสร้างออกมา json ไม่ได้อยู่ในรายการเริ่มต้น ดังนั้นคำขอแบบ JSON จะได้รับสถานะ 403 จนกว่าคุณจะเพิ่มเข้าไป image_proxy: true จะทำหน้าที่ส่งผ่านรูปภาพตัวอย่าง (thumbnails) ของผลลัพธ์ผ่านเซิร์ฟเวอร์ของคุณ เพื่อไม่ให้เว็บไซต์ที่เป็นเจ้าของรูปภาพเหล่านั้นเห็นที่อยู่ IP ของผู้เข้าชมของคุณ

valkey.url ใช้ hostname เป็น valkey เนื่องจากเป็นชื่อบริการในไฟล์ Compose และ Compose จะนำ container ทั้งสองมาไว้บนเครือข่ายเดียวกันซึ่งชื่อบริการจะสามารถ resolve ถึงกันได้ หากชี้ไปที่ localhost ตัว limiter จะทำงานล้มเหลว เพราะภายใน container core นั้น localhost หมายถึงตัว container เอง

เนื่องจาก secret ถูกเก็บไว้ในไฟล์ข้อความธรรมดา คุณควรป้องกันไดเรกทอรีที่เก็บไฟล์นี้ด้วย chmod 750 /opt/searxng จะช่วยป้องกันไม่ให้ผู้ใช้รายอื่นบนโฮสต์เข้าถึงได้ คุณยังสามารถจำกัดสิทธิ์ core-config/settings.yml ให้เป็นโหมด 600 ได้โดยไม่ส่งผลกระทบใดๆ เนื่องจาก entrypoint ของ container อย่างเป็นทางการจะเริ่มทำงานในฐานะ root และเมื่อปล่อย FORCE_OWNERSHIP ไว้ที่ค่าเริ่มต้นคือ true ระบบจะส่งมอบไดเรกทอรี config ที่ mount ไว้ให้กับผู้ใช้ searxng ภายใน container ก่อนที่ SearXNG จะเริ่มทำงาน ดังนั้นไฟล์จะยังคงอ่านได้ตามปกติ ผลข้างเคียงที่เกิดขึ้นบนโฮสต์คือ ขั้นตอนนี้จะเปลี่ยนเจ้าของไฟล์ core-config/ ให้เป็น user ID ของ container ดังนั้นคุณอาจต้องใช้ sudo ในการแก้ไขไฟล์หลังจากนั้น

เริ่มการทำงานของ stack และตรวจสอบสถานะ

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

docker compose ps ควรแสดงสถานะของทั้งสอง container เป็น running และ curl ควรตอบกลับเป็น HTTP/1.1 200 OK หากไม่มีการตอบกลับ ให้ตรวจสอบ docker compose logs core เนื่องจากข้อผิดพลาดของ YAML ใน settings.yml จะปรากฏที่นั่นในรูปแบบของ parse error พร้อมระบุบรรทัดที่เกิดปัญหา

วางไว้หลัง nginx พร้อม TLS

คอนเทนเนอร์จะรับฟังเฉพาะบน loopback เท่านั้น ดังนั้น nginx จึงเป็นตัวที่ทำให้เข้าถึงบริการได้ และยังเป็นตัวที่เพิ่มความปลอดภัยในระดับ transport layer (TLS) ให้ด้วย ให้เขียน /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

nginx -t จะแสดงผล syntax is ok และ test is successful ก่อนที่คุณจะโหลดการตั้งค่าใหม่ Certbot จะเขียนไฟล์เดิมซ้ำเพื่อเปิดรับการเชื่อมต่อที่พอร์ต 443 พร้อมใบรับรอง และเพิ่มการเปลี่ยนเส้นทางจากพอร์ต 80 โดยระเบียน DNS สำหรับ search.example.com จะต้องชี้มาที่เซิร์ฟเวอร์นี้แล้ว เนื่องจากผู้ออกใบรับรองจะตรวจสอบความเป็นเจ้าของโดยการดึงไฟล์ผ่าน HTTP คำแนะนำฉบับเต็มรวมถึงการต่ออายุใบรับรองอยู่ใน คู่มือการใช้งาน Certbot และ nginx สำหรับ Ubuntu 24.04

ส่วนหัวสำหรับการส่งต่อ (forwarding headers) ทั้งสองรายการไม่ใช่สิ่งที่ใส่ไว้เพื่อความสวยงาม หากไม่มี X-Forwarded-For และ X-Real-IP ทุกคำขอที่ส่งมายัง SearXNG จะแสดงเป็นที่อยู่ของพร็อกซี ทำให้ระบบจำกัดอัตราการใช้งาน (rate limiter) มองเห็นว่ามีไคลเอนต์เพียงรายเดียวที่สร้างทราฟฟิกทั้งหมด และไม่สามารถแยกแยะผู้ใช้งานแต่ละรายออกจากกันได้

เหตุผลที่สคริปต์และเอเจนต์ต้องการ JSON search API

ด้วย json ใน formats ทำให้ endpoint เดียวกันที่แสดงผลหน้าเว็บสามารถส่งคืนข้อมูลที่มีโครงสร้างได้

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

คุณจะได้รับออบเจกต์ที่มีอาร์เรย์ results โดยแต่ละรายการจะประกอบด้วย url, title, content และเอนจินที่ให้ผลลัพธ์นั้น พร้อมด้วย answers, infoboxes และ suggestions ข้อมูลเหล่านี้เพียงพอสำหรับการป้อนเข้าสู่ระบบสรุปผล, ระบบตรวจสอบลิงก์ หรือวงจรการวิจัย การส่งผลลัพธ์เหล่านี้ไปยังโมเดลภาษาเป็นขั้นตอนที่ใหญ่กว่าที่เห็น เนื่องจากผลการค้นหาเป็นข้อความที่ไม่น่าเชื่อถือและอาจมีคำสั่งแฝงอยู่ ซึ่งเป็นสิ่งที่ การชี้ AI agent ไปยัง instance ของ SearXNG อธิบายไว้อย่างละเอียด

เรื่องนี้มีความสำคัญสำหรับทุกสิ่งที่อยู่ในรูปแบบของเอเจนต์ โมเดลภาษามีจุดตัดของข้อมูลที่ใช้ฝึกสอน ดังนั้นจึงจำเป็นต้องมีการค้นหาแบบสดเพื่อตอบคำถามเกี่ยวกับปัจจุบัน ในขณะที่ API การค้นหาเชิงพาณิชย์มีการคิดค่าบริการต่อการสืบค้นและจำกัดอัตราการใช้งานอย่างเข้มงวด การรัน instance ในเครื่องใช้เพียงคอนเทนเนอร์เดียวบนเซิร์ฟเวอร์ที่คุณจ่ายเงินอยู่แล้ว และการสืบค้นจะไม่ถูกส่งออกไปภายนอก หากคุณกำลังเชื่อมต่อเครื่องมือเข้ากับโมเดล เหตุผลเดียวกันนี้ผลักดันให้เกิด การรัน MCP servers บน VPS ซึ่งเครื่องมือค้นหามักเป็นสิ่งแรกที่ผู้คนเลือกเพิ่มเข้าไป

กฎสองข้อสำหรับการใช้ API คือ ให้เก็บ instance ไว้เป็นส่วนตัว โดยผูกฝั่ง API ไว้กับ loopback address หรือเครือข่ายส่วนตัว และอนุญาตให้เฉพาะโฮสต์ของคุณเข้าถึงได้เท่านั้น ซึ่งเป็นการจัดการแบบเดียวกับที่ ตัวติดตามตำแหน่งแบบ self-hosted ต้องการสำหรับ endpoint ที่โทรศัพท์ของคุณรายงานตำแหน่ง จากนั้นให้สืบค้นอย่างระมัดระวัง เนื่องจาก SearXNG จะส่งคำขอของคุณต่อไปยังเอนจินการค้นหาจริง ดังนั้นสคริปต์ที่รันการสืบค้นร้อยครั้งต่อวินาทีจึงเท่ากับเป็นการขอให้ Google บล็อกเซิร์ฟเวอร์ของคุณ

ตัวจำกัดอัตราการเข้าถึงและการเปลี่ยนแปลงสำหรับอินสแตนซ์สาธารณะ

ตัวจำกัดอัตราการเข้าถึง (limiter) คือระบบป้องกันบอทของ SearXNG โดยจะคอยตรวจสอบ header ของคำขอ, ที่อยู่ IP และอัตราการส่งคำขอ แล้วทำการตัดทิ้งหากพบว่าทราฟฟิกนั้นมีลักษณะเป็นระบบอัตโนมัติ ระบบนี้จำเป็นต้องใช้ Valkey ในการเก็บสถานะดังกล่าว ซึ่งเป็นเหตุผลว่าทำไมไฟล์ Compose จึงรวมบริการนี้มาให้ด้วย

สำหรับอินสแตนซ์ส่วนตัว ให้คงค่า limiter: false ไว้ เนื่องจากสคริปต์ของคุณถือเป็นทราฟฟิกอัตโนมัติโดยนิยาม ตัวจำกัดนี้จึงอาจบล็อกการเรียกใช้งาน JSON ที่คุณสร้างอินสแตนซ์นี้ขึ้นมาเพื่อใช้งานโดยเฉพาะ การควบคุมการเข้าถึงควรเป็นหน้าที่ของ reverse proxy แทน เช่น การใช้คู่ของ allow และ deny ในไฟล์ location ของ nginx, การใช้ HTTP basic authentication หรือการใช้ไฟร์วอลล์ที่อนุญาตเฉพาะเซิร์ฟเวอร์อื่นของคุณเท่านั้น หากคุณต้องการเข้าถึงอินสแตนซ์ส่วนตัวจากแล็ปท็อปที่เปลี่ยนเครือข่ายไปมา การใช้ v3 onion address เป็นอีกทางเลือกหนึ่ง เนื่องจาก Tor จะเชื่อมต่อเข้ากับพอร์ต loopback เดียวกันโดยไม่เปิดเผยสิ่งใดเพิ่มเติมสู่สาธารณะ

หากคุณเปิดให้อินสแตนซ์เป็นสาธารณะสำหรับผู้อื่น ให้เปิดใช้งานสวิตช์ทั้งสองตัว

server:
  limiter: true
  public_instance: true

การควบคุมที่ละเอียดขึ้นจะอยู่ใน core-config/limiter.toml ซึ่งคอนเทนเนอร์จะอ่านค่าที่ /etc/searxng/limiter.toml คุณควรเขียนเฉพาะคีย์ที่ต้องการเปลี่ยนแปลงเท่านั้น หากอยู่หลังพร็อกซี คุณต้องประกาศค่าพร็อกซี มิฉะนั้นตัวจำกัดจะมองว่าที่อยู่ของ nginx ของคุณเป็นไคลเอนต์ที่ละเมิดกฎ

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

[botdetection.ip_limit]
link_token = true

link_token = true จะทำให้ SearXNG ออกโทเค็นที่เฉพาะเซสชันของเบราว์เซอร์จริงเท่านั้นที่จะดึงข้อมูลได้ ซึ่งจะช่วยหยุดยั้งโปรแกรมดึงข้อมูล (scraper) ส่วนใหญ่ได้ อินสแตนซ์สาธารณะมักจะถูกโจมตีภายในไม่กี่วัน และคาดว่าจะพบข้อผิดพลาดจากเอนจินค้นหาด้วย เพราะยิ่งคุณส่งทราฟฟิกไปมากเท่าไร เอนจินต้นทางก็จะเริ่มส่ง CAPTCHA กลับมายังที่อยู่เซิร์ฟเวอร์ของคุณเร็วขึ้นเท่านั้น การดูแลอินสแตนซ์ SearXNG สาธารณะจึงเป็นงานที่ต้องทำอย่างต่อเนื่อง ในขณะที่อินสแตนซ์ส่วนตัวไม่ต้องทำเช่นนั้น ซึ่งเป็นเหตุผลว่าทำไมมันจึงติดอันดับ สิ่งที่ควรทำ self-hosting ในปี 2026 ในรายการส่วนใหญ่ ไม่ใช่ทุกรายการในลิสต์จะเป็นโครงสร้างพื้นฐานเสมอไป เช่น การสร้างคลัง Jellyfin ให้เหมือนร้านเช่าวิดีโอในยุค 90 ก็เป็นเพียงคอนเทนเนอร์ตัวเดียวที่อยู่หลังบล็อก nginx เดียวกัน โดยเน้นไปที่การพักผ่อนยามเย็นมากกว่าการทำงาน

เหตุใดการค้นหาจึงไม่แสดงผลลัพธ์

เปิด /stats บนอินสแตนซ์ของคุณ หน้าจอนี้จะแสดงรายการเอนจินทั้งหมดพร้อมอัตราข้อผิดพลาดและเวลาในการตอบสนอง ซึ่งเป็นจุดแรกที่ควรตรวจสอบเมื่อผลลัพธ์ที่ได้ดูน้อยผิดปกติ

เอนจินที่แสดงข้อผิดพลาด "Access denied" หรือ "CAPTCHA" หมายความว่าเอนจินนั้นได้บล็อกที่อยู่เซิร์ฟเวอร์ของคุณแล้ว กรณีนี้พบได้บ่อยสำหรับที่อยู่ IP ในช่วงของศูนย์ข้อมูล เนื่องจากเครื่องมือค้นหามักสันนิษฐานว่าที่อยู่เหล่านั้นเป็นของโปรแกรมดึงข้อมูล (scrapers) จากนั้น SearXNG จะระงับการใช้งานเอนจินที่มีปัญหาชั่วคราวแทนที่จะพยายามเชื่อมต่อใหม่ ทำให้เอนจินที่ถูกบล็อกหายไปจากผลลัพธ์ของคุณโดยเงียบๆ คุณสามารถปิดการใช้งานเอนจินนั้นใน settings.yml หรือยอมรับการสูญเสียผลลัพธ์จากแหล่งนั้น อย่างไรก็ตาม นี่ไม่ใช่ทางเลือกเดียวที่มี เพราะ การบล็อก CAPTCHA บางประเภทมีวิธีแก้ไขที่คงอยู่ถาวรแม้หลังรีสตาร์ท เอนจินที่เหลือยังคงทำงานได้ตามปกติ ส่วนข้อผิดพลาด 429 เป็นกรณีที่กำกวม เนื่องจากอาจเกิดจากตัวจำกัดอัตรา (limiter) ของคุณเอง หรือเกิดจากเอนจินต้นทางปฏิเสธเซิร์ฟเวอร์ของคุณ และ บรรทัดใน log จะระบุให้คุณทราบว่าคุณกำลังเผชิญกับกรณีใด ก่อนที่คุณจะเริ่มเปลี่ยนการตั้งค่า

หากเอนจินทั้งหมดล้มเหลวพร้อมกัน แสดงว่าคอนเทนเนอร์ไม่มีการแก้ไขชื่อโฮสต์ (name resolution) ขาออกที่ใช้งานได้ หรือไม่มีเส้นทางเชื่อมต่อไปยังอินเทอร์เน็ต ให้ทดสอบการเชื่อมต่อจากภายในคอนเทนเนอร์

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

ไม่มีระบบใดบนเครื่องที่จะแจ้งเตือนคุณเมื่อการตรวจสอบนี้เริ่มล้มเหลว ดังนั้นควรเรียกใช้การตรวจสอบผ่าน cron และตั้งค่าให้การแจ้งเตือนความล้มเหลว ส่งไปยังโทรศัพท์ของคุณผ่านเซิร์ฟเวอร์ ntfy ของคุณเอง แทนที่จะรอจนกว่าคุณจะสังเกตเห็นว่าผลลัพธ์การค้นหาเริ่มน้อยลง

FAQ

SearXNG ช่วยให้การค้นหาของฉันไม่ระบุตัวตนหรือไม่?

มันช่วยซ่อนตัวตนของคุณจากเครื่องมือค้นหาที่คุณส่งคำขอไป เพราะเครื่องมือเหล่านั้นจะเห็นว่าเซิร์ฟเวอร์ของคุณเป็นผู้ส่งคำขอแทนที่จะเป็นเบราว์เซอร์ของคุณ อย่างไรก็ตาม มันไม่ได้ซ่อนคำค้นหาจากเซิร์ฟเวอร์ของคุณ และไม่ได้ซ่อนเซิร์ฟเวอร์ของคุณจากเครื่องมือเหล่านั้น ในกรณีที่เป็น instance สำหรับผู้ใช้คนเดียว ทราฟฟิกทั้งหมดจากที่อยู่นั้นคือของคุณ ดังนั้นที่อยู่ดังกล่าวจึงกลายเป็นตัวระบุตัวตน ทราฟฟิกระหว่างเบราว์เซอร์ของคุณกับ instance ของคุณจะถูกป้องกันด้วย TLS certificate สำหรับผลกระทบต่อ ISP, ผู้ดูแล public instance และตัวเครื่องมือค้นหาเอง สามารถอ่านรายละเอียดเพิ่มเติมได้ที่ สิ่งที่ SearXNG ซ่อนไว้จริงๆ

ทำไมคำขอ JSON ถึงส่งกลับค่า 403 Forbidden?

มีสองสาเหตุและทั้งคู่เกี่ยวข้องกับการตั้งค่า สาเหตุแรกคือ json หายไปจากรายการ formats ภายใต้ search: ในไฟล์ settings.yml ซึ่งเป็นค่าเริ่มต้น หรือสาเหตุที่สองคือตัวจำกัด (limiter) เปิดใช้งานอยู่และระบุว่าสคริปต์ของคุณเป็นบอท ให้เพิ่มรูปแบบ (format) ดังกล่าวเข้าไปก่อน จากนั้นรีสตาร์ทด้วย docker compose restart core แล้วลองใหม่อีกครั้ง หากยังคงล้มเหลว ให้ตั้งค่า limiter: false แล้วควบคุมการเข้าถึงที่ reverse proxy แทน

ฉันจำเป็นต้องใช้คอนเทนเนอร์ Valkey หรือไม่หากปิดตัวจำกัดไว้?

ควรปล่อยให้มันทำงานต่อไป SearXNG สามารถทำงานได้โดยไม่มีมัน แต่คุณจะไม่สามารถเปิดใช้งานตัวจำกัดในภายหลังได้หากไม่มี Valkey และมันยังทำหน้าที่เก็บสถานะระยะสั้นอื่นๆ อีกด้วย คอนเทนเนอร์นี้มีขนาดเล็กและเก็บเฉพาะข้อมูลที่แคชไว้เท่านั้น ดังนั้นการลบออกจึงช่วยประหยัดพื้นที่ได้เพียงเล็กน้อยแต่ทำให้คุณเสียตัวเลือกในการใช้งานไป

ฉันจะอัปเดต SearXNG ได้อย่างไร?

รันคำสั่ง docker compose pull ตามด้วย docker compose up -d ใน /opt/searxng ตัว Compose จะสร้างคอนเทนเนอร์ใหม่หาก image มีการเปลี่ยนแปลง โดยจะปล่อยให้ไดเรกทอรี core-config/ ของคุณคงเดิม ดังนั้น settings.yml จึงไม่ได้รับผลกระทบ เนื่องจาก use_default_settings: true จะรวมคีย์ของคุณเข้ากับค่าเริ่มต้นที่มากับซอฟต์แวร์ ตัวเลือกที่เพิ่มเข้ามาจากต้นทางจึงมาพร้อมกับค่าที่เหมาะสมแทนที่จะทำให้ไฟล์เสียหาย

หลายคนสามารถใช้ instance เดียวกันได้หรือไม่?

ได้ และนั่นคือกรณีที่คุณควรเปิดใช้งานตัวจำกัดและตั้งค่า public_instance: true การตั้งค่าต่างๆ จะถูกเก็บไว้ในเบราว์เซอร์ของผู้เข้าชมแต่ละคน ดังนั้นจึงไม่มีบัญชีผู้ใช้ที่ต้องจัดการ ให้คอยตรวจสอบ /stats เป็นเวลาหนึ่งสัปดาห์หลังจากเปิดใช้งาน เพราะเครื่องมือค้นหาต้นทางอาจเริ่มปฏิเสธการเชื่อมต่อจากเซิร์ฟเวอร์ของคุณนานก่อนที่คุณจะสังเกตเห็นว่าผลลัพธ์การค้นหาหายไป