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

SearXNG ปลอดภัยไหม? เจาะลึกความเป็นส่วนตัวที่แท้จริง

SearXNG ช่วยซ่อน IP จากเครื่องมือค้นหาด้วยการใช้ IP ของเซิร์ฟเวอร์แทน แต่ผู้ดูแล public instance ยังเห็นคำค้นหาของคุณได้ เรียนรู้ความเสี่ยงจริงและวิธีใช้งานให้ปลอดภัย

SearXNG ปลอดภัยหรือไม่? คำตอบโดยสรุป

SearXNG มีความปลอดภัยในด้านหนึ่งและไม่ปลอดภัยในอีกด้านหนึ่ง ดังนั้นคำถามที่ว่า "SearXNG ปลอดภัยหรือไม่" จะมีคำตอบก็ต่อเมื่อคุณระบุได้ว่าคุณกำลังหลบซ่อนจากใคร SearXNG เป็น metasearch engine ที่รับคำค้นหาของคุณ ส่งต่อไปยัง Google, Bing, DuckDuckGo และเครื่องมือค้นหาอื่นๆ ที่คุณเปิดใช้งาน จากนั้นจึงรวมผลลัพธ์ที่ได้มาไว้ในหน้าเดียว โดยที่เครื่องมือค้นหาเหล่านั้นจะเห็นตัว instance และตัว instance จะเห็นคุณ

บน public instance ที่ดำเนินการโดยบุคคลอื่น บุคคลนั้นจะได้รับทุกคำค้นหาที่คุณพิมพ์ในรูปแบบข้อความธรรมดา (plain text) และไม่มีข้อมูลใดในหน้า about ของพวกเขาที่จะพิสูจน์ได้ว่าพวกเขาทำอย่างไรกับข้อมูลเหล่านั้น แต่หากคุณรันบนเซิร์ฟเวอร์ของคุณเอง upstream engines จะเห็นที่อยู่ของเซิร์ฟเวอร์คุณแทนที่จะเป็นที่อยู่บ้านของคุณ การสลับที่อยู่นี้คือหัวใจสำคัญของความเป็นส่วนตัวทั้งหมด และมันจะมีค่าเท่ากับความปลอดภัยของเซิร์ฟเวอร์ที่คุณใช้งานอยู่เท่านั้น

ไม่มีส่วนใดในกระบวนการนี้ที่ช่วยซ่อนการค้นหาของคุณจากเครือข่ายของคุณเอง ผู้ให้บริการอินเทอร์เน็ต (ISP) ของคุณยังคงเห็นการเชื่อมต่อที่ไปยัง instance นั้น และ DNS (domain name system) resolver ของคุณก็ยังคงเห็น hostname อยู่ โปรดรักษาขอบเขตนี้ไว้ในใจในขณะที่คุณอ่านเนื้อหาส่วนที่เหลือ

สิ่งที่ SearXNG เปลี่ยนแปลงเกี่ยวกับคำขอค้นหา

เมื่อค้นหาผ่าน Google โดยตรง Google จะได้รับ IP address, cookies, User-Agent header และหน้าเว็บที่คุณเข้ามาก่อนหน้า ข้อมูลทั้งหมดนี้จะถูกผูกเข้ากับโปรไฟล์ที่คงอยู่ยาวนานกว่าเซสชันการใช้งาน SearXNG เข้ามาทำหน้าที่เป็นตัวกลาง เอกสารประกอบของ SearXNG อธิบายการทำงานหลักสองประการไว้ว่า "การลบข้อมูลส่วนตัวออกจากคำขอที่ส่งไปยังบริการค้นหา" และ "การสร้างโปรไฟล์เบราว์เซอร์แบบสุ่มสำหรับทุกคำขอ" โดย cookies ของคุณจะไม่ถูกส่งต่อไปยังเครื่องมือค้นหาใดๆ และการตั้งค่าความชอบของคุณจะถูกเก็บไว้ในเบราว์เซอร์ของคุณเองแทนที่จะเก็บไว้ในบัญชีบนเซิร์ฟเวอร์

มีการส่ง response header สองรายการโดยค่าเริ่มต้น ซึ่งทั้งสองรายการมีผลการทำงานจริง:

default_http_headers:
  X-Robots-Tag: noindex, nofollow
  Referrer-Policy: no-referrer

