קריאת קודי כשל בחיבור SOCKS5
זהו אם נכשלו משא ומתן SOCKS, אימות או גישה ליעד לפני שמפרשים כל שגיאת SOCKS כפרוקסי מושבת.
שרת SOCKS5 יכול לקבל חיבור TCP ועדיין לדחות בקשת גישה ליעד. קראו את התשובה בשלב הנכון לפני שתכריעו איזו נקודת קצה נכשלה.
תחילה נבחרת שיטה. לאימות בשם משתמש וסיסמה, אם נבחר, יש תוצאה משלו. רק לאחר מכן השרת מחזיר תשובה ל־CONNECT או לפקודת SOCKS אחרת. אי אפשר לפרש ערך בית משלב אחד בעזרת טבלה של שלב אחר.
תשובות לבקשות מבדילות בין כשלים
| ערך תשובה | משמעות בתשובה לבקשת SOCKS5 |
|---|---|
| 0x01 | כשל שרת כללי. |
| 0x02 | החיבור אינו מותר לפי מערכת הכללים. |
| 0x03 | אין גישה לרשת. |
| 0x04 | אין גישה למארח. |
| 0x05 | החיבור נדחה. |
| 0x06 | TTL פג. |
| 0x07 | הפקודה אינה נתמכת. |
| 0x08 | סוג הכתובת אינו נתמך. |
לדוגמה, סירוב ברמת הבקשה מדווח לאחר ההגעה לשירות SOCKS. זה שונה ממערכת הפעלה שמסרבת לחיבור TCP הראשוני לשירות הזה.
שגיאת סוג כתובת עשויה לגעת לייצוג IPv4, IPv6 או שם מארח. אין פירושה אוטומטית שנקודת הקצה כולה אינה תומכת ב־SOCKS5. בדומה לכך, פקודת UDP שאינה נתמכת אינה מספקת מסקנה נחרצת על בקשת TCP CONNECT נפרדת.
אספו את ההקשר שהופך את הקוד לשימושי
בעת כתיבת דוח שגיאה, שמרו עם התוצאה את כתובת הפרוקסי, הפקודה, מארח היעד והפורט, משפחת הכתובות ומצב DNS. אם אתם מנהלים את נקודת הקצה, יומני המדיניות בשרת מועילים. דחייה לפי כללים מצריכה בדיקת ההרשאה החלה, ולא הארכת זמן ההמתנה לחיבור.
התשובה היא דיווח השרת, לא אבחון עצמאי מלא של רשת היעד. גם נוסח הלקוחות משתנה. תעדו את השלב ואת התשובה המקורית כשאפשר במקום להסתמך רק על הודעת שגיאה קצרה ומתורגמת.