SSD Nodes Learn 8GB RAM — $66/שנה
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-01

איך להקים מנוע חיפוש פרטי עם SearXNG בשרת שלכם

מדריך להקמת SearXNG ב-VPS באמצעות Docker Compose: עריכת settings.yml, הגדרת limiter, חיבור nginx עם TLS והפעלת JSON API לסקריפטים שלכם.

מה אתם בונים

אירוח עצמי של SearXNG מספק לכם מנוע חיפוש פרטי שפועל בשרת שלכם. SearXNG הוא מנוע חיפוש-על: הוא מקבל את השאילתה שלכם, פונה למנועים אחרים כגון Google, Bing, DuckDuckGo ו-Wikipedia, ולאחר מכן ממזג את התוצאות לדף תוצאות אחד. לא נבנה פרופיל ולא מוגדרת עוגיית מעקב, משום שהמחשב היחיד ששומר את השאילתה שלכם הוא המחשב שלכם.

רכיבי המערכת מעטים. שני containers, קובץ הגדרות אחד ו-reverse proxy אחד. ההחלטה החשובה היא אם המופע יהיה פרטי, כלומר רק אתם והסקריפטים שלכם יוכלו לגשת אליו, או ציבורי, כלומר כל משתמש באינטרנט יוכל לשלוח אליו שאילתות. בחירה זו משנה את הגדרות האבטחה, ולכן יש לבצע אותה לפני הקלדת פקודה כלשהי. ברירת המחדל היא פרטי.

יש סיבה נוספת להפעיל מופע כזה. מופע SearXNG מספק ממשק JSON, ולכן כל סקריפט או סוכן AI שתכתבו יקבל API לחיפוש שנמצא בבעלותכם, ללא מפתח, ללא חיוב לכל שאילתה וללא הודעות בנוגע למכסות.

התקנת SearXNG באמצעות Docker Compose

הפרויקט מפרסם 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 הוא מאגר נתונים בזיכרון, המשמש להגבלת קצב ולשמירת מצב לזמן קצר. הקובץ טוען את ./core-config/ אל /etc/searxng/ בתוך הקונטיינר, ולכן כל ההגדרות שלכם נמצאות באותה ספרייה בשרת המארח.

כעת ערכו את .env. כל שורה בדוגמה שסופקה מסומנת כהערה, ולכן הקונטיינר מתחיל להאזין בפורט 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, כך שהקונטיינר עונה רק בכתובת loopback והאינטרנט אינו יכול לגשת אליו ישירות. אם תדלגו על שלב זה, הקונטיינר ייחשף מיד עם הפעלתו, מכיוון שפורט Docker מפורסם מוכנס לפני כללי חומת האש שלכם. כדאי לקרוא במלואו על המלכודת הזו: פורט Docker מפורסם עוקף את ufw.

SEARXNG_VERSION=latest מתאים בזמן הלמידה. בשרת חשוב, הצמידו את התגית לגרסה מסוימת. נכון ליולי 2026, תגיות הגרסאות מבוססות על תאריך ונראות כמו 2026.3.25-541c6c3cb, ולכן פריסה עם גרסה מוצמדת משתדרגת רק כאשר אתם מחליטים על כך, ולא כאשר המאגר משתנה ללא התערבותכם.

settings.yml: החלקים החשובים

צרו את core-config/settings.yml לפני ההפעלה הראשונה. use_default_settings: true מורה ל-SearXNG לטעון את ברירות המחדל שסופקו עם התוכנה, ולאחר מכן להחיל רק את המפתחות שכתבתם. כך הקובץ נשאר קצר וממשיך לעבוד גם לאחר שדרוגים שמוסיפים אפשרויות חדשות.

הפיקו תחילה את הסוד, משום שהערך יוזן ישירות לקובץ.

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 חותם על נתוני הפעלות ועל נתוני אסימונים. ברירת המחדל שסופקה היא המחרוזת המילולית ultrasecretkey. אם משאירים אותה, כל מי שמכיר את ברירת המחדל יכול לזייף את האסימונים האלה. החליפו אותה פעם אחת, ולאחר מכן השאירו אותה ללא שינוי. שינוי מאוחר יותר ימחק את כל ההעדפות שנשמרו.

base_url חייבת להיות כתובת ה-HTTPS הציבורית, כולל הלוכסן בסופה. זו הכתובת ש-SearXNG כותב בקישורים שהוא מציג. אם משאירים אותה כשהיא מצביעה על localhost, הקישור ל"עמוד הבא" בדפדפן מרוחק יצביע על המחשב של המשתמש עצמו וייכשל.

formats קובעת אילו סוגי פלט נקודת הקצה באינטרנט תפיק. json אינה נמצאת ברשימת ברירות המחדל, ולכן בקשת JSON מחזירה 403 עד שמוסיפים אותה. image_proxy: true מנתבת את התמונות הממוזערות של תוצאות החיפוש דרך השרת שלכם, כך שהאתרים שמארחים את התמונות האלה לא יראו את כתובות המבקרים.

