מהו HTTP Proxy? סוגים, שימושים ואיך הוא משתווה ל‑VPN

פתחו את הגדרות הרשת של טלפון או מחשב נייד, וסביר שתמצאו אפשרות HTTP Proxy עם בחירות כמו כבוי, ידני ואוטומטי. ברירת המחדל הבטוחה היא פשוטה: אם מנהל מערכת מהימן או אפליקציה מסוימת לא נתנו לכם פרטי proxy, אל תמציאו אותם. כתובת proxy היא לא מתג ביצועים ולא מצב פרטיות. היא רק משנה לאן בקשות ה‑HTTP שלכם נשלחות.

מאחורי חלון ההגדרות הקטן הזה מסתתר נושא הרבה יותר רחב. HTTP proxy יכול לאכוף מדיניות ארגונית, לנתב קריאות API של מפתחים, לשמור תגובות משותפות במטמון, או ליצור מנהרה עבור HTTPS. גם reverse proxy יכול לעמוד בצד השני של התקשורת — מול אתר אינטרנט במקום מול המשתמשים שלו. אף אחד מהתפקידים האלה לא הופך חיבור אוטומטית לפרטי, אנונימי, מהיר או מורשה.

המדריך הזה מסביר את הפרוטוקול, לא את כותרות השיווק: מהו HTTP proxy, מה באמת עובר על הקו, במה CONNECT שונה מ‑forwarding רגיל, איפה SOCKS5 ו‑VPN נכנסים לתמונה, ואיך לאבחן בעיות proxy בלי לשנות חמש הגדרות בבת אחת.

מהו HTTP Proxy?

HTTP proxy הוא מתווך שמקבל בקשת HTTP ומנסה לשרת אותה על ידי העברתה הלאה, החזרת תגובה שנשמרה במטמון כשהדבר מותר, או החזרת תגובה משלו. RFC 9110 מגדיר proxy שנבחר על ידי הלקוח כסוכן להעברת הודעות. הלקוח בדרך כלל לומד עליו דרך הגדרות אפליקציה, הגדרות מערכת ההפעלה, קובץ Proxy Auto-Configuration (PAC), או משתני סביבה.

ב‑forward proxy מפורש, הזרימה נראית כך:

client  --->  forward proxy  --->  origin server
        <---                 <---

הלקוח מתחבר קודם ל‑proxy. לאחר מכן ה‑proxy פותח או עושה שימוש חוזר בחיבור אל היעד. ה‑origin בדרך כלל יראה את חיבור הרשת של ה‑proxy כעמית המיידי שלו, אבל זה לבדו לא מוכיח אנונימיות. כותרות, עוגיות, טביעות דפדפן, סשנים מאומתים, התנהגות DNS ויומנים עדיין יכולים לזהות משתמש או ארגון. “ה‑origin רואה כתובת IP שונה” ו‑“המשתמש אנונימי” הן טענות שונות מאוד.

HTTP proxy גם אינו הצפנה. HTTP רגיל נשאר רגיל אלא אם שכבת אבטחה אחרת מגינה עליו. HTTPS יכול לעבור דרך proxy כמנהרת TLS, אבל ההצפנה מגיעה מ‑TLS — לא מהמילה proxy.

איך HTTP Proxy מפורש מטפל בבקשה

ההבדל החשוב מופיע ב‑request target. כשלקוח HTTP/1.1 מדבר ישירות עם origin server, הוא בדרך כלל שולח origin-form:

GET /reports/weekly HTTP/1.1
Host: example.com

כשאותו לקוח שולח בקשת HTTP רגילה ל‑proxy מפורש, RFC 9112 מגדיר absolute-form כדי שה‑proxy יזהה את היעד:

GET http://example.com/reports/weekly HTTP/1.1
Host: example.com

הזרימה הטיפוסית היא:

1. הלקוח בוחר proxy לפי כללי ההגדרה הרלוונטיים שלו.
2. הוא מתחבר ל‑proxy ושולח בקשה שמזהה את ה‑URI היעד.
3. ה‑proxy יכול לאמת את הלקוח, להחיל מדיניות, לבדוק מטמון, או לדחות את הבקשה.
4. אם ההעברה מותרת, ה‑proxy שולח בקשה מתאימה לעבר ה‑origin.
5. התגובה חוזרת דרך ה‑proxy. ה‑proxy יכול להוסיף מטא־נתונים של מתווך, לשנות את ההודעה כשהדבר מותר, לשמור תגובה שניתנת למטמון, או פשוט להעביר אותה הלאה.

