วิธีแก้ปัญหา 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 ที่เสียกลายเป็น engine ที่หายไปโดยไม่มีการแจ้งเตือน

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

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 180
    SearxEngineCaptcha: 3600
    SearxEngineTooManyRequests: 180
    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 ซึ่งตัวเลขส่วนใหญ่มีค่าสูงกว่ามาก โดย 180 วินาทีคือสามนาที สำหรับการปฏิเสธทั่วไปหรือสถานะ 429, 3600 คือหนึ่งชั่วโมง สำหรับ CAPTCHA ทั่วไป, 86400 คือหนึ่งวันเต็ม, 604800 คือหนึ่งสัปดาห์ และ 1296000 คือสิบห้าวัน คีย์ที่มีคำนำหน้าว่า cf_ จะถูกนำมาใช้เมื่อตรวจพบว่าเป็นความท้าทายจาก Cloudflare และ recaptcha_ เมื่อตรวจพบว่าเป็น reCAPTCHA

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

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

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

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

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

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

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

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

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

ใช้วิธีนี้เพื่อให้ 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: 3.0
  extra_proxy_timeout: 10
  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:// หากคุณต้องการให้พร็อกซีเป็นผู้แก้ไขชื่อโฮสต์ (hostname resolution) เนื่องจาก h หมายความว่าชื่อโฮสต์จะถูกส่งไปยังพร็อกซีแทนที่จะทำการค้นหาบนเซิร์ฟเวอร์ของคุณเอง ในขณะเดียวกันควรเพิ่มงบประมาณเวลาสำหรับ timeout ด้วย โดยค่าเริ่มต้นของ request_timeout คือ 3.0 วินาที แต่การใช้พร็อกซีจะเพิ่มรอบการรับส่งข้อมูล (round trip) ให้กับทุกคำขอ ทำให้เครื่องมือค้นหาที่เคยตอบสนองได้ทันเวลาเริ่มล้มเหลวเนื่องจาก timeout แทน ทั้งนี้ extra_proxy_timeout มีไว้เพื่อการนี้โดยเฉพาะและจะเพิ่มจำนวนวินาทีเมื่อมีการใช้งานพร็อกซี ให้ระบุเป็นจำนวนเต็ม เช่น 10 ต่างจาก request_timeout ที่ยอมรับค่าทศนิยม แต่ extra_proxy_timeout เป็นจำนวนเต็มในโครงสร้างการตั้งค่า ดังนั้นค่าอย่าง 10.0 จะถูกปฏิเสธเนื่องจากเป็น settings.yml ที่ไม่ถูกต้อง แม้ว่าตัวอย่างในคอมเมนต์บนหน้าเอกสารการตั้งค่าขาออกจะเขียนไว้ในรูปแบบนั้นก็ตาม

สิ่งที่ต้องแลกเมื่อใช้พร็อกซี:

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

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

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

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

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

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

คุ้มค่าที่จะต่อสู้กับปัญหานี้หรือไม่?

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

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

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

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

FAQ

เหตุใด SearXNG engine จึงยังไม่แสดงผลลัพธ์หลังจากที่ผมแก้ไขปัญหาแล้ว?

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

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

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

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

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

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

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