Referrer-Policy: no-referrer หมายความว่าเมื่อคุณคลิกผลการค้นหา เว็บไซต์ปลายทางจะไม่ทราบว่าหน้าผลการค้นหาใดเป็นผู้ส่งคุณไป เนื่องจากเบราว์เซอร์จะละเว้น header Referer ส่วน X-Robots-Tag: noindex, nofollow จะช่วยป้องกันไม่ให้ instance ของคุณและหน้าผลการค้นหาถูกจัดเก็บลงในดัชนีการค้นหา

สิ่งที่ SearXNG ไม่ได้เปลี่ยนแปลงคือตัวคำค้นหาเอง ซึ่งจะมาถึง instance ในรูปแบบที่สมบูรณ์และอ่านได้ เนื่องจาก TLS (transport layer security) ถูกทำ termination ที่จุดนั้น ทุกประเด็นด้านล่างนี้เป็นผลสืบเนื่องมาจากข้อเท็จจริงดังกล่าว

บนอินสแตนซ์สาธารณะ ผู้ดูแลระบบสามารถเห็นทุกคำค้นหา

เอกสารประกอบของโครงการระบุไว้อย่างชัดเจนว่า ผู้ใช้งานอินสแตนซ์สาธารณะ "ต้องเชื่อใจผู้ดูแลระบบของอินสแตนซ์นั้น" และไม่สามารถทราบได้ว่า "คำขอของตนถูกบันทึก รวบรวม และส่งต่อหรือขายให้กับบุคคลที่สามหรือไม่" การกล่าวอ้างเรื่องไม่เก็บ log บนหน้าเว็บไซต์เป็นเพียงคำกล่าวอ้างเท่านั้น จากภายนอกไม่มีวิธีใดที่จะตรวจสอบได้ ดังนั้นจึงเป็นเรื่องของความเชื่อใจเพียงอย่างเดียว อินสแตนซ์สาธารณะบางแห่งยังคงรัน Searx เวอร์ชันดั้งเดิมแทนที่จะเป็น fork นี้ ซึ่งเป็นประเด็นสำคัญเนื่องจาก Searx ไม่มีการ commit โค้ดใดๆ มาตั้งแต่ปี 2023 และซอฟต์แวร์ค้นหาที่ไม่ได้รับการดูแลเป็นอีกสิ่งหนึ่งที่คุณต้องเชื่อใจโดยไม่มีหลักประกัน

การบันทึก log ยังเป็นสิ่งที่เกิดขึ้นได้ง่ายที่สุด เนื่องจากค่าเริ่มต้นที่มากับซอฟต์แวร์จะใส่คำค้นหาของคุณไว้ใน URL:

server:
  method: "GET"

ด้วย GET คำค้นหาจะเดินทางไปในรูปแบบ ?q=... ในบรรทัดคำขอ (request line) Reverse proxy ทั่วไปจะเขียนบรรทัดคำขอดังกล่าวลงใน access log ของตน ดังนั้นคำค้นหาจึงถูกบันทึกไว้โดยที่ไม่มีใครต้องตัดสินใจสั่งให้บันทึก:

203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"

บนอินสแตนซ์ของคุณเอง คุณสามารถตรวจสอบได้ด้วยตนเอง:

sudo tail -n 5 /var/log/nginx/access.log

คำค้นหาของคุณปรากฏอยู่ในนั้นเพราะรูปแบบ log combined ของ nginx เขียนค่า $request ซึ่งเป็นบรรทัดคำขอทั้งหมดรวมถึง query string ไว้ SearXNG ไม่สามารถควบคุมส่วนนี้ได้ การเปลี่ยนอินสแตนซ์ไปใช้ method: "POST" จะย้ายคำค้นหาไปไว้ในส่วน request body ทำให้คำค้นหาไม่ปรากฏใน access log และประวัติการใช้งานของเบราว์เซอร์อีกต่อไป เอกสารประกอบระบุไว้อย่างตรงไปตรงมาว่าการใช้ POST มีข้อเสียที่ "จำกัดความสะดวกในการใช้งานของผู้ใช้ปลายทางอย่างมาก" โดยส่วนใหญ่เกี่ยวข้องกับปุ่มย้อนกลับของเบราว์เซอร์ นี่คือการแลกเปลี่ยนที่คุณต้องตัดสินใจเลือกเอง

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