למילה “יכול” יש כאן משמעות אמיתית. HTTP מגדיר התנהגות אפשרית וכללי תאימות; הוא לא מבטיח שכל proxy יסנן תוכן, ישמור תגובות, ישכתב כותרות או יסתיר מזהים.

אם ה‑proxy דורש אימות, הוא יכול להשיב 407 Proxy Authentication Required. זה שונה מ‑401 Unauthorized: ‏407 עוסק בפרטי גישה ל‑proxy, בעוד 401 עוסק ב‑origin server. RFC 9110 מגדיר את ההבחנה הזו. גם פרטי התחברות חייבים לעבור בערוץ מוגן מתאים; Basic authentication לא מספקת סודיות בפני עצמה.

HTTPS דרך HTTP Proxy: ‏CONNECT הוא Tunnel, לא הצפנה

עבור יעד HTTPS, הלקוח בדרך כלל מבקש מה‑proxy לפתוח מנהרת TCP באמצעות CONNECT. יעד הבקשה משתמש ב‑authority-form — שם מארח + פורט — ולא ב‑URL מלא:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

אחרי תגובה מוצלחת, החיבור הופך למנהרה. לאחר מכן הלקוח מבצע TLS handshake עם example.com דרך זרם הבתים הזה:

client == TLS ==[ proxy relays bytes ]== TLS endpoint at origin

במודל tunneling רגיל כזה, ה‑proxy יכול לראות מטא־נתוני חיבור כמו משתמש ה‑proxy, היעד, תזמון וספירת בתים, אבל גוף בקשות ותגובות HTTPS מוצפן על ידי TLS. המנהרה עצמה אינה מנגנון ההצפנה. ההבחנה הזו חשובה כשמנתחים כשל: CONNECT יכול להצליח בעוד ש‑TLS handshake מאוחר יותר ייכשל.

בחלק מהרשתות המנוהלות מתבצע TLS interception מורשה. בעיצוב כזה, המתווך מסיים חיבור TLS אחד ופותח חיבור נוסף אל ה‑origin. הלקוח חייב לסמוך על רשות אישורים שנעשה בה שימוש בפריסה הזו. לאחר מכן המתווך יכול לבדוק תוכן HTTP משום שהוא נקודת קצה של TLS, לא משום שכל HTTP proxy מסוגל “לקרוא” HTTPS בקסם. זה צריך להיות נוהל מפורש ומנוהל במכשירים שבשליטה ארגונית. ביטול אימות אישורים אינו תיקון לגיטימי לבעיה בייצור כשמופיעה שגיאת אישור בלתי צפויה.

יש גם גבול אבטחה בצד של ה‑proxy עצמו. מתן אפשרות ל‑CONNECT לכל יעד ולכל פורט עלול להפוך proxy לנתיב אל שירותים שמעולם לא נועד לחשוף. Proxy בסביבת ייצור צריך להגביל יעדים ופורטִים בהתאם למטרתו.

Forward, Reverse, Explicit ו‑Interception Proxies

הכינויים של proxies נהיים מבלבלים כשמאחדים שני צירים שונים לרשימה אחת.

הציר הראשון הוא מי בוחר את המתווך:

• Forward proxy נבחר בשם הלקוח. הוא שולט או מסייע בגישה יוצאת מאותו לקוח או מאותה רשת.
• Reverse proxy, שבמונחי HTTP נקרא gateway, עומד מול אחד או יותר origin servers. המבקרים פונים לשירות הציבורי; ה‑gateway בוחר backend, מסיים TLS, שומר תגובות מתאימות במטמון, או מחיל מדיניות בצד השרת.

הציר השני הוא איך התעבורה מגיעה אל המתווך:

• Explicit proxy מוכר ללקוח דרך ההגדרות. הלקוח מעצב אליו במכוון את הבקשות או פותח אליו מנהרת CONNECT.
• Interception proxy מקבל תעבורה שהרשת הפנתה אליו בלי הגדרת proxy מפורשת רגילה בצד הלקוח.

הכינויים האלה יכולים לחפוף. Forward proxy ארגוני יכול להיות מפורש. Gateway ברשת יכול ליירט תעבורה יוצאת נבחרת. Reverse proxy בדרך כלל שקוף למבקר כקפיצה נפרדת, אף על פי שהוא עדיין השרת שהלקוח מתחבר אליו.

