مقصدهای اصلی در ارسال شفاف TCP به SOCKS
توضیح می‌دهد چرا ارسال شفاف TCP به SOCKS به مترجمی نیاز دارد که مقصد اصلی را پیش از مذاکره با پروکسی بازیابی کند.
یک دیوار آتش می‌تواند تغییر دهد که یک اتصال TCP کجا فرود آید. اما تنها با آن تغییر نمی‌تواند به برنامه مبدأ بیاموزد که به SOCKS سخن بگوید.
یک سرور SOCKS معمولی انتظار مذاکره‌ای را دارد که مقصد درخواستی را توصیف کند. برنامه‌ای که از پروکسی بی‌خبر است در عوض بی‌درنگ بایت‌های پروتکل خودش را می‌فرستد. اگر آن بایت‌ها را مستقیم به یک شنونده SOCKS هدایت کنید، دو طرف درباره نخستین پیام با هم اختلاف پیدا می‌کنند.
قطعه گمشده یک مترجم است
یک قطعه شفاف TCP به پروکسی میان این واسط‌ها می‌نشیند. مقصدی را که برنامه در ابتدا درخواست کرده بود کشف می‌کند، نشست مناسب SOCKS یا HTTP CONNECT را برقرار می‌سازد و سپس داده‌های برنامه را روی جریان حاصل بازپخش می‌کند.
در مسیر Linux iptables، کد منبع redsocks مقصد حفظ‌شده را با SO_ORIGINAL_DST بازیابی می‌کند. سیستم‌عامل‌ها و روش‌های هدایت دیگر سازوکارهای متفاوتی به کار می‌برند. این ویژگی هدایت‌کننده و پیکربندی شبکه است، نه قابلیتی معمول در کارخواه SOCKS.
اطلاعات مقصد اصلی همچنین توضیح می‌دهد که چرا جابه‌جا کردن یک قاعده هدایت از میزبان پروکسی به درگاهی نامرتبط همیشه هم‌ارز نیست. فرایند گیرنده به فراداده‌ای نیاز دارد که شیوه رهگیری آن می‌طلبد. نشانی‌ای که جای دیگری بازنویسی شده ممکن است دیگر آن اطلاعات را به شکل مورد انتظار فراهم نکند.
دامنه مترجم را روشن نگه دارید. یک اتصال TCP هدایت‌شده کارآمد اثبات پشتیبانی از UDP دلخواه، ICMP یا هر مسیر حل‌کننده نیست. پروتکل پروکسی بالادست و پیاده‌سازی مترجم همچنان عملیات پشتیبانی‌شده را تعیین می‌کنند.
وقتی پیکربندی بلافاصله پس از اتصال شکست می‌خورد، پیش از گستردن قواعد دسترسی مرز پروتکل را بررسی کنید. یک شنونده SOCKS کاملاً در دسترس می‌تواند بایت‌هایی را رد کند که هرگز درخواست SOCKS نبوده‌اند.