บน VPS ของคุณเอง เอนจินจะเห็นเซิร์ฟเวอร์ของคุณแทนที่จะเป็นตัวคุณ

การรัน instance ของคุณเองบน VPS (virtual private server) มีการเปลี่ยนแปลงที่อธิบายได้ง่าย Google จะไม่ได้รับ IP address ที่บ้านของคุณพร้อมกับคำค้นหาอีกต่อไป แต่จะได้รับ IP address ของเซิร์ฟเวอร์ของคุณแทน ทำให้ Google ไม่สามารถเชื่อมโยงการค้นหานั้นเข้ากับบัญชีที่คุณล็อกอินไว้ โทรศัพท์ของคุณ หรือโปรไฟล์โฆษณาที่ผูกกับเครือข่ายในบ้านของคุณได้ ขั้นตอนการสร้างระบบครอบคลุมอยู่ใน คู่มือการรัน SearXNG instance ของคุณเองบน VPS

โปรดทำความเข้าใจให้ชัดเจนว่าสิ่งใดที่ไม่ได้เปลี่ยนไป เอนจินยังคงเห็นข้อความคำค้นหา เวลา ภาษา และภูมิภาคที่คุณระบุ รวมถึงรูปแบบการค้นหาทั้งหมดของคุณตลอดหลายเดือน โดยทั้งหมดจะถูกจัดกลุ่มภายใต้ที่อยู่เดียวที่คงที่ หากคุณเป็นผู้ใช้งานเพียงคนเดียว ที่อยู่นั้นจะเป็นกระแสข้อมูลส่วนบุคคลที่ไม่มีชื่อระบุตัวตน การจะทำลายการจัดกลุ่มนี้จำเป็นต้องให้ instance เชื่อมต่อไปยังเอนจินผ่าน outbound proxy หรือผ่าน Tor ซึ่ง SearXNG รองรับการทำงานในส่วนนี้ แต่ถือเป็นงานแยกต่างหากที่ต้องดำเนินการเพิ่ม

สิ่งที่ ISP, ตัวแก้ไข DNS และโฮสต์ของคุณยังคงมองเห็น

มีผู้สังเกตการณ์ 4 กลุ่มที่ไม่ได้รับผลกระทบจากสิ่งเหล่านี้

  • ISP ของคุณจะเห็นการเชื่อมต่อ TLS ไปยัง IP address ของอินสแตนซ์ และเห็นชื่อโฮสต์ในฟิลด์ SNI (Server Name Indication) ซึ่งถูกส่งเป็นข้อความธรรมดาในระหว่างขั้นตอน handshake แต่ ISP จะไม่เห็นเนื้อหาของคำขอ
  • ตัวแก้ไข DNS ของคุณจะเห็นการค้นหาชื่อโฮสต์นั้น ให้ตรวจสอบบนไคลเอนต์ด้วย sudo tcpdump -ni any port 53 ในขณะที่คุณโหลดหน้าเว็บ แล้วคำขอ A record สำหรับอินสแตนซ์ของคุณจะปรากฏขึ้น
  • ผู้ให้บริการ VPS ของคุณเป็นผู้ดูแลฮาร์ดแวร์ จึงสามารถอ่านข้อมูลในดิสก์และหน่วยความจำของเครื่องเสมือนได้ การเข้ารหัสลับดิสก์ภายใน VM ที่เช่ามาไม่สามารถป้องกันส่วนนี้ได้ เนื่องจากระบบที่กำลังทำงานอยู่เป็นผู้ถือคีย์ไว้
  • ใครก็ตามที่มีสิทธิ์ root บนอินสแตนซ์จะเห็นทุกอย่าง ซึ่งรวมถึงตัวคุณเองและใครก็ตามที่เข้าถึงระบบได้ในภายหลัง

การเข้าถึงอินสแตนซ์ในฐานะ Tor onion service จะช่วยปิดช่องโหว่สองข้อแรก เนื่องจากไม่มีชื่อโฮสต์สาธารณะให้ค้นหาและไม่มีฟิลด์ SNI ให้อ่าน โดย ขั้นตอนการเพิ่ม v3 onion service ให้กับ VPS จะครอบคลุมถึงการตั้งค่ารวมถึงข้อมูลรั่วไหลที่อาจเชื่อมโยงที่อยู่นั้นกลับไปยัง IP สาธารณะของเซิร์ฟเวอร์คุณ

