cURL מותקן בכ־20 מיליארד התקנות ברחבי העולם לפי ההערכות — הוא מובנה כברירת מחדל ב-macOS, ברוב הפצות Linux, וב-Windows 10/11. ובכל זאת, אם תשאלו עשרה מפתחים איך לנתב בקשת cURL דרך פרוקסי כמו שצריך, תקבלו עשר תשובות מעט שונות, ולפחות חצי מהן יישברו ברגע שנכנסים לתמונה אימות או SOCKS.
זה בדיוק הפער שאני רוצה לסגור כאן. רוב המדריכים מראים לכם פקודה אחת, אומרים שזה עובד, וממשיכים הלאה. הם לא מראים איך לוודא שהפרוקסי באמת עושה משהו (ספוילר: לפעמים הוא לא), ובטח לא מלווים אתכם דרך קודי השגיאה שמופיעים ברגע שהתצורה סוטה אפילו קצת מהמסלול הנוח. המדריך הזה מכסה את כל הטווח — פרוקסי HTTP/HTTPS, SOCKS4/SOCKS5/socks5h, משתני סביבה (והמלכודות המאוד ספציפיות שלהם), טבלת פתרון תקלות מסודרת, ומה עושים כש-cURL ופרוקסי פשוט כבר לא מספיקים.
מה זה cURL ולמה בכלל להשתמש בו עם פרוקסי?
cURL הוא כלי שורת פקודה להעברת נתונים אל כתובת URL וממנה. זה הכול — בלי ממשק גרפי, בלי קישוטים, רק תוכנה שמדברת HTTP, HTTPS, FTP ועוד כמה פרוטוקולים. הקריאה הכי בסיסית נראית כך:
curl https://example.com
הפקודה הזו מביאה את הדף ומדפיסה את ה-HTML הגולמי למסוף. שימושי בפני עצמו, אבל הסיבה האמיתית שמפתחים ומשתמשים עסקיים טכניים פונים ל-cURL היא בדיקת API-ים, איסוף נתונים מהאינטרנט, בדיקת תוכן שמוגבל לפי אזור, והרצת בקשות בתוך צינורות CI/CD.
פרוקסי יושב בין המחשב שלכם לבין שרת היעד, ומעביר את הבקשה בשמכם. לשרת היעד יופיע ה-IP של הפרוקסי, לא שלכם. זה חשוב מכמה סיבות לגיטימיות: בדיקה איך האתר נראה ממדינה אחרת, עקיפת מגבלות קצב בזמן QA, או ניתוב תעבורה דרך שער תאגידי שהארגון מחייב. cURL תומך בכל משפחת פרוטוקולי הפרוקסי — HTTP, HTTPS, SOCKS4 ו-SOCKS5 — והדגלים שתראו שוב ושוב במדריך הזה הם -x / --proxy (כתובת הפרוקסי עצמה), -v (פלט מפורט, החבר הכי טוב שלכם לדיבוג), ו--k (דילוג על אימות SSL, שעדיף כמעט לעולם לא להשתמש בו מחוץ לבדיקה).
הערה קצרה לפני שממשיכים: המדריך הזה עוסק במכניקה הרשתית של שימוש בפרוקסי עם cURL. הוא לא נותן רשות להתעלם מתנאי השימוש של אתר יעד או ממדיניות האבטחה של הארגון. פרוקסי משנה את נתיב הרשת — לא את מה שמותר או אסור.
לפני שמתחילים
רמת קושי: מתחילים עד ביניים זמן נדרש: כ-15 דקות לעבור על הדוגמאות המרכזיות מה צריך:
- cURL מותקן (בדקו עם
curl --version— אם אתם על macOS, Linux או Windows 10/11, הוא כמעט בוודאות כבר שם) - פרטי פרוקסי מהספק: host, port, protocol (HTTP/HTTPS/SOCKS), ו-username/password אם נדרש
- מסוף/טרמינל (Terminal ב-macOS, כל shell ב-Linux, PowerShell או CMD ב-Windows)
אם cURL לא מותקן מסיבה כלשהי, זה פקודה אחת: brew install curl ב-macOS דרך Homebrew, sudo apt install curl ב-Debian/Ubuntu, או sudo yum install curl ב-RHEL/CentOS. ב-Windows הוא מובנה במערכת מאז Windows 10 build 17063.
לאורך המדריך אשתמש בערכי דמה — proxy.example:8080 לכתובת הפרוקסי ו-user:pwd לפרטי התחברות. החליפו אותם בפרטי הפרוקסי האמיתיים שלכם, ואל תדביקו פרטי גישה אמיתיים בהיסטוריית shell, בצילום מסך או בהודעת Slack. ראיתי יותר מדי סיסמאות של פרוקסי שנחשפו ב-Slack, הרבה מעבר למה שהייתי רוצה להודות.
איך להשתמש ב-cURL עם פרוקסי HTTP או HTTPS
זו התצורה הנפוצה ביותר, והיא גם זו שתשתמשו בה ברוב המכריע של משימות הפרוקסי.
שימוש בדגל -x / --proxy
התחביר הבסיסי נראה כך:
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x ו---proxy עושים בדיוק אותו דבר — בחרו את מה שקל לכם לזכור. מכיוון ש-HTTP הוא סכמת הפרוקסי ברירת המחדל של cURL, אפשר טכנית להשמיט את הקידומת http:// ולכתוב רק proxy.example:8080. אני עדיין ממליץ לכתוב אותה במפורש, כי בעוד שישה חודשים תודו לעצמכם על הבהירות.
עטפו את כל ה-URL במרכאות כפולות. אם הסיסמה שלכם מכילה @, # או &, מחרוזת לא מצוטטת תתפרק על ידי ה-shell עוד לפני ש-cURL בכלל יראה אותה.
חיבור דרך פרוקסי HTTPS
חלק מהספקים מצפינים את החיבור אל הפרוקסי עצמו באמצעות TLS, ולא רק את החיבור מהפרוקסי אל היעד. זה שונה מלגלוש לאתר HTTPS — פרוטוקול הפרוקסי ופרוטוקול היעד הם משתנים בלתי תלויים. כדי לציין זאת:
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
אם מופיעה כאן שגיאת תעודה, אל תתפתו להוסיף -k ולהמשיך הלאה. הדגל הזה מבטל לחלוטין את אימות תעודת ה-SSL, וזה אולי בסדר לבדיקת לוקאלית של חמש דקות — אבל רע מאוד לכל דבר שנוגע לייצור או לנתוני משתמש אמיתיים. אם אתם עובדים מול פרוקסי ארגוני שמבצע TLS interception (תצורת MITM, נפוצה בסביבות ארגוניות), הפתרון הנכון הוא לייבא את תעודת ה-CA של הפרוקסי, לא לבטל את האימות.
אימות עם --proxy-user
אפשר גם להפריד את פרטי ההתחברות לדגל משלהם במקום לדחוס אותם לתוך ה-URL:
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
שימו לב שה--U הגדול אינו אותו דבר כמו אימות מול אתר היעד (-u / --user, באות קטנה) — בלבול ביניהם הוא דרך מהירה לשלוח את סיסמת הפרוקסי ליעד הלא נכון. בסביבות ארגוניות שמשתמשות ב-NTLM או Digest במקום Basic, הוסיפו --proxy-ntlm או --proxy-digest לצד --proxy-user.
איך להשתמש ב-cURL עם פרוקסי SOCKS: SOCKS4 מול SOCKS5 מול socks5h
פרוקסי SOCKS פועל ברמה נמוכה יותר מפרוקסי HTTP — הוא לא מתעניין באיזה פרוטוקול אתם מעבירים דרכו, ולכן הוא שימושי לתעבורה שאינה HTTP, לחיבורי Tor, ולכל מה שרגיש לפרטיות. רוב המדריכים המתחרים נותנים כאן פקודה אחת וממשיכים. זו טעות, כי ההבדלים בין SOCKS4, SOCKS5 ו-socks5h:// באמת חשובים.
| תכונה | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| תמיכה ב-TCP | כן | כן | כן |
| תמיכה ב-UDP | לא | כן | כן |
| אימות | לא | כן | כן |
| פתרון DNS מרחוק | לא | לא (DNS מקומי) | כן (הפרוקסי פותר) |
| תואם Tor | לא | מסוכן (דליפת DNS) | כן |
השורה של DNS היא זו שבאמת מפילה אנשים. עם socks5://, המחשב שלכם פותר את שם המארח לפני שהוא מוסר את החיבור לפרוקסי — כלומר מפענח ה-DNS המקומי שלכם (ובהרחבה גם ספק האינטרנט) רואה בדיוק לאיזה דומיין ניסיתם להגיע, גם אם התעבורה עצמה עוברת דרך הפרוקסי. socks5h:// מתקן את זה בכך שהפרוקסי מבצע את פתרון שם המארח בעצמו, כך ששום דבר על היעד לא דולף מקומית. זו בדיוק הסיבה שהמסמכים של Tor מתעקשים על socks5h:// — שימוש ב-socks5:// רגיל מבטל חלק גדול מהאנונימיות ש-Tor אמור לספק.
כך כל גרסה נראית ב-cURL:
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
אלא אם יש לכם סיבה ספציפית לא, עדיף להתחיל תמיד עם socks5h://. זה לא עולה כלום, ומונע דליפה שאחרת לא הייתם מבחינים בה בכלל.
הגדרת פרוקסי באמצעות משתני סביבה (ואיך להימנע מהמלכודות)
להוסיף -x לכל פקודה מהר מאוד נהיה מעיק. משתני סביבה מאפשרים להגדיר את הפרוקסי פעם אחת לכל סשן shell, וכל קריאת cURL שאחריה יורשת אותו אוטומטית — המדריך של cURL מתעד את http_proxy, HTTPS_PROXY, ALL_PROXY ו-NO_PROXY כסט הנתמך.
הבסיס
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
כאן יש את החלק שמבלבל אנשים שוב ושוב: שם המשתנה מתייחס לפרוטוקול של כתובת היעד, לא לפרוטוקול של הפרוקסי. לכן http_proxy שולט בבקשות ל-URLs עם http://, ו-HTTPS_PROXY שולט בבקשות ל-https:// — אפשר לכוון את שניהם לאותו שרת פרוקסי HTTP, וזה לגמרי תקין.
עקיפה עם NO_PROXY
export NO_PROXY="localhost,127.0.0.1,.internal.example"
מופרד בפסיקים, והנקודה בתחילת .internal.example פועלת כ-wildcard לכל תת-דומיין. NO_PROXY עוקף הכול — גם אם -x מוגדר במפורש בשורת הפקודה, התאמה ב-NO_PROXY תגרום לאותה בקשה לדלג על הפרוקסי.
המלכודות שבאמת תופסות אנשים
- שוכחים
export. אם פשוט מקלידיםhttp_proxy=http://...בליexport, המשתנה נשאר רק ב-shell הנוכחי והוא שקוף לגמרי ל-cURL כתהליך צאצא. מניסיון, זו הסיבה הנפוצה ביותר להודעות תמיכה בסגנון "הפרוקסי לא עובד". - רגישות לאותיות. cURL בודק במיוחד קודם כל את
http_proxyבאותיות קטנות ונותן לו עדיפות אם שתי הגרסאות קיימות. כלים אחרים קוראים רק uppercase. אם אתם מנסים להבין למה משתנה "לא נקלט", בדקו אם יש כפילות עם אותיות שונות. - מלכודת האליאס של PowerShell. ב-PowerShell 5.1, הקלדה של
curlבכלל לא מפעילה את cURL — אלא אתInvoke-WebRequest, כלי אחר לגמרי עם דגלים אחרים. אם-xזורק שגיאות מוזרות ב-Windows, הקלידו במפורשcurl.exeכדי לוודא שאתם באמת מריצים cURL. - הבדלי תחביר ב-Windows. ב-CMD משתמשים ב-
set http_proxy=...; ב-PowerShell משתמשים ב-$env:http_proxy = "...". ערבוב בין התחבירים בסשנים שונים הוא דרך קלה לאבד אחר צהריים. - משתנים ישנים.
unset http_proxyו-unset https_proxyמנקים תצורת פרוקסי מתה שממשיכה לנתב כל בקשה — וכמובן להיכשל — בשקט.
למעבר מהיר בין מצב עם פרוקסי וללא פרוקסי, שני aliases ב-.bashrc חוסכים זמן אמיתי:
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
לגרום ל-cURL להשתמש תמיד בפרוקסי (קובץ קונפיגורציה)
אם אתם מאחורי פרוקסי ארגוני 95% מהזמן, קובץ .curlrc (במערכות Unix-like, בתוך תיקיית הבית) או _curlrc (ב-Windows, בתיקיית app-data) מגדיר ברירת מחדל קבועה בלי לגעת בכלל במשתני סביבה:
proxy="http://proxy.example:8080"
לכל בקשה חד-פעמית שבה צריך לעקוף זאת, --noproxy "*" מחליף את ההגדרה עבור אותה הפעלה בלבד. סדר הקדימויות הוא בדרך כלל דגל שורת פקודה > משתנה סביבה > קובץ קונפיגורציה, כך ש--x בשורת הפקודה תמיד מנצח אם יש התנגשות.
אזהרה חשובה: אל תשימו סיסמה בטקסט גלוי בתוך .curlrc אם הקובץ עשוי להסתנכרן, להיגבות או להיכנס בטעות ל-repo. ב-CI pipelines, עדיף להשתמש במנהל הסודות של הפלטפורמה ולשנע את הפרטים כמשתני סביבה מוסתרים.
איך לבדוק שהפרוקסי באמת עובד
זה החלק שכמעט כל שאר המדריכים מדלגים עליו, וזה גם החלק שחוסך הכי הרבה זמן דיבוג. להגדיר פרוקסי ולהניח שהוא מנתב את התעבורה זה איך אנשים מבלים שעות בניסיון להבין למה scraper כלל לא השתמש בפרוקסי מלכתחילה.
שיטה 1: להשוות את ה-IP היוצא
הפעילו את אותה בקשה שמחזירה IP פעמיים — פעם ישירות, ופעם דרך הפרוקסי — והשוו:
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
אם שתי הפקודות מחזירות את אותה כתובת IP, הפרוקסי שלכם לא עושה שום דבר. בדקו את תחביר הדגל, את משתני הסביבה, או אם NO_PROXY במקרה תואם ליעד שלכם.
שיטה 2: לקרוא את הפלט המפורט
הוסיפו -v לכל בקשת פרוקסי, ו-cURL ידפיס את כל תהליך ה-handshake:
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
חפשו שורה כמו * Connected to proxy.example (xx.xx.xx.xx) port 8080, ואחריה > CONNECT httpbin.org:443 HTTP/1.1 ובסוף < HTTP/1.1 200 Connection established. הרצף הזה — התחברות לפרוקסי ואז יצירת CONNECT tunnel ליעד — הוא שיטת HTTP CONNECT בפעולה, וזה בדיוק מה שאמור לקרות כאשר יעד HTTPS מנותב דרך פרוקסי HTTP. אם שורת ה-CONNECT לא מופיעה בכלל, דגל הפרוקסי לא מיושם. רק שימו לב: השתמשו ב--v רק בזמן דיבוג פעיל, והסירו מידע רגיש לפני שמשתפים את הפלט — מצב verbose יכול להדפיס פרטי התחברות של הפרוקסי בטקסט גלוי.
שיטה 3: השוואה זה לצד זה
לבדיקות גיאוגרפיות, שמרו את שתי התוצאות לקבצים והשוו ביניהן:
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
אם גוף התגובה (או הכותרות, במקרה של תוכן מוגבל אזורית) שונים, יש לכם אישור חזותי שהפרוקסי באמת משנה את נתיב הרשת — דרך מהירה ופשוטה להסיר ספק לפני שמעמיקים הלאה.
פתרון תקלות לשגיאות פרוקסי נפוצות ב-cURL
רוב המדריכים מנפנפים בזה ומזכירים -k פעם אחת. הנושא הזה ראוי לטבלת ייחוס אמיתית.
| שגיאה | סיבה סבירה | תיקון |
|---|---|---|
curl: (7) Failed to connect | host/port של הפרוקסי שגויים, או שהפרוקסי למטה | בדקו את הכתובת; בדקו קישוריות גולמית עם telnet host port או nc -zv host port |
407 Proxy Authentication Required | פרטי התחברות חסרים או שגויים | הוסיפו --proxy-user user:pass; בדקו אם הספק דורש NTLM/Digest/Negotiate במקום Basic |
curl: (56) Recv failure: Connection reset by peer | הפרוקסי ניתק את החיבור באמצע ההעברה | בדקו יציבות מול הספק; אם זה פרוקסי שמסיים TLS, ודאו טיפול נכון בתעודות במקום לבטל אותו בכוח |
curl: (28) Connection timed out | חסימת firewall, פרוקסי מיושן, או port שגוי | הריצו env | grep -i proxy כדי לבדוק משתנים שנשארו; נקו משתנים ישנים; בדקו בקשה ישירה כדי לבודד את הסיבה |
| כשל באימות תעודה | תעודת פרוקסי לא מהימנה או שמבצעת interception | השיגו את שרשרת ה-CA הנכונה והשתמשו ב---proxy-cacert; הימנעו מביטול אימות מחוץ לבדיקה חד-פעמית |
הצעד האוניברסלי הראשון לכל אחת מהבעיות האלה הוא להוסיף -v. זה יראה לכם בדיוק איפה החיבור נשבר — פתרון DNS, חיבור TCP, handshake של TLS, או חילופי אימות מול הפרוקסי — במקום להשאיר אתכם לנחש לפי קוד שגיאה בן שלוש ספרות.
בפרוקסי ארגוני במיוחד, --proxy-ntlm ו---proxy-negotiate מכסים שיטות אימות של דומיין Windows. דבר אחד ש-cURL באמת לא יודע לעשות באופן מובנה: קבצי PAC (סקריפטי Proxy Auto-Config שחלק מהארגונים משתמשים בהם כדי להקצות פרוקסי דינמית). אם הארגון שלכם משתמש באחד כזה, תצטרכו לחלץ ידנית את host וה-port האמיתיים — בדרך כלל מהגדרות הרשת של הדפדפן — כי ל-cURL אין parser מובנה ל-PAC.
מתי cURL + פרוקסי כבר לא מספיקים
cURL עם פרוקסי מטפל יפה ב-HTML סטטי, קריאות ל-REST API, ובמשיכת נתונים פשוטה — בערך הכי טוב שאפשר. איפה שהוא נשבר זה מול ההגנות האהובות על האינטרנט המודרני: אפליקציות SPA שמורנדרות ב-JavaScript, מערכות anti-bot כמו Cloudflare או Akamai, וחומות CAPTCHA. תכוונו cURL לאפליקציית React או Vue שמאחורי אחת מהמערכות האלה, ותקבלו בחזרה <div id="root"></div> ריק — טכנית בקשה מוצלחת, מעשית נתונים חסרי תועלת. זו לא באג ב-cURL. הוא פשוט לא דפדפן, ומעולם לא טען שהוא כזה.
אם כבר נוח לכם להריץ cURL מהטרמינל ואתם נתקלים בקיר הזה, הצעד הטבעי הבא הוא לא לעבור לסט כלים אחר לגמרי — אלא להוסיף שכבה שמטפלת עבורכם ברינדור ובמבנה. בדיוק את הפער הזה הכלים למפתחים של Thunderbit נועדו לסגור.
| תרחיש | cURL + פרוקסי | Thunderbit API (POST /extract) |
|---|---|---|
| דף HTML סטטי | עובד מצוין | עובד, וגם מחזיר נתונים מובנים |
| SPA שמורנדרת ב-JS | מקבל HTML ריק/חלקי | renderMode: "full" מטפל ב-JS |
| Anti-bot / CAPTCHA | נחסם | טיפול מובנה |
| פלט נתונים מובנים | HTML גולמי — צריך לפרסר בעצמכם | JSON לפי הסכמה שלכם |
| עיבוד אצווה (100+ URLs) | לולאה ידנית + rate limiting משלכם | POST /batch/extract |
ה-Open API של Thunderbit חושף endpoint של /extract שמחזיר JSON מותאם לסכמה ישירות מדפים כבדי-JS, ו-endpoint של /distill להמרה נקייה ל-Markdown — את שניהם אפשר להפעיל מאותו סשן טרמינל שבו אתם כבר מריצים פקודות cURL. יש גם שרת MCP לעוזרי קידוד מבוססי AI כמו Claude או Cursor, וגם CLI (npx @thunderbit/thunderbit-cli extract <url> --schema fields.json) אם אתם מעדיפים להישאר לגמרי בתוך סקריפטים. שום דבר מזה לא מחליף את cURL במשימות שבהן cURL מצטיין — זה פשוט ממשיך מאיפה ש-cURL מבנית כבר לא יכול להתקדם. אם אתם רוצים תמונה רחבה יותר של איפה מופק מידע בעזרת AI נכנס לעומת כתיבת לוגיקה משלכם, המאמר שלנו על AI web scraping וההשוואה של best AI web scrapers מסבירים זאת לעומק, והמאמר שלנו על web scraping without coding הוא פתיח טוב אם אתם מגיעים לזה מזווית עסקית ולא הנדסית.
לסיכום
להביא את cURL והפרוקסי לדבר זה עם זה בצורה נכונה לא קשה ברגע שמבינים איפה באמת נקודות הכשל — ומסתבר שכמעט אף אחת מהן היא לא הפרוקסי עצמו. שוכחים export. מתבלבלים בין -u ל--U. משתמשים ב-socks5:// כשבעצם התכוונתם ל-socks5h://. מריצים את האליאס curl של PowerShell במקום curl.exe. כל אחד מאלה מייצר שגיאה מבלבלת וכללית לכאורה, שאין לה שום קשר לספק הפרוקסי.
ההרגל שחוסך הכי הרבה זמן: קודם מאמתים, אחר כך פותרים תקלות. הריצו בדיקת IP echo, הציצו בפלט של -v, וודאו שהפרוקסי בכלל נמצא בנתיב הבקשה לפני שאתם מניחים שמשהו נשבר בהמשך. וכשאתר היעד מתחיל לשלוח לכם JavaScript במקום HTML נקי, זו לא בעיה של cURL לפתור עם עוד דגלים — זה סימן שכדאי לעבור לכלי שנבנה לרינדור, כמו Thunderbit API, שמציעה גם שכבה חינמית אם תרצו לראות בעצמכם את ההבדל בין JSON-יציאה לבין HTML גולמי.
שאלות נפוצות
האם cURL משתמש בפרוקסי כברירת מחדל?
לא. אלא אם הגדרתם משתני סביבה כמו http_proxy / HTTPS_PROXY או קובץ .curlrc, cURL מתחבר ישירות ליעד בלי שום פרוקסי.
איך עוצרים את cURL משימוש בפרוקסי עבור בקשה אחת?
הוסיפו --noproxy "*" לאותה פקודה ספציפית. כדי לנקות את זה לכל סשן ה-shell, הריצו unset http_proxy && unset https_proxy.
אפשר להשתמש ב-cURL עם פרוקסי מתחלפים?
כן — אם הספק מציע gateway מתחלף (נקודת קצה אחת שמקצה IP חדש לכל בקשה), פשוט כוונו את -x לאותה כתובת gateway כמו לכל פרוקסי אחר. ללוגיקת רוטציה מורכבת יותר מול יעדים שמורנדרים ב-JS, שכבת API כמו זו של Thunderbit מטפלת ברוטציה ובצד של anti-bot מבפנים, כך שאתם לא מנהלים retry logic ידנית.
למה socks5:// חושף את בקשות ה-DNS שלי אבל socks5h:// לא?
עם socks5://, המחשב המקומי פותר את שם היעד עוד לפני שליחת בקשת החיבור לפרוקסי — כלומר שרת ה-DNS של ספק האינטרנט רואה לאיזה דומיין ביקרתם. socks5h:// מעביר את פתרון שם המארח אל הפרוקסי עצמו, כך ששום דבר על היעד לא גלוי מקומית.
האם חוקי להשתמש ב-cURL עם פרוקסי?
השימוש בפרוקסי עצמו חוקי ברוב התחומים המשפטיים. מה שקובע הוא מה עושים איתו — תמיד כבדו את תנאי השימוש של אתר היעד, robots.txt כשיש כזה, וכל חוק רלוונטי להגנת פרטיות. המדריך הזה עוסק במכניקה הטכנית בלבד, לא באישור משפטי לשום מקרה שימוש מסוים.
למידע נוסף