Interception הוא לא פשוט “proxy מפורש בלי מסך ההגדרות”. הוא עלול לשבש הנחות לגבי כתובות יעד, אימות, TLS ו‑path MTU. מדריך ה‑interception של Squid מתעד כמה מהמגבלות התפעוליות הללו. אם הרשת לא יכולה לעמוד בהן, התוצאה היא לעיתים כשל חלקי ומסתורי במקום הודעת שגיאה נקייה (האהובה על כולנו).

מונחים כמו anonymous, elite ו‑high-anonymity שייכים בעיקר לטקסונומיות של ספקים. הם לא יכולות HTTP רשמיות. העריכו את ההתנהגות שאפשר לצפות לה בפועל — כותרות, כתובות יציאה, אימות, לוגים, פתרון DNS ומדיניות tunnel — במקום להתייחס לתווית כאל הבטחת אבטחה.

HTTP Proxy מול SOCKS5 מול VPN

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

שאלה	HTTP proxy	SOCKS5 proxy	VPN
באיזה ממשק הלקוח משתמש?	העברת HTTP ובדרך כלל מנהרת CONNECT	פקודות פרוטוקול SOCKS	מנהרה וירטואלית/רשתית שמנוהלת על ידי מערכת ההפעלה או לקוח ה‑VPN
איזה תעבורה נכללת?	תעבורה מאפליקציות שתומכות ב‑HTTP proxy שהוגדר	TCP, ובנוסף UDP association כשהלקוח והשרת תומכים בכך	תעבורה שנבחרת לפי ניתוב ומדיניות split-tunnel
האם המנגנון מבטיח הצפנת payload?	לא	לא	מנהרת ה‑VPN בדרך כלל מגנה על התעבורה בתוך ההיקף שהוגדר לה; עדיין יש חשיבות לפרוטוקול ולמדיניות
היכן מגדירים זאת בדרך כלל?	אפליקציה, מערכת, PAC/WPAD, או משתני סביבה	לכל אפליקציה או ספרייה בנפרד	מערכת ההפעלה או לקוח ה‑VPN, ולעיתים לכל אפליקציה
מי פותר את DNS של היעד?	תלוי בלקוח, במצב הבקשה ובמימוש	תלוי באופן שבו הלקוח מספק את היעד	תלוי בנתיבי ה‑VPN ובמדיניות ה‑DNS
שאלת ההחלטה הטובה ביותר	האם האפליקציה הזו שתומכת ב‑HTTP צריכה מתווך?	האם האפליקציה צריכה ממשק relay כללי יותר?	אילו נתיבי מכשיר או אפליקציה צריכים להיכנס למנהרת רשת מוצפנת?

SOCKS5 מגדיר CONNECT, BIND ו‑UDP ASSOCIATE. זה הופך אותו לכללי יותר מהעברה ממוקדת HTTP, אבל הוא עדיין לא מבטיח הצפנה או אנונימיות. האבטחה תלויה באימות, בערוץ המוגן החיצוני אם קיים, בהתנהגות נקודות הקצה ובמפעיל.

VPN פועל בדרך כלל בגבול רשת רחב יותר, אבל הטענה “VPN תמיד מעביר כל בית מהמכשיר” אינה נכונה. Split tunneling יכול לכלול או להחריג נתיבים או אפליקציות מסוימות. תיעוד פריסת ה‑VPN של Apple הוא דוגמה אחת לפלטפורמה שתומכת בהתנהגות VPN מוגבלת בהיקפה.

בחרו לפי היקף ואמון, לא לפי תווית של מילה אחת. אם רק לקוח HTTP אחד צריך gateway ארגוני, VPN לכל המכשיר עשוי להיות מיותר. אם כמה אפליקציות צריכות גישה לרשת פרטית, הגדרת proxies נפרדים ל‑HTTP עלולה להיות הפשטה שגויה.

האם להפעיל את הגדרת HTTP Proxy או לכבות אותה?

ברשת ביתית לא מנוהלת, השאירו אותה כבויה אלא אם שירות מהימן שאתם משתמשים בו במכוון מספק את הכתובת, הפורט ושיטת האימות. הפעלה של proxy ציבורי אקראי שולחת תעבורה אל מפעיל שלא הערכתם.