ยังมีอีกหนึ่งประเด็นที่ผู้คนมักลืม คือคำขอขาออกของเซิร์ฟเวอร์คุณนั้นสามารถมองเห็นได้จากเครือข่ายของเซิร์ฟเวอร์เอง ดังนั้นผู้ให้บริการของคุณจึงเห็นได้ว่าเครื่องของคุณติดต่อกับ Google และ Bing ตลอดทั้งวัน ซึ่งนั่นเป็นรูปแบบการรับส่งข้อมูล (traffic pattern) มากกว่าจะเป็นคำขอ และมันยังคงบ่งบอกข้อมูลบางอย่างได้

นี่คือจุดที่คำถามเรื่อง VPN เกิดขึ้น VPN (Virtual Private Network) จะเปลี่ยนมุมมองจาก ISP ของคุณไปเป็นมุมมองของบริษัท VPN แทน แต่มันไม่ได้เปลี่ยนแปลงอะไรเกี่ยวกับผู้ให้บริการอินสแตนซ์และไม่ได้เปลี่ยนแปลงอะไรเกี่ยวกับเครื่องมือค้นหา (engines) เนื่องจากเครื่องมือค้นหาเหล่านั้นกำลังสื่อสารกับเซิร์ฟเวอร์ของคุณ ไม่ใช่สื่อสารกับตัวคุณ ทั้งสองประเด็นนี้ถูกเปรียบเทียบไว้อย่างชัดเจนใน การวิเคราะห์เปรียบเทียบระหว่าง VPS กับ VPN

เหตุใด SearXNG ถึงบล็อกคุณ และความหมายที่แท้จริงของ 429

มีเหตุการณ์สองลักษณะที่มักถูกเรียกว่า "SearXNG บล็อกฉัน" ซึ่งมีวิธีแก้ไขที่แตกต่างกัน

กรณีแรกคือตัวจำกัดอัตรา (limiter) ของคุณเองตอบกลับด้วย HTTP 429 นี่คือระบบป้องกันบอทของ SearXNG ซึ่งโดยปกติจะปิดใช้งานไว้เป็นค่าเริ่มต้น:

server:
  limiter: true
valkey:
  url: valkey://localhost:6379/0

ตั้งแต่เดือนสิงหาคม 2026 เป็นต้นไป ตัวจำกัดอัตราจำเป็นต้องใช้ฐานข้อมูล Valkey และอ่านกฎจาก /etc/searxng/limiter.toml หากมีบุคคลภายนอกใช้งานเซิร์ฟเวอร์ของคุณจริง ให้ตั้งค่า server.public_instance: true ด้วย เนื่องจากค่าเริ่มต้นคือ false ซึ่งเป็นตัวกำหนดพฤติกรรมสำหรับการใช้งานสาธารณะ

ตัวจำกัดอัตราจะทำงานผ่านการตรวจสอบหลายรูปแบบ http_user_agent จะถือว่า User-Agent ที่ไม่ได้กำหนดไว้ หรือ User-Agent ที่ตรงกับเครื่องมือทั่วไปอย่าง curl และ wget เป็นบอท http_accept จะถือว่าคำขอที่ header Accept ไม่มี text/html เป็นบอท link_token จะทำเครื่องหมายไคลเอนต์ว่าน่าสงสัยหากไม่เคยเรียกใช้ URL /client<token>.css ซึ่งเบราว์เซอร์ปกติจะโหลดเสมอ เมื่อการตรวจสอบพบความผิดปกติ SearXNG จะส่งสถานะ 429 และเขียนบรรทัด ERROR ลงใน logger botdetection ของระบบ

ดังนั้นการทำงานนี้จึงล้มเหลว ซึ่งเป็นสิ่งที่ควรจะเป็น:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'

