วิธีแก้ปัญหา SearXNG ติด CAPTCHA จาก Search Engine

ความหมายของข้อผิดพลาด CAPTCHA ใน SearXNG

ข้อผิดพลาด CAPTCHA ใน SearXNG เกิดจาก search engine ที่ instance ของคุณส่งคำขอไปหา เมื่อเซิร์ฟเวอร์ของคุณร้องขอผลลัพธ์จาก engine แต่ engine กลับตอบกลับมาเป็นหน้า challenge แทนที่จะเป็นผลลัพธ์ SearXNG จึงบันทึกข้อผิดพลาดสำหรับ engine นั้นเนื่องจากไม่มีข้อมูลในคำตอบที่สามารถนำไปประมวลผลได้ ตัว instance ของคุณยังทำงานได้ตามปกติ แต่เครื่องที่คุณไม่ได้เป็นผู้ควบคุมตัดสินว่าคำขอของคุณดูไม่เหมือนพฤติกรรมของมนุษย์

ข้อเท็จจริงนี้เป็นตัวกำหนดวิธีการแก้ไขทั้งหมดด้านล่าง เนื่องจากการตัดสินใจเกิดขึ้นบนฮาร์ดแวร์ของตัว engine เอง จึงไม่มีการตั้งค่าใดใน settings.yml ที่จะสามารถเปลี่ยนแปลงผลลัพธ์นั้นได้ สิ่งที่คุณสามารถทำได้คือการเปลี่ยนที่อยู่ IP ที่ใช้ส่งคำขอ การเลือก engine ที่จะใช้งาน หรือการปรับพฤติกรรมของ instance เมื่อ engine เริ่มปฏิเสธการให้บริการ

ความล้มเหลวสองรูปแบบที่ดูคล้ายกันและวิธีแยกแยะ

ความล้มเหลวแบบแรกคือ instance ของคุณตอบกลับด้วย HTTP 429 (too many requests) ให้กับเบราว์เซอร์ของคุณเอง นี่คือตัวจำกัดของ SearXNG ซึ่งเป็นชั้นการตรวจจับบอทที่อยู่หน้า endpoint การค้นหา มันทำงานบนเซิร์ฟเวอร์ของคุณและคุณเป็นผู้กำหนดค่าเอง ตัวจำกัดที่ส่งคืน 429 ให้กับผู้ใช้ของคุณเอง เป็นปัญหาแยกต่างหากที่มีการตั้งค่าแยกกัน และคำแนะนำด้านล่างนี้ไม่มีส่วนเกี่ยวข้องกับกรณีดังกล่าว

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

• หากหน้าเว็บไม่โหลด หรือ endpoint การค้นหาตอบกลับด้วย 429: ให้ตรวจสอบตัวจำกัด (limiter) ของคุณ
• หากหน้าเว็บโหลดได้แต่ผลลัพธ์มีน้อย หรือเครื่องมือค้นหาถูกระบุว่ามีข้อผิดพลาด: ให้ตรวจสอบต้นทาง (upstream) และอ่านคำแนะนำต่อไป

ทั้งสองกรณีสามารถเกิดขึ้นได้ใน instance เดียวกันและส่งผลกระทบต่อกัน เนื่องจากตัวจำกัดที่ตั้งค่าไว้หลวมเกินไปจะปล่อยให้ทราฟฟิกผ่านเข้ามามากจนผลักดันอัตราการส่งคำค้นหาออกไปสูงขึ้น ให้วินิจฉัยปัญหาเหล่านี้ทีละประเด็น

เหตุใด SearXNG engines จึงส่งข้อผิดพลาด CAPTCHA กลับมาเมื่อใช้งานบน VPS แต่ไม่พบปัญหานี้บนแล็ปท็อปของฉัน?

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

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

การปฏิเสธการเข้าถึงไม่ได้แสดงออกมาเป็นความล้มเหลวที่ชัดเจนเสมอไป เครื่องมือค้นหาอาจตอบกลับด้วยรหัส 403, 429 หรือตอบกลับด้วย HTTP 200 พร้อมหน้าท้าทาย (challenge page) ในเนื้อหา กรณีหลังนี้มักทำให้ผู้ใช้สับสน เพราะการตรวจสอบรหัสสถานะจะระบุว่าเครื่องมือค้นหาทำงานปกติ ในขณะที่ SearXNG กลับไม่พบผลลัพธ์ใดๆ ในการตอบกลับ นี่คือเหตุผลที่คุณควรตรวจสอบรายงานข้อผิดพลาดของอินสแตนซ์ของคุณเอง แทนการใช้คำสั่ง curl เพื่อตรวจสอบเครื่องมือค้นหาและดูเพียงบรรทัดสถานะเท่านั้น