במכשיר עבודה או לימודים מנוהל, פעלו לפי ההנחיות העדכניות של מנהל המערכת. אל תסירו הגדרה לא מוכרת לפני שבדקתם ניהול מכשיר, לקוח VPN/אבטחה, או את מנהל המערכת. Proxy יכול להיות חלק ממנגנון בקרת גישה; מחיקה שלו עלולה לשבור גישה או להפר מדיניות גם אם גלישה רגילה נראית תקינה אחר כך.

“אוטומטי” מתייחס בדרך כלל לכתובת PAC או למנגנון גילוי אוטומטי. קובץ PAC הוא JavaScript שיכול להחזיר מסלולים שונים ל‑URLs שונים — למשל, להפנות hostname פנימי דרך proxy, אבל להתחבר ישירות לאתר ציבורי. המשמעות היא שדפדפן יכול לעבוד ליעד אחד ולהיכשל ביעד אחר עם אותה הגדרה גלויה.

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

• האם ההגדרה מנוהלת על ידי הארגון או הוזנה על ידי המשתמש?
• האם היא ידנית, PAC/אוטומטית, או ספציפית לאפליקציה?
• אילו פרוטוקולים ויעדים היא מכסה?
• האם קיימים כללי עקיפה כמו NO_PROXY או “exclude simple hostnames”?
• איזו הגדרה מנצחת כשאפליקציה, מערכת, סביבה ו‑PAC לא מסכימים?

השאלה האחרונה תלויה בלקוח הספציפי. Chrome/Chromium בדרך כלל משתלב עם פתרון ה‑proxy של הפלטפורמה, אבל יש לו גם כללים מתועדים משלו. Firefox יכול להשתמש בהגדרות חיבור משלו. כלים משורת הפקודה לעיתים קוראים משתני סביבה באופן עצמאי. לכן proxy מוגדר במערכת אינו מוכיח שכל אפליקציה אכן משתמשת בו.

שימוש ב‑HTTP Proxy ב‑curl וב‑Python

לבקשה חד־פעמית, האפשרות --proxy של curl הופכת את הבחירה לגלויה:

curl --fail-with-body --show-error \
  --proxy 'http://proxy.example:8080' \
  'https://api.example.com/health'

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

curl --fail-with-body --show-error \
  --proxy 'http://proxy.example:8080' \
  --proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
  'https://api.example.com/data'

לאוטומציה קבועה, יש להיכשל סגור. אם המדיניות אומרת שהבקשה חייבת לעבור דרך proxy, אל תתפסו שגיאת proxy ואל תנסו בשקט חיבור ישיר. fallback ישיר עלול לחשוף את כתובת היציאה של הלקוח או לעקוף מדיניות גישה.

Python Requests מקבלת מיפוי מפורש:

import os
import requests

proxy_url = os.environ["APP_PROXY_URL"]
proxies = {
    "http": proxy_url,
    "https": proxy_url,
}

response = requests.get(
    "https://api.example.com/health",
    proxies=proxies,
    timeout=(5, 20),
)
response.raise_for_status()
print(response.json())

המפתח https למעלה אומר “השתמש ב‑proxy הזה עבור יעד HTTPS”; הוא לא בהכרח אומר שהלקוח יוצר TLS אל ה‑proxy. כתובת proxy מסוג http:// עדיין יכולה לקבל CONNECT ולבצע tunneling של TLS ל‑origin. Requests גם מתעדת תמיכה במשתני סביבה ובטיפול ב‑CA bundle במדריך ה‑proxy המתקדם שלה.

התנהגות משתני סביבה אינה אחידה לחלוטין. curl מקבל בכוונה את http_proxy באותיות קטנות, בעוד שמשתנים וכלים אחרים עשויים לקבל צורות כתיב שונות. התאמת NO_PROXY, תמיכה ב‑CIDR, נקודות מובילות, פורטים, התנהגות loopback והעדיפויות משתנות. התייחסו לתיעוד של סביבת הריצה המדויקת כחוזה. אל תניחו שפקודת curl שעובדת מוכיחה ש‑Requests, Go, דפדפן ומכולה יבחרו באותו נתיב.

כדאי גם להימנע מה“תיקון” הזה:

# אל תשתמשו בזה כדי להסתיר בעיית אישור בייצור.
requests.get("https://api.example.com", verify=False)

אם proxy לבדיקה מאושרת משתמש ב‑CA פרטי, יש להתקין או להפנות ל‑trust bundle הנכון. אם ה‑proxy אינו מורשה, עצרו וחקרו.

