כיצד פורט פרוקסי אחד יכול לקבל גם HTTP וגם SOCKS
מסביר כיצד מאזין מעורב במכוון יכול להבחין בין HTTP ל-SOCKS, בעוד שמאזין רגיל של פרוטוקול אחד אינו יכול.
מאזין פרוקסי מעורב יכול לקבל HTTP ו-SOCKS על פורט TCP אחד מפני שהשרת בודק את בייטי הפרוטוקול הראשוניים. מספר הפורט אינו מבצע את הזיהוי הזה.
בקשת פרוקסי HTTP מתחילה בשיטת HTTP, כגון GET או CONNECT. ברכת SOCKS מתחילה בשדות פרוטוקול בינאריים. תוכנה שתוכננה לקלטים אלה יכולה להעביר את החיבור למטפל המתאים.
זהו מאפיין מימוש מפורש. מאזין HTTP רגיל של Squid אינו הופך למעורב מפני שהפורט שלו שונה ל-1080, ומאזין SOCKS בלבד אינו לומד HTTP מהגדרה של דפדפן.
TLS מוסיף גבול נוסף: חיבור פרוקסי מוצפן מתחיל ב-TLS, ולא בשיטת HTTP גלויה. תמיכה בו באותה נקודת קצה דורשת טיפול מכוון נוסף; זיהוי HTTP בטקסט גלוי ו-SOCKS אינו מבסס את היכולת הזו.
השתמשו בפרוטוקול הלקוח המתועד עבור נקודת הקצה. אם שניהם עובדים, זו ראיה לגבי המאזין המעורב של אותו שרת, ולא סיבה להשאיר את הפרוטוקול לא מוגדר בכל לקוח.
המאזין המעורב של Glider מספק דוגמה קונקרטית: הוא מציץ בבייט אחד בלי לצרוך אותו, שולח 0x05 למטפל ה-SOCKS5 שלו, ואחרת קורא למנתח ה-HTTP שלו. המנתח הזה עדיין מאמת את הבקשה הנכנסת; בחירת השליחה אינה הופכת קלט שרירותי ל-HTTP תקף.
שיתוף מאזין ה-TCP אינו מספק כשלעצמו שיוך UDP של SOCKS5. Glider מפעיל את מאזין ה-UDP שלו בנפרד. בחירת פרוטוקול TCP והעברת הדאטהגרם המאוחרת הן יכולות נפרדות.