HTTP או SOCKS5: איזו כתובת IP של פרוקסי לבחור?
בחרו סוג פרוקסי לפי היישום, התעבורה הנתמכת והצורך ב־DNS בצד הפרוקסי.
פתחו תחילה את הגדרות הפרוקסי של היישום. הפרוטוקולים הנתמכים קובעים אילו רשומות אפשר להשתמש בהן; תווית מרשימה או מספר יציאה מוכר לא מוסיפים תמיכה ללקוח.
| היישום או המשימה | בחירה ובדיקה |
|---|---|
| מציע רק שדה פרוקסי HTTP | נקודת קצה מתאימה מרשימת שרתי פרוקסי HTTP. בדקו גם HTTPS CONNECT אם נדרשים יעדי HTTPS. |
| תומך ב־SOCKS5 וצריך אפשרויות חיבור או DNS | נקודת SOCKS5 שהאפשרויות הנדרשות נתמכות בה בשני הצדדים. |
| צריך UDP | בדקו תמיכת UDP בלקוח ובנקודת הקצה; תווית SOCKS5 לבדה אינה מספיקה. |
| דורש SOCKS4 | נקודת SOCKS4 תואמת ומצב לקוח מתאים. |
| אינו תומך בפרוקסי | IP מרשימה לא מגדיר לבדו את היישום. |
לבקשות אינטרנט ו־API, פרוקסי HTTP מספיק לעיתים קרובות. הוא מעביר HTTP וכשמותר נושא HTTPS דרך CONNECT. הצלחת דף HTTP רגיל לא מוכיחה תמיכה במנהרה: השירות עשוי לדרוש אימות למנהרה או להגביל יעדים ויציאות.
SOCKS פועל מתחת לשכבת בקשות HTTP. יישום תואם מבקש ממנו ליצור חיבור בלי לפרש בקשת HTTP, ולכן הוא שימושי גם לתעבורה נתמכת אחרת. SOCKS5 מגדיר כתובות IPv4, IPv6 ושמות מתחם, אימות ושיוך UDP. יישום מסוים או נקודת קצה חינמית עשויים לממש רק חלק מהיכולות. נתיב TCP SOCKS של דפדפן לא מכסה אוטומטית יישום אחר או שירות UDP.
היכן נפתר שם היעד?
ב־curl, כתיב כתובת SOCKS5 קובע היכן מתבצע DNS של היעד: socks5:// פותר מקומית; socks5h:// מבקש מהפרוקסי לפתור. תצוגות DNS שונות יכולות לגרום לבחירה אחת לעבוד ולאחרת להיכשל. לקוחות אחרים עשויים להשתמש בתיבת סימון או באפשרות נפרדת. בחירת SOCKS5 לבדה לא מוכיחה שכל שאילתת DNS עוברת דרכו.
SOCKS4 מציע פחות יכולות; SOCKS4a מוסיף טיפול בשמות מארח. אם הלקוח והשירות תומכים ב־SOCKS5 ואין סיבה לפרוטוקול הישן, רשומת SOCKS5 מתאימה היא בחירה ראשונה סבירה. הזנת נקודת SOCKS4 כשהלקוח במצב SOCKS5 היא אי־התאמה בפרוטוקול.
לאחר התאמת הפרוטוקול, בדקו את היעד בפועל וזהו את הכשל הראשון. HTTP ו־SOCKS5 אינם מדדי אנונימיות: האמון במפעיל, TLS של היעד והנתיב האמיתי של היישום עדיין קובעים את ההגנה.