איתור תקלות ב‑HTTP Proxy לפי שכבות

כשלי proxy נהיים ניתנים לניהול כשבודקים שכבה אחת בכל פעם:

1. בחירת הגדרה: ודאו מאיזה מקור ה‑proxy האפליקציה הכושלת באמת משתמשת — הגדרות ידניות, הגדרות מערכת, PAC, משתני סביבה או תצורה פנימית שלה. בדקו כללי עקיפה.
2. פתרון שמות: קבעו אם הלקוח פותר את שם היעד מקומית או שולח hostname ל‑proxy לפתרון. בדקו גם את שם ה‑proxy בנפרד.
3. הגעה ב‑TCP: האם הלקוח יכול להתחבר ל‑host ולפורט של ה‑proxy? timeout בשלב הזה אינו שגיאת HTTP.
4. אימות proxy: ‏407 אומר שה‑proxy מבקש פרטי גישה. אל תבלבלו אותו עם 401 מה‑origin.
5. העברת HTTP: עבור יעד HTTP רגיל, בדקו את קוד התגובה והאם הבקשה משתמשת ב‑absolute-form הנכון.
6. מדיניות CONNECT: עבור HTTPS, ודאו שה‑proxy מאפשר את host והפורט של היעד. מנהרה שנדחתה לא מגיעה כלל לשלב TLS.
7. TLS: אחרי ש‑CONNECT מצליח, בדקו את זהות האישור, שרשרת האמון, משא ומתן הפרוטוקול, והאם צפוי interception מורשה.
8. תגובת origin: ‏403, 404 או 429 מהיעד אינם בהכרח כשל proxy — וגם אינם מתירים החלפת זהויות או עקיפת בקרות.

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

ומה לגבי Proxy Caching?

מטמון משותף שימושי, אבל הוא מותנה ולא אוטומטי. RFC 9111 מחייב cache משותף לשקול את השיטה, מפתח המטמון, הטריות, הוראות התגובה, הרשאות וכללי revalidation לפני שימוש חוזר בתגובה.

ארבע הוראות נוטות להיות מובנות לא נכון:

• private אומר ל‑shared cache לא לשמור את התגובה (או את השדות שצוינו).
• no-store אומר למטמונים לא לשמור את ההודעה, אבל ה‑RFC מבהיר שזה לא מנגנון פרטיות מלא.
• no-transform מבקש ממתווכים לא לשנות את הייצוג.
• proxy-revalidate משפיע על שימוש חוזר אחרי שתגובה מאוחסנת התיישנה; הוא לא הופך תגובה שלא ניתנת למטמון לכזו שכן.

HTTPS שממוסגר כ‑tunnel מקצה לקצה הוא אטום ל‑forwarding proxy, ולכן proxy כזה לא יכול לשמש כ‑HTTP content cache להודעות המוצפנות בתוך המנהרה. reverse proxy או gateway מורשה שמסיים TLS הוא ארכיטקטורה שונה.

HTTP Proxies, Web Scraping ו‑Thunderbit

מערכות לאיסוף נתונים עשויות להשתמש ב‑proxy עבור יציאה מבוקרת, ניתוב לפי אזור, הפרדת עומסים או זהות רשת יציבה. אלו יכולות ניתוב, לא אישורי־על. Proxy לא מעניק הרשאה לאסוף דף, לעקוף בקרות גישה, או להבטיח שהיעד יקבל את הבקשה. קודי מצב כמו 403 ו‑429, או CAPTCHA, דורשים טיפול מודע למדיניות — לא מתכון אוטומטי של “שנה סוג proxy”.

יש כאן גם בחירה של רמת הפשטה. forward proxy גולמי נותן למפתח ממשק HTTP לניתוב או tunneling. האפליקציה עדיין אחראית על fetching, rendering, parsing, אימות סכמות, retries, תצפיתיות ועמידה במדיניות.

הממשקים המתועדים של Thunderbit יושבים גבוה יותר ב‑stack. התיעוד של Thunderbit מתאר חילוץ מבוסס URL עם יכולות rendering ו‑routing, בעוד ש‑Web Scraper API מתעד שני מצבי פלט: Markdown נקי מ‑URL, או JSON מותאם לסכימה. זה יכול לצמצם את כמות תשתית ה‑crawler וה‑parsing שצוות צריך להפעיל. זה לא יוצר הצלחה אוניברסלית מול כל יעד, לא עוקף בקרות גישה, ולא מחליט אם האיסוף מורשה.