อ่านสิ่งที่อินสแตนซ์ของคุณรายงานก่อนทำการเปลี่ยนแปลงใดๆ

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

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

docker compose logs -f core

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

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

วิธีที่ SearXNG ใช้ลองใหม่และระงับ engine ที่ทำงานล้มเหลว

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

กลไกนี้ควบคุมโดยสองส่วน ซึ่งทั้งคู่อยู่ภายใต้ search: ในไฟล์ settings.yml โปรดตรวจสอบชื่อคีย์เหล่านี้กับเอกสารการตั้งค่าของเวอร์ชันที่คุณใช้งานจริงก่อนที่จะคัดลอกค่าใดๆ ไปวาง เนื่องจากมีการย้ายตำแหน่งคีย์ระหว่างการปล่อยเวอร์ชันต่างๆ ตามที่ระบุไว้เมื่อวันที่ 2 กันยายน 2026 ค่าเริ่มต้นมีดังนี้:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 86400
    SearxEngineCaptcha: 86400
    SearxEngineTooManyRequests: 3600
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

ส่วนแรกจัดการกับความล้มเหลวทั่วไป เช่น การหมดเวลา (timeout) การระงับจะเริ่มที่ ban_time_on_fail วินาที และเพิ่มขึ้นเรื่อยๆ ตามจำนวนครั้งที่ล้มเหลวติดต่อกัน จนถึงขีดจำกัดที่ max_ban_time_on_fail โดยค่าเริ่มต้นคือสองนาที ดังนั้น engine ที่ทำงานไม่เสถียรจะฟื้นตัวได้เองภายในไม่กี่นาทีหลังจากปัญหาหมดไป

ส่วนที่สองจัดการกับความล้มเหลวที่เป็นหัวข้อของคู่มือนี้ เมื่อ SearXNG ตรวจพบว่าการตอบกลับเป็นความท้าทาย (challenge) หรือการปฏิเสธ (refusal) แทนที่จะเป็นข้อผิดพลาดทั่วไป ระบบจะใช้ค่าที่ตรงกันจาก suspended_times ซึ่งตัวเลขเหล่านี้จะมีค่าสูงกว่ามาก โดย 86400 วินาทีคือหนึ่งวันเต็ม 604800 คือหนึ่งสัปดาห์ และ 1296000 คือสิบห้าวัน คีย์ที่มีคำนำหน้า cf_ จะใช้เมื่อตรวจพบว่าเป็นความท้าทายจาก Cloudflare และ recaptcha_ เมื่อตรวจพบว่าเป็น reCAPTCHA

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

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

เอกสารเกี่ยวกับ SSH tunnel และสิ่งที่วิธีนี้แก้ไขไม่ได้

ตรวจสอบเมื่อวันที่ 2 กันยายน 2026 เอกสารผู้ดูแลระบบของ SearXNG ได้ระบุวิธีแก้ปัญหานี้ด้วยการทำ tunnel แบบแมนนวล คุณสามารถเปิด SOCKS proxy ผ่านเซิร์ฟเวอร์ของคุณ ตั้งค่าเบราว์เซอร์บนเดสก์ท็อปให้เชื่อมต่อผ่าน proxy ดังกล่าว แล้วตอบโต้กับ challenge ด้วยตนเองในขณะที่ search engine มองเห็นที่อยู่ IP ของเซิร์ฟเวอร์

ssh -q -N -D 8080 user@example.org

-D 8080 จะเปิด SOCKS server ในเครื่องที่พอร์ต 8080 ซึ่งส่งต่อข้อมูลผ่านการเชื่อมต่อ SSH ส่วน -N จะไม่รันคำสั่งบนฝั่งรีโมท และ -q จะทำให้การทำงานเงียบ ดังนั้น tunnel ที่ทำงานปกติจะไม่แสดงข้อความใดๆ และไม่คืนค่ากลับมา ให้ตรวจสอบการทำงานจาก terminal อีกหน้าต่างหนึ่ง:

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