curl ส่ง User-Agent: curl/8.5.0 และ Accept: */* ทำให้ตรงกับเงื่อนไขการตรวจสอบสองรายการพร้อมกัน นี่คือเหตุผลที่สคริปต์และ AI agent ได้รับสถานะ 429 จากอินสแตนซ์ที่ใช้งานผ่านเบราว์เซอร์ได้ตามปกติ และเป็นสิ่งที่ต้องแก้ไขก่อน การเชื่อมต่อความสามารถในการค้นหาของ agent เข้ากับอินสแตนซ์ของคุณเอง รายละเอียดสาเหตุและการตั้งค่าทั้งหมดอยู่ใน คู่มือการจำกัดอัตราและข้อผิดพลาด 429 ของ SearXNG

มีกับดักของตัวจำกัดอัตราหนึ่งที่ควรทราบ หากอยู่หลัง reverse proxy ตัว SearXNG จะมองเห็นที่อยู่ IP ของ proxy แทนที่จะเป็นที่อยู่ของผู้เข้าชม เว้นแต่ว่า proxy นั้นจะได้รับความเชื่อถือ:

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']

[botdetection.ip_limit]
link_token = false

[botdetection.ip_lists]
pass_ip = []
block_ip = []

รายการเริ่มต้นจะครอบคลุม proxy ที่อยู่บนโฮสต์เดียวกัน หาก proxy อยู่ใน Docker network แยกต่างหาก คำขอจะมาจากที่อยู่เช่น 172.18.0.5 ซึ่งไม่อยู่ในรายการ ส่งผลให้ผู้เข้าชมทุกคนถูกนับเป็นไคลเอนต์เดียวกัน และผู้ใช้งานที่ใช้งานหนักเพียงคนเดียวจะทำให้ผู้อื่นถูกบล็อกทั้งหมด ให้เพิ่ม subnet นั้นลงใน trusted_proxies

การบล็อกประเภทที่สองเกิดขึ้นจากต้นทาง (upstream) โดย search engine จะตัดสินว่าที่อยู่ IP ของศูนย์ข้อมูลที่มีการค้นหาจำนวนมากเป็น scraper และหยุดตอบกลับเซิร์ฟเวอร์ของคุณ ในกรณีนี้คุณจะไม่ได้รับสถานะ 429 แต่คุณจะได้รับหน้าผลลัพธ์ที่ไม่มีข้อมูลจาก engine นั้นและมีการระบุความล้มเหลวไว้ โดย SearXNG จะระงับการใช้งาน engine นั้นชั่วคราวหลังจากเกิดความล้มเหลวซ้ำๆ สาเหตุเกิดจากที่อยู่ IP ของ VPS ของคุณ ดังนั้นวิธีแก้ไขคือการเลือก engine ใหม่และความอดทน ไม่ใช่การปรับแต่งค่าในตัวจำกัดอัตรา

การแชร์อินสแตนซ์กับคนแปลกหน้ามีผลดีหรือผลเสียอย่างไร

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

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

ดังนั้น ให้เลือกตามภัยคุกคามที่คุณเผชิญอยู่จริง หากคุณกังวลเรื่องการทำโปรไฟล์โฆษณาและการติดตามข้ามเว็บไซต์ (cross-site tracking) การใช้งานร่วมกับคนจำนวนมากจะช่วยจัดการเรื่องนี้ได้ดีและมีความเสี่ยงจากผู้ดูแลระบบต่ำ หากคุณกังวลว่าบุคคลหรือบริษัทใดบริษัทหนึ่งจะอ่านคำค้นหาเฉพาะเจาะจงที่คุณทำ การใช้งานร่วมกับคนจำนวนมากจะไม่ช่วยอะไรเลยเพราะผู้ดูแลระบบจะเห็นข้อมูลที่เป็นข้อความดิบ ทางสายกลางที่ดีคือการใช้อินสแตนซ์สำหรับกลุ่มคนจำนวนไม่กี่คนที่คุณรู้จัก คุณจะได้กลุ่มผู้ใช้ขนาดเล็กและผู้ดูแลระบบที่คุณสามารถตรวจสอบได้ เพราะผู้ดูแลระบบคนนั้นก็คือตัวคุณเอง

ผลลัพธ์จาก SearXNG ดีกว่า Google หรือไม่

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

สิ่งที่เปลี่ยนไปคือการประมวลผลข้อมูลของคุณ ไม่มีระบบใดสร้างโปรไฟล์โฆษณาจากคำค้นหาของคุณ และไม่มีการจัดลำดับผลลัพธ์ใหม่ตามสิ่งที่คุณคลิกเมื่อสัปดาห์ก่อน ซึ่งส่งผลทั้งสองด้านเนื่องจากการปรับแต่งผลลัพธ์ให้เหมาะกับบุคคล (Personalisation) ยังช่วยในเรื่องความต้องการเชิงพื้นที่ด้วย การค้นหาเช่น "ร้านขายยาเปิดตอนนี้" จะให้ผลลัพธ์ที่ด้อยกว่าผ่าน SearXNG เนื่องจากเครื่องมือไม่มีสัญญาณระบุตำแหน่งของคุณนอกเหนือจากตำแหน่งศูนย์ข้อมูลที่เซิร์ฟเวอร์ตั้งอยู่ ให้ตั้งค่าภูมิภาคใน preferences เมื่อต้องการผลลัพธ์ในพื้นที่

การตั้งค่าสองรายการจะเป็นตัวกำหนดว่า instance ของคุณจะรั่วไหลข้อมูลมากน้อยเพียงใดในขณะที่คุณอ่านผลลัพธ์เหล่านั้น image_proxy ถูกตั้งค่าเป็น false โดยค่าเริ่มต้น ดังนั้นรูปภาพตัวอย่าง (thumbnails) จะโหลดโดยตรงจากเว็บไซต์ที่โฮสต์รูปภาพเหล่านั้น และเว็บไซต์เหล่านั้นจะเห็นที่อยู่ IP ของเบราว์เซอร์คุณ การตั้งค่า image_proxy: true จะเปลี่ยนเส้นทางรูปภาพผ่าน instance แทน ซึ่งต้องแลกมาด้วยการใช้แบนด์วิดท์และหน่วยความจำที่เพิ่มขึ้น และ formats ถูกตั้งค่าเป็น html เท่านั้น ดังนั้นคำขอแบบ JSON (JavaScript object notation) จะถูกปฏิเสธด้วยสถานะ 403 Forbidden:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'

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

จุดสิ้นสุดของความเป็นส่วนตัวใน SearXNG

SearXNG ช่วยปกปิดตัวตนของผู้ค้นหาจากเครื่องมือค้นหา แต่ไม่ได้ปกปิดกิจกรรมของคุณจากเครือข่ายที่ใช้งาน ต่อไปนี้คือข้อจำกัด 4 ประการที่ควรทราบ

  • ทราฟฟิกของคุณจะไม่มีการเปลี่ยนแปลงใดๆ ยกเว้นในส่วนของช่องค้นหา กิจกรรมอื่นๆ ทั้งหมดที่เครื่องทำจะออกจากเครือข่ายของคุณในรูปแบบเดิมทุกประการ
  • ผู้ใช้งานหนึ่งคนบนเซิร์ฟเวอร์หนึ่งเครื่องถือเป็นตัวระบุตัวตนที่คงที่สำหรับทุกเครื่องมือค้นหา ตัวระบุนี้ไม่มีชื่อระบุตัวตน และนั่นคือประโยชน์เพียงอย่างเดียวที่ได้รับ
  • ผู้ดูแล instance ใดก็ตามสามารถอ่านข้อความค้นหาของคุณได้ในรูปแบบข้อความธรรมดา การเป็นผู้ดูแลด้วยตนเองเป็นวิธีเดียวที่คุณจะสามารถตรวจสอบความปลอดภัยในส่วนนี้ได้
  • log การเข้าถึงของคุณเองจะสร้างบันทึกที่คุณพยายามหลีกเลี่ยงขึ้นมาใหม่ หากคุณต้องการให้ log ว่างเปล่า ให้ตรวจสอบ log เหล่านั้นและเปลี่ยนไปใช้ method: "POST" แทน

SearXNG เป็นเพียงการย้ายจุดที่ถูกเฝ้าสังเกตเท่านั้น ไม่ได้กำจัดการเฝ้าสังเกตให้หมดไป คุณควรตัดสินใจว่าคุณกังวลเกี่ยวกับผู้เฝ้าสังเกตรายใด เลือก instance ที่เหมาะสม และอย่ามองว่าหน้าเว็บสำหรับค้นหาเป็นซอฟต์แวร์เพื่อการปกปิดตัวตน (anonymity software)

FAQ

การใช้งาน SearXNG บน public instance ปลอดภัยหรือไม่?

ในมุมของ search engine ถือว่าปลอดภัย แต่ในมุมของผู้ดูแลระบบนั้นไม่ปลอดภัย คำค้นหาของคุณจะถูกส่งไปยังเซิร์ฟเวอร์นั้นในรูปแบบข้อความธรรมดา (plain text) และเอกสารประกอบของโปรเจกต์ระบุชัดเจนว่าผู้ใช้ "ต้องเชื่อใจผู้ดูแลระบบของ instance นั้น" และไม่สามารถทราบได้ว่า "คำขอถูกบันทึก รวบรวม หรือส่งต่อ/ขายให้กับบุคคลที่สามหรือไม่" ด้วยค่าเริ่มต้นที่มาพร้อมกับ method: "GET" คำค้นหาจะปรากฏอยู่ใน access log ของ reverse proxy ในส่วนของ request line ไม่ว่าผู้ดูแลระบบจะตั้งใจให้เป็นเช่นนั้นหรือไม่ก็ตาม ให้ใช้ public instance สำหรับการค้นหาทั่วไปที่คุณกังวลเรื่องการทำ ad profiling เท่านั้น ห้ามพิมพ์ข้อมูลใดๆ ลงใน instance ที่คุณไม่ไว้วางใจเจ้าของระบบ

SearXNG ช่วยซ่อนคำค้นหาจากผู้ให้บริการอินเทอร์เน็ต (ISP) ของฉันหรือไม่?

ตัวข้อความคำค้นหาจะถูกซ่อนไว้ แต่กิจกรรมการใช้งานจะไม่ถูกซ่อน ISP ของคุณจะเห็นการเชื่อมต่อ TLS ไปยังที่อยู่ของ instance และเห็นชื่อโฮสต์ในฟิลด์ SNI แบบข้อความธรรมดาในระหว่างการ handshake รวมถึง DNS resolver ของคุณจะเห็นการค้นหาชื่อโฮสต์นั้น แต่ทั้งสองฝ่ายจะไม่เห็นสิ่งที่คุณค้นหาเนื่องจากการเชื่อมต่อถูกเข้ารหัสไว้ SearXNG ไม่ใช่ VPN และไม่ได้ให้การป้องกันใดๆ กับกิจกรรมอื่นที่เครื่องของคุณทำ

ทำไม SearXNG ถึงส่งคืนข้อผิดพลาด 429?

ข้อผิดพลาด 429 มาจากระบบจำกัดอัตราการเข้าถึง (limiter) ของตัว instance เอง ซึ่งเป็นการป้องกันบอท ไม่ใช่ข้อความจาก Google ระบบตรวจสอบจะทำเครื่องหมายคำขอที่ header Accept ขาด text/html หรือมี User-Agent ที่ไม่ได้ตั้งค่าหรือตรงกับเครื่องมืออย่าง curl และ wget การตรวจสอบที่สามคือ link token ซึ่งจะทำเครื่องหมาย client ที่ไม่เคยดึงข้อมูล URL /client<token>.css ที่เบราว์เซอร์ปกติจะโหลด หากอยู่หลัง reverse proxy ที่ไม่ได้ระบุไว้ใน trusted_proxies ภายใน /etc/searxng/limiter.toml ผู้เข้าชมทุกคนจะถูกนับเป็น client เดียวกัน ทำให้ผู้ใช้ที่ใช้งานหนักเพียงคนเดียวส่งผลให้ผู้อื่นถูกบล็อกไปด้วย ในกรณีที่ upstream engine บล็อกเซิร์ฟเวอร์ของคุณ ผลลัพธ์จาก engine นั้นจะหายไปจากหน้าเว็บเฉยๆ โดยที่คุณจะไม่ได้รับข้อผิดพลาด 429

การ self-host SearXNG ทำให้ผลการค้นหาแย่ลงหรือไม่?

ในบางครั้งอาจแย่ลงด้วยเหตุผล 2 ประการที่ควรทราบ ประการแรก ผลลัพธ์มาจาก upstream engine ดังนั้นหากที่อยู่ IP ของ datacenter ถูกจำกัดความเร็ว (throttle) จะทำให้มี engine ตอบกลับน้อยลงและผลลัพธ์บนหน้าเว็บจะเบาบางลง ประการที่สอง การจัดอันดับแบบเฉพาะบุคคล (personalised ranking) จะหายไป ซึ่งช่วยลดการจัดลำดับใหม่ที่ขับเคลื่อนด้วยโฆษณา แต่ก็ทำให้การค้นหาที่อิงตามตำแหน่งที่ตั้ง (local intent) ให้ผลลัพธ์ที่แม่นยำน้อยลง จนกว่าคุณจะตั้งค่าภูมิภาคใน preferences ของคุณเอง