השתמשו בממשק proxy ברמה נמוכה כאשר אתם צריכים שליטה ישירה בהתנהגות התחבורה ומוכנים לקחת אחריות על שאר ה‑crawler. השתמשו בממשק חילוץ ברמה גבוהה יותר כאשר הצורך האמיתי הוא נתוני עמוד מובְנים וגבול השירות המתועד מתאים. אלו אחריות הנדסית שונה, לא שני מותגים של אותו proxy.

נקודות עיקריות

• HTTP proxy הוא מתווך להעברת הודעות, לא תכונת פרטיות או הצפנה אוטומטית.
• העברה מפורשת ב‑HTTP משתמשת ב‑absolute URI; ‏HTTPS מתחיל בדרך כלל ב‑CONNECT host:port ואז מריץ TLS דרך המנהרה.
• Proxy עם tunneling בדרך כלל לא יכול לקרוא גופי HTTP שמוגנים ב‑TLS, אבל gateway מורשה שמבצע TLS interception הוא פריסה שונה.
• Forward/reverse ו‑explicit/interception מתארים צירים נפרדים.
• HTTP proxy, ‏SOCKS5 ו‑VPN צריכים להיבחן לפי היקף התעבורה, ההגדרה, האמון ומדיניות הניתוב — לא לפי טענות כלליות על מהירות או עלות.
• אם לא קיבלתם פרטי proxy ממנהל מערכת מהימן או מאפליקציה מכוונת, השאירו את הגדרת ה‑proxy כבויה.
• באוטומציה, הגדירו שימוש ב‑proxy במפורש, הגנו על אישורים, הבינו כללי עקיפה והעדיפות, והיכשלו סגור כשה‑proxy הוא חובה.

שאלות נפוצות

האם HTTP proxy הוא אותו דבר כמו VPN?

לא. HTTP proxy מספק ממשק העברה או tunneling שמודע ל‑HTTP עבור אפליקציות שבוחרות בו. VPN יוצר מנהרת רשת ומשנה את הניתוב עבור התעבורה שנכללת במדיניות שלו. אף תווית לבדה לא מוכיחה אנונימיות, וגם split tunneling ב‑VPN אומר שהכיסוי לכל המכשיר אינו אוניברסלי.

האם HTTP proxy יכול לראות תעבורת HTTPS?

ב‑CONNECT tunnel רגיל, ה‑proxy רק מעביר בתים של TLS ואינו יכול לקרוא את תוכן ה‑HTTP המוגן. הוא עדיין יכול לראות מטא־נתונים של החיבור. אם gateway מורשה מסיים TLS באמצעות CA שהלקוח המנוהל סומך עליו, הוא יכול לבדוק את התוכן משום שהוא אחד משני קצות חיבורי TLS.

מה המשמעות של 407 Proxy Authentication Required?

ה‑proxy מאתגר את הלקוח עם דרישה לפרטי גישה ל‑proxy. זה שונה מאתגר 401 שמגיע מה‑origin. בדקו את שיטת האימות המאושרת ואת הערוץ המוגן לפני שליחת פרטי התחברות.

האם HTTP proxy מסתיר את כתובת ה‑IP שלי?

ה‑origin בדרך כלל רואה את חיבור ה‑proxy כעמית הרשת המיידי שלו, אבל זה לא יוצר אנונימיות. כותרות מועברות, אימות, עוגיות, טביעות דפדפן, התנהגות DNS ויומנים עדיין עשויים לזהות את הלקוח.

האם אני צריך proxy כדי לבצע web scraping?

לא בהכרח. התשובה תלויה ביעד המורשה, בהיקף הבקשות, בדרישות אזוריות, בארכיטקטורה ובכללי הגישה שפורסמו על ידי האתר. Proxy יכול לספק ניתוב ובקרת יציאה; הוא לא מחליף הרשאה, ויסות קצב, parsing, ניטור או טיפול בשגיאות.

למה אפליקציה אחת מתעלמת מה‑system proxy שלי?

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

למידע נוסף

• מהו Web Scraping
• AI Web Scraping
• חלופות ל‑Instant Data Scraper
• ה‑AI Web Scrapers הטובים ביותר
• Web Scraping בלי קוד