לדרוש התחברות בשני שירותי ה-HTTP וה-SOCKS של 3proxy

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

דוגמה מקומית בלבד לשני שירותים:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

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

הלקוח זקוק לחילופי ההתחברות הנכונים

שירות ה-HTTP מצפה לאימות פרוקסי HTTP. שירות ה-SOCKS זקוק ללקוח שתומך באימות SOCKS5 בשם משתמש ובסיסמה. לקוח SOCKS4 אינו יכול לספק את החילוף הזה רק מפני שהוא מגיע לאותו פורט האזנה.

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

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

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