הגדרת פרוקסי ב‑Wget נראית כמו עניין של חמש שניות — עד שמבינים אחרי שעה למה הבקשות עוקפות את הפרוקסי לגמרי, בלי שום הודעת שגיאה. ראיתי את זה קורה גם למנהלי מערכות ותיקים וגם למפתחים מתחילים.
הבעיה כמעט אף פעם לא נמצאת בפרוקסי עצמו. היא נובעת מארבעה מקומות שונים ש‑Wget יכול לקרוא מהם הגדרות פרוקסי, מכשלים שקטים כשמשתמשים באותיות גדולות או קטנות לא נכונות, ומניואנסים של רשת ארגונית שאף עמוד תיעוד לא טורח להסביר. המדריך הזה סוקר את כל הדרכים להגדרת Wget עם פרוקסי, את כללי הקדימות המדויקים כשכמה שיטות מתנגשות, פלט טרמינל אמיתי לכל שגיאה נפוצה, וגם פרק ייעודי למשתמשי Windows ולמי שעובד מאחורי חומת אש ארגונית — הקהל שכמעט כל מדריך אחר מתעלם ממנו.
- רמת קושי: מתחילים עד ביניים
- זמן נדרש: כ‑15 דקות לקריאה ולהגדרה; כ‑2 דקות ברגע שכבר יודעים מה עושים
- מה צריך: התקנה פעילה של Wget (הנחיות בהמשך), כתובת פרוקסי (host + port), ובמידת הצורך גם פרטי התחברות לפרוקסי
נסו את Thunderbit לחילוץ נתונים מובנים
מה זה Wget ולמה בכלל להשתמש בו עם פרוקסי?
Wget הוא כלי שורת פקודה שמוריד קבצים ודפי אינטרנט מהאינטרנט בלי דפדפן. התיאור הרשמי של GNU מגדיר אותו כ־"non-interactive network downloader" — כלומר הוא עובד ברקע, יודע להמשיך הורדות שנקטעו, ומטפל בהורדות רקורסיביות בלי שאף אחד ילחץ על משהו.
פרוקסי, בהקשר הזה, הוא שרת מתווך. במקום שהמחשב שלכם יתחבר ישירות לאתר היעד, Wget שולח את הבקשה לפרוקסי, והפרוקסי מעביר אותה הלאה. הסיבות העיקריות להשתמש בזה:
- עמידה במדיניות חומת אש ארגונית — הארגון דורש שכל התעבורה היוצאת תעבור דרך פרוקסי מאושר
- פרטיות וניהול IP — הבקשות נראות כאילו הן מגיעות מכתובת ה‑IP של הפרוקסי, לא שלכם
- בדיקות גאוגרפיות — גישה למשאבים מוגבלי אזור או בדיקת התנהגות CDN מאזור מסוים
- צינורות איסוף נתונים — הורדת HTML דרך פרוקסים מתחלפים לצורכי מחקר או ניטור
- סביבות CI/CD — סביבות בנייה ברשתות נעולות שיכולות להגיע לאינטרנט רק דרך פרוקסי
Wget תומך באופן מובנה בפרוקסי ל‑HTTP, HTTPS ו‑FTP. הוא לא תומך ב‑SOCKS5. אם אתם צריכים SOCKS5, ל‑curl יש תמיכה מובנית ב‑socks4://, socks5:// ו‑socks5h:// — או שאפשר לעטוף את Wget בכלי כמו proxychains4.
איך מתקינים Wget ב‑Linux, ב‑macOS וב‑Windows
לפני שמגדירים פרוקסי, צריך ש‑Wget יהיה מותקן במחשב. זה החלק הקצר — רק תנאי מקדים, לא העיקר.
Linux (Debian/Ubuntu ו‑RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# בדיקה
wget --version
Ubuntu 24.04 LTS מגיעה עם Wget 1.21.4, בעוד Debian Trixie כוללת 1.25.0. חבילות CentOS Stream 10 מציגות 1.24.5.
macOS (Homebrew)
brew install wget
wget --version
הנוסחה של Homebrew מספקת כרגע את Wget 1.25.0 היציב, עם 396,818 התקנות בשנה האחרונה.
Windows (Chocolatey והתקנה ידנית)
choco install wget
wget --version
חבילת GNU Wget ב‑Chocolatey מדווחת על יותר מ־10 מיליון הורדות בסך הכול, אף שהיא כרגע בגרסה 1.21.4. הקובץ הבינרי בדרך כלל יופיע תחת C:\ProgramData\chocolatey\bin\wget.exe.
הערה חשובה למשתמשי Windows: המיקום שבו Wget מחפש את .wgetrc משתנה לפי ה‑build. פרטים בהמשך בפרק של Windows.
4 דרכים להשתמש ב‑Wget עם פרוקסי (ואיזו מהן כדאי לבחור)
ארבע שיטות, לכל אחת היקף ורמת קדימות שונים:
- דגלי
-eבשורת הפקודה — חד־פעמי, לפקודה אחת - קובץ הגדרות משתמש (
~/.wgetrc) — חל על כל פקודת Wget שתפעילו - קובץ מערכת (
/etc/wgetrc) — חל על כל המשתמשים במחשב - משתני סביבה (
http_proxy,https_proxy) — חלים על כל סשן ה‑shell
שיטה 1: דגלי שורת פקודה (פרוקסי חד־פעמי)
מתאים לבדיקות מהירות. ההגדרות נעלמות כשהפקודה מסתיימת.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
ליעדי HTTPS:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
בדיקת sanity מהירה — משיכת ה‑IP הנראה שלכם דרך הפרוקסי:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
אם הפלט מציג את כתובת ה‑IP של הפרוקסי במקום שלכם, הכול עובד.
שיטה 2: קובץ הגדרות משתמש (~/.wgetrc)
הוסיפו את השורות הבאות ל‑~/.wgetrc (צרו את הקובץ אם הוא לא קיים):
use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com
שימו לב לרווחים סביב = — זו התחביר המתועד של .wgetrc. מעכשיו, כל פקודת Wget שתפעילו בשם המשתמש הזה תעבור דרך הפרוקסי.
שיטה 3: הגדרה לכל המערכת (/etc/wgetrc)
אותן הנחיות כמו ב‑~/.wgetrc, אבל בקובץ ההגדרות של המערכת. התיעוד של GNU מגדיר זאת כקובץ אתחול גלובלי — הנתיב המדויק תלוי ב‑install prefix שלכם. מיקומים נפוצים:
/etc/wgetrc(ברוב מנהלי החבילות בלינוקס)/usr/local/etc/wgetrc(בחלק מה‑builds של Homebrew)- הנתיב שמופיע בפלט של
wget --versionתחת "Wgetrc:"
זה שימושי לשרתים משותפים, קונטיינרי Docker, או כל סביבה שבה כל המשתמשים צריכים לעבור דרך אותו פרוקסי.
שיטה 4: משתני סביבה (http_proxy / https_proxy)
export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com
אלה משפיעים על כל סשן ה‑shell שלכם — לא רק על Wget. גם כלים כמו curl יזהו אותם.
אזהרה קריטית: Wget קורא רק שמות משתני סביבה באותיות קטנות. HTTP_PROXY (אותיות גדולות) פשוט מתעלם ממנו בשקט. בלי שגיאה, בלי אזהרה, כלום. אראה את הפלט המדויק בפרק ההפתעות, אבל חשוב לזכור את זה כבר עכשיו.
קדימות בין שיטות פרוקסי: מה גובר על מה כשיש כמה הגדרות
אם יש לכם פרוקסי גם במשתני הסביבה וגם ב‑.wgetrc וגם בשורת הפקודה — מי מנצח? אף אחד לא מסביר את זה מספיק ברור, אז בדקתי.
זו הקדימות שנבדקה ומתועדת:
| עדיפות | שיטה | היקף | מבטלת |
|---|---|---|---|
| 1 (הגבוהה ביותר) | דגלי CLI מסוג -e | פקודה אחת | הכול |
| 2 | ~/.wgetrc | המשתמש הנוכחי | קובץ מערכת + משתני סביבה |
| 3 | /etc/wgetrc | כלל המערכת | משתני סביבה בלבד |
| 4 (הנמוכה ביותר) | משתני סביבה http_proxy / https_proxy | סשן shell | כלום |
אימתתי את זה על Wget 1.25.0 על ידי הגדרת פרוקסים מתנגשים בכל רמה. כשהסביבה כוונה לפורט 3128, קובץ ההגדרות לפורט 3129, וה‑CLI לפורט 3130:
- קובץ ההגדרות גובר על הסביבה: Wget התחבר לפורט 3129, והתעלם מ‑3128.
- CLI גובר על קובץ ההגדרות: Wget התחבר לפורט 3130, והתעלם גם מ‑3129 וגם מ‑3128.
היציאה מהמצב הזה היא --no-proxy. היא עוקפת כל הגדרת פרוקסי, לא משנה איפה היא הוגדרה:
wget --no-proxy https://internal-server.company.com/report.pdf
תרחיש מעשי: מנהל המערכת הגדיר פרוקסי ב‑/etc/wgetrc, אבל אתם צריכים להגיע לשרת פנימי ישירות. במקרה כזה משתמשים ב‑--no-proxy רק לפקודה הזו, במקום לערוך את הגדרות המערכת.
איך להשתמש ב‑Wget עם פרוקסי עם אימות
רוב הפרוקסים העסקיים והביתיים דורשים שם משתמש וסיסמה. Wget תומך בזה בשתי דרכים, ובשתיהן נעשה שימוש ב‑HTTP Basic authentication עבור אישורי הפרוקסי.
שילוב פרטי התחברות בכתובת הפרוקסי
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
זה עובד גם ב‑.wgetrc:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
שימוש בדגלים --proxy-user ו--proxy-password
wget --proxy-user=USERNAME --proxy-password=PASSWORD \
-e use_proxy=on \
-e http_proxy=http://proxy.company.com:8080/ \
http://example.com/file.zip
הדגלים האלה גוברים על כל user:pass@ שמוטמע בתוך כתובת הפרוקסי.
שמירה על פרטי התחברות
שתי השיטות עלולות לחשוף סודות. GNU מזהיר שסיסמאות בשורת הפקודה נראות דרך ps או כלים לצפייה ברשימת תהליכים. דרכי צמצום סיכון:
- מחשבים עם משתמש יחיד: שמרו את פרטי ההתחברות ב‑
~/.wgetrcונעלו את הקובץ:chmod 600 ~/.wgetrc - צינורות CI/CD: השתמשו ב‑GitHub Actions encrypted secrets או במקבילה של הפלטפורמה שלכם. העבירו אותם כמשתני סביבה באותיות קטנות בהגדרת השלב — לעולם לא כערכים קשיחים ב‑YAML.
- בוני Docker: אל תשתמשו ב‑
ARGאוENVעבור סודות. התיעוד של Docker מזהיר במפורש ש‑build arguments יכולים להישאר בתוך התמונה הסופית. השתמשו ב‑BuildKit secret mounts במקום זאת. - בקרת גרסאות: לעולם אל תכניסו ל‑git קובץ
.wgetrcעם סיסמאות. הוסיפו אותו ל‑.gitignore.
ניואנס אחד ספציפי ל‑Wget ב‑GitHub Actions: שמות הסודות נשמרים בדרך כלל באותיות גדולות לפי מוסכמה, אבל משתני הסביבה שאתם חושפים ל‑Wget חייבים להיות באותיות קטנות (http_proxy, לא HTTP_PROXY).
איך להשתמש ב‑Wget עם פרוקסי ב‑Windows ומאחורי חומות אש ארגוניות
רוב המאמרים בנושא נעצרים ב־"תתקינו עם Chocolatey". אם אתם ב‑Windows או מאחורי פרוקסי ארגוני, שם הבעיות רק מתחילות.
איפה Windows מחפש את .wgetrc
התיעוד של GNU אומר ש‑Wget קורא את $HOME/.wgetrc אלא אם משתנה הסביבה WGETRC מפנה למקום אחר. ב‑Windows, $HOME עשוי להיות ממופה ל‑%USERPROFILE% (למשל C:\Users\alice), או שלא — תלוי אם אתם משתמשים ב‑build של Chocolatey, ב‑MSYS2, ב‑Git Bash או בבינארי עצמאי.
ההמלצה שלי: לא לנחש, אלא להשתמש בדגל --config כדי לקבל התנהגות דטרמיניסטית:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
כדי לבדוק אם ה‑build שלכם קורא קובץ הגדרות ממיקום מסוים, צרו קובץ בדיקה שמצביע על פרוקסי שידוע כלא תקין:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
ואז הפעילו:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
אם Wget מנסה להתחבר ל‑127.0.0.1:3128, סימן שהוא קרא את הקובץ.
הגדרת משתני סביבה של פרוקסי ב‑Windows
CMD (לסשן הנוכחי בלבד):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (לסשן הנוכחי בלבד):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
קבוע (נשמר אחרי אתחול):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
אחרי setx צריך לפתוח חלון טרמינל חדש. הסשן הנוכחי לא יראה את השינוי.
בעיות נפוצות בפרוקסי ארגוני: קובצי PAC, אימות NTLM, ואיך למצוא את כתובת הפרוקסי
שלושה דברים שגורמים שוב ושוב לבעיות אצל משתמשים בארגונים:
קובצי PAC: ארגונים רבים משתמשים ב‑Proxy Auto-Configuration (PAC) files — סקריפטים מבוססי JavaScript שאומרים לדפדפן איזה פרוקסי להשתמש עבור איזה URL. ל‑Wget אין מנוע JavaScript, ולכן הוא לא יכול לקרוא קובצי PAC. התיעוד של curl אומר את אותו הדבר. הפתרון: פותחים את קובץ ה‑PAC (או שואלים את IT), מאתרים את התוצאה PROXY host:port עבור הדומיין שלכם, ומגדירים את הכתובת הסטטית הזו ב‑Wget.
אימות NTLM: אימות הפרוקסי של Wget מיישם רק Basic auth. אם הפרוקסי הארגוני שלכם דורש NTLM ואתם מקבלים 407 Proxy Authentication Required, אל תבזבזו זמן על ניסיונות שונים של --proxy-user. התקינו את Cntlm — ממסר מקומי שמטפל ב‑NTLM/NTLMv2 ומציג ל‑Wget ממשק Basic auth. Cntlm עדיין מתוחזק (עדכון אחרון אוקטובר 2025, כ‑395 הורדות בשבוע).
עץ החלטה למשתמשי פרוקסי ארגוני:
- נסו
set http_proxy=http://YOUR_PROXY:PORT/והפעילו את Wget. - אם מתקבלת שגיאת
407והארגון משתמש ב‑NTLM → התקינו Cntlm, הגדירו אותו עם פרטי הדומיין שלכם, והפנו את Wget לפורט המקומי של Cntlm (בדרך כללhttp://127.0.0.1:3128/). - אם הארגון משתמש בקובץ PAC → חלצו את
PROXY host:portהאמיתי מתוך קובץ ה‑PAC או בקשו מ‑IT את כתובת הפרוקסי הסטטית.
פורטים נפוצים בפרוקסי ארגוני: 3128 (בסגנון Squid), 8080 (פרוקסי HTTP כללי), 8888 (פרוקסי דיבוג כמו Fiddler/Charles). אלה מוסכמות, לא הבטחות.
בעיות נפוצות כשמשתמשים ב‑Wget עם פרוקסי (עם פלט שגיאות אמיתי)
ועכשיו לחלק שהבטחתי בכותרת. כל הפלטים שלהלן שוחזרו על Wget 1.25.0 (macOS, Homebrew) בתאריך 2026-06-01.
בעיה 1: חסר prefix של http://
יש מדריכים ישנים שטוענים שזה תמיד נשבר. ב‑Wget 1.25.0, ההגדרה http_proxy=127.0.0.1:3128 דווקא עובדת — Wget מוסיף בשקט http://:
Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.
הוא עדיין התחבר לפרוקסי הנכון. אבל אני ממליץ בכל זאת תמיד לכלול את prefix של http:// ואת ה‑slash הסופי. זה מונע עמימות בין גרסאות Wget ומבהיר את התחביר כשיש פרטי התחברות (http://user:pass@host:port/).
בעיה 2: use_proxy=yes לעומת use_proxy=on
בשני הערכים, yes ו‑on, הבדיקות שלי על Wget 1.25.0 עבדו. אבל ערכים לא תקינים נכשלים עם שגיאה ברורה:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
עדיף להשתמש ב‑on לתאימות רחבה ביותר — הוא תואם לתבנית הבוליאנית המתועדת במדריך וגם לרמז השגיאה של Wget עצמו.
בעיה 3: HTTP_PROXY באותיות גדולות מתעלם בשקט
זו הבעיה המתסכלת ביותר כי אין שום שגיאה בכלל. Wget פשוט מתחבר ישירות, כאילו לא הוגדר פרוקסי מעולם.
אותיות גדולות (לא עובד — לא נעשה שימוש בפרוקסי):
HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06-- http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
אותיות קטנות (עובד — ניסיון שימוש בפרוקסי):
http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
רואים את ההבדל? הגרסה עם אותיות גדולות פתרה את example.com ישירות. הגרסה עם אותיות קטנות ניסתה את הפרוקסי. אין אזהרה באף אחד מהמקרים. ל‑curl יש קטע דומה — הוא מקבל אותיות גדולות עבור רוב משתני הפרוקסי, אבל דוחה במפורש את HTTP_PROXY מסיבות אבטחה.
פתרון: תמיד השתמשו ב‑http_proxy ו‑https_proxy באותיות קטנות.
בעיה 4: פרוקסי ישן ב‑.wgetrc גורם ל‑"Connection Refused"
אם אתם (או מנהל המערכת, או image של Docker) השארתם כתובת פרוקסי ישנה בקובץ ההגדרות, תראו משהו כזה:
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
השגיאה מצביעה על כתובת הפרוקסי הישנה, לא על אתר היעד. סדר בדיקה (לפי היררכיית הקדימות):
- בדקו את הפקודה שלכם לדגלי
-eאו לאליאסים ב‑shell - בדקו את
~/.wgetrc(או את הקובץ שמוגדר ב‑WGETRC) - בדקו את קובץ ההגדרות של המערכת (הנתיב מופיע ב‑
wget --version) - בדקו את הסביבה:
env | grep -i proxy
לצורכי דיבוג, --no-config הוא החבר הכי טוב שלכם — הוא אומר ל‑Wget לדלג על כל קובצי ההגדרות:
wget --no-config --spider http://example.com/
אם זה עובד, הבעיה נמצאת באחד מקובצי ההגדרות.
בעיה 5: בלבול בתחביר של פרוקסי ל‑HTTPS
זה תופס הרבה אנשים. כשמגדירים https_proxy, כתובת הפרוקסי עצמה היא בדרך כלל http://, לא https://. זה כי Wget שולח בקשת HTTP CONNECT דרך הפרוקסי כדי ליצור מנהרה עבור סשן ה‑HTTPS המוצפן.
נכון:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget שולח ל‑proxy את CONNECT example.com:443 HTTP/1.1, ואז מעביר את ה‑HTTPS דרך המנהרה.
לא נכון (לכתובות יעד HTTP עם נקודת פרוקסי ב‑HTTPS):
http_proxy=https://127.0.0.1:18082/
wget http://example.com/
Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.
Wget 1.25.0 דוחה לחלוטין https:// ככתובת פרוקסי עבור יעדי HTTP. השתמשו ב‑https_proxy=http://HOST:PORT/ אלא אם הארגון שלכם תיעד במפורש נקודת קצה של פרוקסי ב‑HTTPS ואתם גם בדקתם אותה עם ה‑build שלכם של Wget.
דף פקודות קצר ל‑Wget עם פרוקסי (שווה לשמור בסימניות)
שמרו את הטבלה הזו. היא מרכזת במקום אחד את כל הדגלים וההנחיות של Wget שקשורים לפרוקסי.
| דגל / הנחיה | הקשר | דוגמה | הערות |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on הוא הבחירה הבטוחה ביותר; חלק מה‑builds מקבלים גם yes |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | לכלול prefix של http:// ו‑/ בסוף |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | כתובת הפרוקסי בדרך כלל היא http:// גם עבור יעדי HTTPS |
--proxy-user | CLI | --proxy-user=admin | גובר על user:pass@ שמוטמע בכתובת |
--proxy-password | CLI | --proxy-password=secret | גלוי ב‑ps — הימנעו משימוש במערכות משותפות |
--no-proxy | CLI | --no-proxy | עוקף את כל הגדרות הפרוקסי מכל מקור |
--no-config | CLI | --no-config | מדלג על כל קובצי ההגדרות — שימושי לדיבוג |
--config=FILE | CLI | --config=/tmp/wgetrc | נתיב הגדרות דטרמיניסטי — מצוין ל‑Windows ול‑CI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | בקובץ ההגדרות יש רווחים סביב =; במשתנה סביבה משתמשים באותיות קטנות |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | אותו פורמט כמו http_proxy |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | להורדות FTP |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | רשימת דומיינים מופרדת בפסיקים |
proxy_user | .wgetrc | proxy_user = admin | מקביל ל‑--proxy-user |
proxy_password | .wgetrc | proxy_password = secret | להגן על הקובץ עם chmod 600 |
מתי Wget + פרוקסי הוא לא הכלי הנכון (ומה להשתמש במקום)
אחרי כל ההגדרות האלה, הנה גישה קצת נגד הזרם: לפעמים פשוט לא צריך להתאמץ.
הרבה אנשים שמחפשים "wget proxy" לא באמת מנסים להוריד קובץ אחד. הם מנסים לאסוף נתונים מובנים מאתרים — מחירי מוצרים, רשימות אנשי קשר, נדל״ן — ופשוט בחרו ב‑Wget כי זה הכלי שהם מכירים בשורת הפקודה. הבעיה היא ש‑Wget נותן HTML גולמי. עדיין צריך לנתח אותו, לנקות אותו ולהפוך אותו למבנה. ואם אתם גם מחליפים פרוקסים כדי להימנע מחסימות, עכשיו אתם מנהלים גם רשימת פרוקסים, גם סקריפט הורדה, גם parser וגם צינור ייצוא.
| המטרה שלכם | הכלי המתאים ביותר | למה |
|---|---|---|
| הורדת קובץ אחד דרך פרוקסי | wget עם דגלי פרוקסי | פשוט, פקודה אחת |
| שיקוף אתר או תיקייה דרך פרוקסי | wget --recursive + הגדרת פרוקסי | הורדה רקורסיבית היא אחד היתרונות המרכזיים של Wget |
| חילוץ נתונים מובנים (טבלאות, רשימות, אנשי קשר) | Thunderbit | Wget נותן HTML גולמי — עדיין צריך לנתח אותו. Thunderbit קורא את הדף ב‑AI ומוציא נתונים מובנים ל‑Excel, Google Sheets, Airtable או Notion בלי קוד. הסריקה בענן מטפלת בסיבוב IP ובהגנות נגד בוטים, כך אפשר לדלג לגמרי על הגדרת פרוקסי. |
| קריאות REST API דרך פרוקסי | curl | שליטה טובה יותר ב‑headers, תמיכה מובנית ב‑JSON, ותמיכה ב‑SOCKS5 |
| איסוף נתונים מתוזמן ומתמשך | Thunderbit Scheduled Scraper או cron + wget | Thunderbit מתאים את עצמו כשהפריסה של הדף משתנה; סקריפטים של cron + wget נשברים בשקט |
Wget מצוין להורדות קבצים. אבל תהליך של "להגדיר פרוקסי → להחליף IPs → להוריד HTML → לכתוב parser → לייצא לגיליון" כולל יותר מדי חלקים נעים כשמה שבאמת רוצים הוא טבלה של נתונים. אם זה נשמע כמו המצב שלכם, התוסף שלנו ל‑Chrome מטפל בכל הצינור הזה בשני קליקים. למידע נוסף על הגישה הזו, ראו את המדריכים שלנו על AI web scraping ועל web scraping without coding.
אבל אם המטרה שלכם היא "להוריד קובץ ZIP דרך פרוקסי ארגוני" — Wget עדיין הכלי הנכון, ועכשיו אתם יודעים איך להגדיר אותו כמו שצריך.
נקודות מרכזיות לזכור
הגרסה הקצרה:
- ארבע שיטות, קדימות ברורה: דגלי CLI גוברים על קובץ משתמש, שגובר על קובץ מערכת, שגובר על משתני סביבה.
--no-proxyגובר על הכול. - תמיד השתמשו באותיות קטנות עבור משתני סביבה (
http_proxy, לאHTTP_PROXY). אותיות גדולות פשוט מתעלמות בשקט. - תמיד לכלול
http://בכתובת הפרוקסי, גם עבורhttps_proxy. נקודת הקצה של הפרוקסי היא HTTP; היא מעבירה HTTPS דרך CONNECT. - להשתמש ב‑
onלערכים בוליאניים ב‑.wgetrcובדגלי-e. זו הבחירה הבטוחה ביותר בין גרסאות Wget. - משתמשי Windows: השתמשו ב‑
--config=C:\path\to\wgetrcכדי להימנע מאי־בהירות של קובץ ההגדרות. השתמשו ב‑set(ב‑CMD) או ב‑$env:(ב‑PowerShell) למשתני פרוקסי של הסשן. - משתמשי פרוקסי ארגוני: Wget לא קורא קובצי PAC ולא תומך ב‑NTLM באופן מובנה. אם צריך, השתמשו ב‑Cntlm כממסר מקומי.
- שמרו בסימניות את דף הפקודות למעלה — זה יחסוך לכם קריאה מחדש של כל המאמר בכל פעם שתצטרכו שם של דגל.
אם המטרה האמיתית שלכם היא חילוץ נתונים מובנים, ייתכן ש‑Thunderbit או curl יתאימו יותר. הדיבוג הטוב ביותר הוא זה שלא הייתם צריכים להתחיל בכלל.
שאלות נפוצות
1. האם Wget תומך בפרוקסי SOCKS5?
לא. GNU Wget 1.x תומך רק בפרוקסי ל‑HTTP, HTTPS ו‑FTP. בפרויקט Wget2 הועלתה בקשה לתמיכה ב‑SOCKS5, אבל זו לא אפשרות סטנדרטית ומתועדת. עבור SOCKS5, השתמשו ב‑curl עם הסכמות socks5:// או socks5h://, או עטפו את Wget ב‑proxychains4 כדי לאלץ ניתוב דרך SOCKS.
2. למה הגדרת הפרוקסי שלי מתעלמת כשאני משתמש ב‑HTTP_PROXY באותיות גדולות?
Wget קורא רק שמות משתני סביבה באותיות קטנות (http_proxy, https_proxy, ftp_proxy, no_proxy). גרסאות באותיות גדולות כמו HTTP_PROXY פשוט מתעלמות בשקט — בלי שגיאה, בלי אזהרה. זו אחת הבעיות הנפוצות והמתסכלות ביותר, כי אין שום רמז שמשהו לא בסדר. תמיד השתמשו באותיות קטנות.
3. איך עוקפים את הפרוקסי עבור דומיינים מסוימים?
השתמשו בהנחיה no_proxy, או כמשתנה סביבה או בתוך .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
או ב‑~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
הדומיינים מופרדים בפסיקים. נקודה מובילה (.mycompany.com) מתאימה לכל תתי-הדומיינים.
4. אפשר להשתמש ב‑Wget עם פרוקסים מתחלפים?
ל‑Wget עצמו אין מנגנון מובנה להחלפת פרוקסי. יש לכם שתי אפשרויות: להשתמש בספק פרוקסי שמחליף IP בצד השרת (כך תמיד פונים לאותה כתובת שער, אבל כתובת ה‑IP היוצאת משתנה), או לכתוב סקריפט shell שבוחר פרוקסי אקראי מרשימה ומעביר אותו בכל הרצה דרך -e http_proxy=.... לכל דבר מורכב יותר — החלפה אוטומטית, לוגיקת retry, טיפול בהגנות נגד בוטים — כלי ייעודי לסריקה בדרך כלל יתאים יותר.
5. מה ההבדל בין http_proxy ל‑https_proxy ב‑Wget?
http_proxy משמש כשכתובת היעד היא http://. https_proxy משמש כשכתובת היעד היא https://. בשני המקרים, כתובת הפרוקסי עצמה היא בדרך כלל http://. עבור יעדי HTTPS, Wget שולח דרך הפרוקסי בקשת HTTP CONNECT כדי להקים מנהרה, וההצפנה עצמה של HTTPS מתבצעת מקצה לקצה בין Wget לשרת היעד. הפרוקסי רואה את שם המארח (מתוך בקשת CONNECT) אבל לא יכול לקרוא את התעבורה המוצפנת.
נסו את Thunderbit ל‑AI Web Scraping Get Started Free
למידע נוסף
