الزام ورود در هر دو سرویس 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 و حافظه نهان احراز هویت را بررسی کنید. تغییر گذرواژه نمی‌تواند سرویسی را که با سیاست نادرست آغاز شده ترمیم کند. به همین ترتیب، تغییر حساب سیستم‌عامل دیمن کاربر پراکسی ایجاد نمی‌کند.