Wajibkan Log Masuk pada Kedua-dua Perkhidmatan HTTP dan SOCKS 3proxy

Mentakrifkan pengguna bukanlah keseluruhan konfigurasi log masuk 3proxy. Perkhidmatan juga memerlukan kaedah pengesahan dan peraturan akses yang menggunakannya. Urutan penting kerana tetapan perkhidmatan digunakan semasa konfigurasi diproses.

Contoh khusus tempatan untuk dua perkhidmatan:

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

Rujukan konfigurasi menerangkan users, auth strong dan arahan perkhidmatan. CL menyimpan kata laluan contoh ini sebagai teks biasa. Lindungi fail dan pilih bentuk penyimpanan kelayakan yang disokong dan sesuai untuk penggunaan.

Klien memerlukan pertukaran log masuk yang betul

Perkhidmatan HTTP menjangka pengesahan proksi HTTP. Perkhidmatan SOCKS memerlukan klien yang menyokong pengesahan SOCKS5 dengan nama pengguna dan kata laluan. Klien SOCKS4 tidak boleh menyediakan pertukaran itu semata-mata kerana ia mencapai port pendengar yang sama.

Perkataan strong ialah nama mod pengesahan, bukan jaminan pengangkutan yang disulitkan. Lindungi bahagian daripada klien ke proksi apabila perlu. HTTPS ke destinasi dan penyulitan ke proksi kekal sebagai keputusan berasingan.

Ikatan loopback mengehadkan contoh ini kepada akses tempatan. Untuk klien jauh, pilih pendengar dan dasar rangkaian yang dimaksudkan secara jelas. Pendengar awam dengan kad liar bukan pengganti pemeriksaan tingkah laku log masuk.

Jika satu perkhidmatan meminta kelayakan dan yang lain tidak, periksa tetapan sebelum setiap arahan perkhidmatan, peraturan selepas mana-mana flush dan cache pengesahan. Menukar kata laluan tidak boleh membaiki perkhidmatan yang dimulakan di bawah dasar yang salah. Begitu juga, menukar akaun sistem pengendalian daemon tidak mencipta pengguna proksi.