SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-09-05

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

เรียนรู้วิธีติดตั้ง SearXNG บนเซิร์ฟเวอร์ส่วนตัวผ่าน Docker Compose ตั้งแต่การตั้งค่า settings.yml การจำกัดการใช้งาน ไปจนถึงการทำ Nginx TLS และการเรียกใช้ผ่าน JSON API

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

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

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

เหตุผลประการที่สองในการรัน SearXNG คืออินสแตนซ์ของ 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 บนทุก address ให้เอาเครื่องหมายคอมเมนต์ออกและตั้งค่าสามรายการนี้

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 เพื่อให้ container ตอบสนองเฉพาะบน loopback address เท่านั้น และอินเทอร์เน็ตจะไม่สามารถเข้าถึงได้โดยตรง หากข้ามขั้นตอนนี้ไป container จะถูกเปิดเผยทันทีที่เริ่มทำงาน เนื่องจากพอร์ตที่เผยแพร่โดย Docker จะถูกแทรกไว้ก่อนกฎ firewall ของคุณ ควรศึกษาเรื่องนี้ให้ละเอียด: พอร์ต Docker ที่เผยแพร่จะข้าม ufw

SEARXNG_VERSION=latest สามารถใช้งานได้ในระหว่างการเรียนรู้ แต่สำหรับเซิร์ฟเวอร์ที่คุณให้ความสำคัญ ควรระบุเวอร์ชันของ tag ให้ชัดเจน ณ เดือนกรกฎาคม 2026 tag ของรุ่นที่ปล่อยออกมาจะอ้างอิงตามวันที่ เช่น 2026.3.25-541c6c3cb ดังนั้นการระบุ tag ไว้จะทำให้การอัปเกรดเกิดขึ้นเมื่อคุณตัดสินใจเอง ไม่ใช่เมื่อมีการเปลี่ยนแปลงใน 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 เป็นตัวกำหนดประเภทผลลัพธ์ที่ endpoint ของเว็บจะสร้างขึ้น json ไม่ได้อยู่ในรายการเริ่มต้น ดังนั้นคำขอ JSON จะได้รับข้อผิดพลาด 403 จนกว่าคุณจะเพิ่มเข้าไป image_proxy: true จะทำหน้าที่ส่งผ่านรูปภาพตัวอย่าง (thumbnail) ของผลลัพธ์ผ่านเซิร์ฟเวอร์ของคุณ เพื่อไม่ให้เว็บไซต์ที่เป็นเจ้าของรูปภาพเหล่านั้นเห็นที่อยู่ IP ของผู้เข้าชมของคุณ

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

เนื่องจาก secret ถูกเก็บไว้ในไฟล์ข้อความธรรมดา ให้ป้องกันที่ไดเรกทอรีรอบไฟล์แทนการป้องกันตัวไฟล์โดยตรง chmod 750 /opt/searxng จะช่วยป้องกันไม่ให้ผู้ใช้รายอื่นบนโฮสต์เข้าถึงได้ อย่าปรับสิทธิ์ core-config/settings.yml ให้เข้มงวดถึงระดับ 600 เนื่องจาก container ทำงานด้วยผู้ใช้ที่ไม่มีสิทธิ์ (unprivileged user) ของตนเอง และหากไฟล์ที่ SearXNG ต้องอ่านถูกจำกัดสิทธิ์ไว้ จะทำให้ SearXNG ไม่สามารถเริ่มทำงานได้เลย

เริ่มการทำงานของ 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 พร้อมระบุบรรทัดที่เกิดปัญหา

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

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

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

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

กฎสองข้อสำหรับการใช้ API คือ ให้เก็บ instance ไว้เป็นส่วนตัว โดยผูกฝั่ง API ไว้กับ loopback address หรือเครือข่ายส่วนตัวและอนุญาตให้เฉพาะโฮสต์ของคุณเข้าถึงได้เท่านั้น จากนั้นให้สืบค้นข้อมูลอย่างระมัดระวัง เนื่องจาก 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-host ในปี 2026 และไม่ใช่ทุกรายการในลิสต์นั้นจะเป็นโครงสร้างพื้นฐานเสมอไป เช่น การสร้างคลังสื่อ Jellyfin ให้เป็นร้านเช่าวิดีโอสไตล์ยุค 90 ก็ใช้คอนเทนเนอร์ตัวเดียวที่อยู่หลังบล็อก nginx เดียวกัน โดยเน้นไปที่การพักผ่อนยามเย็นมากกว่าการทำงาน

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

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

Engine ที่แสดงข้อผิดพลาด "Access denied" หรือ "CAPTCHA" ได้บล็อก address ของเซิร์ฟเวอร์ของคุณ กรณีนี้พบได้บ่อยกับ address ในช่วงของ data centre เพราะ search engine มักถือว่า address เหล่านั้นเป็นของ scraper จากนั้น SearXNG จะระงับ engine ที่ล้มเหลวไว้ระยะหนึ่งแทนการลองใหม่ ทำให้ engine ที่ถูกบล็อกหายไปจากผลลัพธ์ของคุณโดยไม่แสดงอาการ ปิดใช้งาน engine ดังกล่าวใน settings.yml หรือยอมรับว่าผลลัพธ์จะลดลง แต่สองทางเลือกนี้ไม่ใช่ทางเลือกทั้งหมด เพราะ CAPTCHA บางกรณีมีวิธีแก้ที่ยังคงอยู่หลัง restart Engine ที่เหลือยังคงตอบกลับตามปกติ ส่วนรหัส 429 เป็นกรณีที่ระบุสาเหตุได้ไม่ชัดเจน เพราะอาจเกิดจาก limiter ของคุณเอง หรือเกิดจาก upstream engine ที่ปฏิเสธเซิร์ฟเวอร์ของคุณ และ บรรทัดใน log จะระบุว่ากำลังพบกรณีใดจากสองกรณีนี้ ก่อนที่คุณจะเริ่มเปลี่ยนการตั้งค่า

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

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

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

FAQ

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

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

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

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

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

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

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

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

หลายคนสามารถใช้งานอินสแตนซ์เดียวกันได้หรือไม่?

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