คำสั่งแรกควรแสดงที่อยู่ IP ของเซิร์ฟเวอร์ และคำสั่งที่สองควรแสดงที่อยู่ IP ของเดสก์ท็อปของคุณ หากได้ผลลัพธ์เหมือนกันทั้งสองค่า แสดงว่าคำขอไม่ได้วิ่งผ่าน tunnel จากนั้นให้ตั้งค่า network ในเบราว์เซอร์ของคุณให้ใช้ SOCKS5 proxy ที่ 127.0.0.1 พอร์ต 8080 แล้วโหลดหน้าเว็บตรวจสอบที่อยู่ IP ในเบราว์เซอร์เพื่อยืนยันว่าระบบรายงานที่อยู่เป็นของเซิร์ฟเวอร์ จากนั้นจึงเข้าใช้งาน search engine ที่กำลังแสดง challenge ให้คุณตอบโต้กับ challenge นั้นที่นั่น

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

ใช้วิธีนี้เพื่อให้ instance ใช้งานได้ในช่วงบ่ายนี้เท่านั้น แต่อย่าสร้าง instance โดยยึดติดกับวิธีนี้เป็นหลัก

การแก้ไขที่ยั่งยืน: การปิดใช้งานหรือปรับน้ำหนักของเอนจินที่บล็อกคุณ

วิธีแก้ปัญหาที่คุ้มค่าและยั่งยืนที่สุดคือการหยุดส่งคำขอไปยังเอนจินที่ไม่ให้บริการเซิร์ฟเวอร์ของคุณ settings.yml ของคุณเริ่มต้นด้วย use_default_settings: true ในอิมเมจคอนเทนเนอร์ ซึ่งหมายความว่ารายการภายใต้ engines: ที่มี name ตรงกัน จะเขียนทับเฉพาะคีย์ที่คุณระบุไว้เท่านั้น และคงค่าเริ่มต้นส่วนที่เหลือไว้ตามเดิม

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

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

ให้รีสตาร์ทคอนเทนเนอร์หลังจากแก้ไขไฟล์ ทดสอบการค้นหาจำนวนหนึ่ง จากนั้นตรวจสอบ /stats อีกครั้ง หน้าสถิติที่สะอาดตาซึ่งมีเอนจินที่ทำงานได้ปกติ 6 รายการ มีประโยชน์มากกว่าหน้าสถิติที่เต็มไปด้วยข้อผิดพลาดถึง 20 รายการ

การแก้ไขที่ยั่งยืน: ส่งคำขอขาออกผ่านพร็อกซี

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

outgoing:
  request_timeout: 2.0
  extra_proxy_timeout: 10.0
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

ควรเลือกใช้ socks5h:// แทน socks5:// หากคุณต้องการให้พร็อกซีเป็นผู้ทำหน้าที่ resolve ชื่อโฮสต์ เนื่องจาก h หมายความว่าชื่อโฮสต์จะถูกส่งไปยังพร็อกซีแทนที่จะถูกค้นหาจากเซิร์ฟเวอร์ของคุณเอง ในขณะเดียวกันควรเพิ่มงบประมาณเวลา timeout ด้วย เพราะ request_timeout มีค่าเริ่มต้นที่ 2.0 วินาที การใช้พร็อกซีจะเพิ่มรอบการรับส่งข้อมูล (round trip) ให้กับทุกคำขอ ทำให้เอนจินที่เคยตอบสนองทันเวลาเริ่มล้มเหลวเนื่องจาก timeout ดังนั้น extra_proxy_timeout จึงถูกสร้างมาเพื่อการนี้โดยเฉพาะเพื่อเพิ่มจำนวนวินาทีเมื่อมีการใช้งานพร็อกซี

ต้นทุนของการใช้พร็อกซี:

• ผู้ให้บริการพร็อกซีจะเห็นว่าอินสแตนซ์ของคุณสอบถามเอนจินใดและเมื่อใด แม้ว่า TLS (transport layer security) จะช่วยป้องกันไม่ให้ผู้ให้บริการเห็นคำค้นหาใน log เพราะคำค้นหาถูกเข้ารหัสอยู่ภายในคำขอ แต่พวกเขาสามารถวิเคราะห์รูปแบบและช่วงเวลาของทราฟฟิกของคุณได้
• ที่อยู่ IP ขาออกที่ใช้ร่วมกันจะถูกแชร์กับผู้ใช้งานรายอื่น หากผู้ใช้งานรายอื่นทำ scraping คุณจะได้รับผลกระทบจากชื่อเสียงของ IP นั้นไปด้วย ซึ่งบางครั้งอาจถูกบล็อกเร็วกว่าเดิมเสียอีก
• พร็อกซีแบบ residential ราคาถูกมักสร้างขึ้นจากอุปกรณ์ของผู้บริโภคทั่วไปที่เจ้าของไม่ได้ยินยอมให้ผู้อื่นใช้ทราฟฟิกผ่านอุปกรณ์ของตนโดยรู้ตัว ควรตรวจสอบที่มาของบริการที่คุณซื้อ
• using_tor_proxy: true จะส่งทราฟฟิกผ่าน Tor แต่เนื่องจากที่อยู่ของ exit node ถูกเผยแพร่ต่อสาธารณะทั้งหมด เอนจินที่บล็อกช่วง IP ของศูนย์ข้อมูลมักจะบล็อก exit node เหล่านี้อย่างเข้มงวดเช่นกัน
• การค้นหาจะขึ้นอยู่กับบริการภายนอกเซิร์ฟเวอร์ของคุณ ซึ่งอาจเกิดข้อผิดพลาดได้ด้วยตัวมันเองและส่งผลให้คุณไม่ได้รับผลการค้นหา

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

การแก้ไขที่ยั่งยืน: เลือกใช้ชุดเอนจินขนาดเล็กลงโดยเจตนา

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

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

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

คุ้มค่าที่จะสู้หรือไม่?

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

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

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

กฎที่ควรยึดถือคือ: จงสู้เพื่อรักษาเครื่องมือค้นหาไว้หากนั่นคือเหตุผลที่คุณทำ self-host และจงตัดมันทิ้งหากไม่ใช่เหตุผลดังกล่าว

FAQ

ทำไม engine ของ SearXNG ถึงยังไม่แสดงผลลัพธ์หลังจากที่ฉันแก้ไขปัญหาแล้ว?

เพราะ engine นั้นยังคงอยู่ในสถานะถูกระงับการใช้งาน เมื่อ SearXNG ตรวจพบความท้าทาย (challenge) หรือการปฏิเสธจาก engine ระบบจะหยุดส่งคำขอไปยัง engine นั้นตามระยะเวลาที่กำหนดไว้ใน search.suspended_times ซึ่งค่าเริ่มต้นมีตั้งแต่หนึ่งชั่วโมงไปจนถึงสิบห้าวันขึ้นอยู่กับประเภทของการปฏิเสธ สถานะการระงับนี้ถูกเก็บไว้ในกระบวนการทำงานที่กำลังรันอยู่ ดังนั้นการรีสตาร์ท container จะเป็นการล้างสถานะดังกล่าว และการค้นหาครั้งถัดไปจะพยายามเชื่อมต่อกับ engine นั้นอีกครั้ง หาก engine ยังคงล้มเหลวอีกครั้งทันทีหลังจากรีสตาร์ท แสดงว่าการแก้ไขของคุณยังไม่สำเร็จ

ข้อผิดพลาด CAPTCHA จาก engine เหมือนกับข้อผิดพลาด 429 ที่ instance ของฉันส่งกลับมาหรือไม่?

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

การใช้ VPN หรือ proxy บนเซิร์ฟเวอร์จะช่วยแก้ปัญหา CAPTCHA ของ engine ได้หรือไม่?

ทำได้ในบางครั้ง แต่มีต้นทุนที่ต้องแลก การส่งคำขอขาออกผ่าน outgoing.proxies จะเปลี่ยนที่อยู่ IP ที่ engine มองเห็น ซึ่งอาจช่วยปลดบล็อกที่ผูกติดอยู่กับช่วง IP ของศูนย์ข้อมูลที่คุณใช้งานได้ อย่างไรก็ตาม ผู้ให้บริการ proxy จะเห็นว่าคุณสืบค้น engine ใดและเมื่อใด นอกจากนี้ที่อยู่ IP ขาออกที่ใช้ร่วมกันยังมาพร้อมกับชื่อเสียงของผู้ใช้งานรายอื่น และความหน่วง (latency) ที่เพิ่มขึ้นจะทำให้เกิดปัญหา timeout เว้นแต่คุณจะเพิ่มค่า request_timeout และ extra_proxy_timeout สำหรับ Tor นั้นสามารถใช้งานได้ผ่าน using_tor_proxy แต่ที่อยู่ IP ขาออกของ Tor นั้นถูกเผยแพร่ต่อสาธารณะและมักถูกท้าทายอยู่บ่อยครั้ง

ฉันสามารถทำให้ SearXNG แก้ CAPTCHA โดยอัตโนมัติได้หรือไม่?

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