چگونه یک پورت پروکسی می‌تواند هم 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 و بازپخش بعدی دیتاگرام دو توانایی جداگانه‌اند.