ה-valkey.url משתמש בשם המארח valkey, משום שזהו שם השירות בקובץ Compose. Compose מציב את שני הקונטיינרים באותה רשת, שבה שמות שירותים נפתרים. אם מצביעים אל localhost, מגבלת הקצב נכשלת, משום שבתוך הקונטיינר core, localhost הוא הקונטיינר עצמו.

הסוד נמצא בקובץ רגיל, לכן יש להגן על הספרייה שמכילה אותו ולא על הקובץ עצמו. chmod 750 /opt/searxng מונעת ממשתמשים אחרים במארח לגשת אליו. אל תשנו את core-config/settings.yml למצב 600. הקונטיינר פועל כמשתמש חסר הרשאות משלו, וקובץ שאין לו אפשרות לקרוא מונע מ-SearXNG להתחיל לפעול.

הפעילו את ה-stack ובדקו אותו.

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

docker compose ps אמורה להציג את שני הקונטיינרים במצב running. ה-curl אמורה להשיב HTTP/1.1 200 OK. אם אינה משיבה דבר, קראו את docker compose logs core, משום שטעות YAML ב-settings.yml תופיע שם כשגיאת ניתוח שמציינת את השורה.

הציבו מאחורי 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 לפני הטעינה מחדש. Certbot כותב מחדש את אותו קובץ כדי להאזין ב-443 עם תעודה, ומוסיף הפניה מחדש מיציאה 80. רשומת ה-DNS עבור search.example.com חייבת כבר להפנות לשרת הזה, מכיוון שרשות האישורים מוכיחה בעלות באמצעות הורדת קובץ דרך HTTP. המדריך המלא, כולל חידוש התעודה, נמצא ב-מדריך Certbot ו-nginx עבור Ubuntu 24.04.

שתי כותרות ההעברה אינן קישוט. ללא X-Forwarded-For ו-X-Real-IP, כל בקשה שמגיעה אל SearXNG כוללת את כתובת ה-proxy, ולכן מגביל הקצב רואה לקוח אחד שמייצר את כל התעבורה ואינו יכול להבחין בין המבקרים.

מדוע סקריפטים וסוכנים זקוקים ל-API לחיפוש JSON

כאשר json נמצא ב-formats, אותה נקודת קצה שמציגה את הדף מחזירה נתונים מובנים.

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. די בכך כדי להזין מסכם, בודק קישורים או לולאת מחקר.

הדבר חשוב לכל יישום המבוסס על סוכן. למודל שפה יש מועד חיתוך של נתוני האימון, ולכן הוא זקוק לחיפוש עדכני כדי לענות על שאלות הנוגעות להווה. ממשקי API מסחריים לחיפוש גובים תשלום עבור כל שאילתה ומגבילים את קצב הבקשות באופן נוקשה. מופע מקומי מסתכם במכולה אחת בשרת שכבר משולם עבורו, והשאילתות אינן עוזבות אותו. אם אתם מחברים כלים למודל, אותו שיקול מוביל ל-הפעלת שרתי MCP ב-VPS, כאשר כלי חיפוש הוא בדרך כלל הכלי הראשון שמוסיפים.

יש שני כללים לשימוש ב-API. שמרו את המופע פרטי. קשרו את צד ה-API לכתובת הלולאה החוזרת או לרשת פרטית, ואפשרו רק למארחים שלכם לגשת אליו. לאחר מכן שלחו שאילתות במתינות. SearXNG מעביר את הבקשה שלכם למנועי חיפוש אמיתיים, ולכן סקריפט שמריץ מאה שאילתות בשנייה מבקש מ-Google לחסום את השרת שלכם.

מנגנון ההגבלה, ומה משתנה עבור מופע ציבורי

מנגנון ההגבלה הוא מנגנון ההגנה של SearXNG מפני בוטים. הוא מנטר כותרות בקשות, כתובות וקצבי בקשות, ומשמיט תעבורת רשת שנראית אוטומטית. הוא זקוק ל-Valkey כדי לשמור את המצב הזה, ולכן הוא כלול בקובץ Compose.

במופע פרטי השאר את limiter: false. הסקריפטים שלך הם תעבורה אוטומטית מעצם הגדרתם, ולכן מנגנון ההגבלה יחסום בדיוק את קריאות ה-JSON שלשמן בנית את המופע. בקרת הגישה היא באחריות ה-proxy ההפוך: זוג allow ו-deny ב-location של nginx, אימות בסיסי של HTTP, או חומת אש שמאפשרת גישה רק לשרתים האחרים שלך.

אם אתה מפרסם את המופע עבור משתמשים אחרים, הפעל את שני המתגים.

server:
  limiter: true
  public_instance: true

שליטה מפורטת יותר מוגדרת ב-core-config/limiter.toml, שהמכולה קוראת מתוך /etc/searxng/limiter.toml. יש לכתוב רק את המפתחות שברצונך לשנות. מאחורי proxy חובה להצהיר על ה-proxy, אחרת מנגנון ההגבלה יזהה את כתובת ה-nginx שלך כלקוח הפוגעני היחיד.

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

[botdetection.ip_limit]
link_token = true

link_token = true גורם ל-SearXNG להנפיק אסימון שרק הפעלת דפדפן אמיתית תבקש, ובכך מונע את רוב הסורקים הפשוטים. צפה שמופע ציבורי ימשוך סורקים כאלה בתוך ימים. צפה גם לשגיאות במנועים, מפני שככל שתעביר יותר תעבורה, כך מנועי המקור יתחילו להחזיר CAPTCHA לכתובת השרת שלך מוקדם יותר. מופע ציבורי של SearXNG דורש תחזוקה שוטפת. מופע פרטי אינו דורש זאת, ולכן הוא מופיע ברוב הרשימות הקצרות של דברים שכדאי לארח בעצמך ב-2026.

מדוע החיפושים אינם מחזירים תוצאות

פתחו את /stats במופע שלכם. הוא מציג את כל המנועים, את שיעור השגיאות ואת זמן התגובה של כל אחד מהם. זהו המקום הראשון לבדיקה כאשר מספר התוצאות נמוך.

מנוע שמציג שגיאות מסוג "Access denied" או "CAPTCHA" חסם את כתובת השרת שלכם. הדבר נפוץ בכתובות מטווחים של מרכזי נתונים, משום שמנועי חיפוש מניחים שהן שייכות לסורקים. לאחר מכן SearXNG משעה את המנוע שנכשל למשך פרק זמן, במקום לנסות שוב. לכן מנוע חסום אחד נעלם מהתוצאות בלי הודעה ברורה. השביתו אותו ב-settings.yml או קבלו את הירידה בכיסוי. המנועים הנותרים עדיין מחזירים תשובות.

אם כל המנועים נכשלים בו-זמנית, ל-container אין פתרון שמות יוצא תקין או שאין לו נתיב אל האינטרנט. בדקו זאת מתוך ה-container.

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

FAQ

האם SearXNG הופך את החיפושים שלי לאנונימיים?

הוא מסתיר את זהותכם ממנועי החיפוש שאליהם הוא שולח שאילתות, משום שהם רואים את השרת שלכם שולח את הבקשה במקום את הדפדפן שלכם. הוא אינו מסתיר את השאילתה מהשרת שלכם, ואינו מסתיר את השרת שלכם ממנועי החיפוש. במופע של משתמש יחיד, כל התעבורה מכתובת זו שייכת לכם, ולכן הכתובת עצמה הופכת למזהה. התעבורה בין הדפדפן שלכם למופע שלכם מוגנת באמצעות אישור TLS.

מדוע בקשת JSON מחזירה 403 Forbidden?

יש לכך שתי סיבות, ושתיהן קשורות לתצורה. ייתכן ש-json חסר ברשימת formats תחת search: ב-settings.yml, וזהו מצב ברירת המחדל; לחלופין, ייתכן שהמגביל פעיל וזיהה את הסקריפט שלכם כבוט. הוסיפו תחילה את הפורמט, הפעילו מחדש באמצעות docker compose restart core, ולאחר מכן נסו שוב. אם הבקשה עדיין נכשלת, הגדירו את limiter: false והגבילו את הגישה באמצעות השרת המתווך ההפוך.

האם אני זקוק למכל Valkey אם המגביל נשאר כבוי?

השאירו אותו פועל. SearXNG פועל בלעדיו, אך לא ניתן להפעיל את המגביל בהמשך בלעדיו, והוא גם מחזיק נתוני מצב נוספים קצרי-טווח. המכל קטן ומאחסן נתונים שנשמרו במטמון בלבד, ולכן הסרתו חוסכת מעט מאוד ומונעת מכם את האפשרות להפעיל את המגביל.

כיצד מעדכנים את SearXNG?

הריצו את docker compose pull ולאחר מכן את docker compose up -d בתוך /opt/searxng. Compose יוצר מחדש כל מכל שהתמונה שלו השתנתה ומשאיר את ספריית core-config/ שלכם ללא שינוי, ולכן settings.yml נשמר. מכיוון ש-use_default_settings: true ממזג את המפתחות שלכם על גבי ברירות המחדל שסופקו, אפשרויות שנוספו upstream מגיעות עם ערכים סבירים במקום לגרום לקובץ להיכשל.

האם כמה אנשים יכולים לשתף מופע אחד?

כן, ובמקרה כזה מפעילים את המגביל ומגדירים את public_instance: true. ההעדפות נשמרות בדפדפן של כל מבקר בנפרד, ולכן אין צורך לנהל חשבונות. עקבו אחר /stats במשך שבוע לאחר פתיחת הגישה, משום שמנועי החיפוש upstream מתחילים לדחות את השרת שלכם זמן רב לפני שתבחינו בתוצאות חסרות.

#searxng#search#privacy#self-hosting#docker