ទាមទារការចូលលើសេវា 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 កំណត់ឧទាហរណ៍នេះចំពោះការចូលក្នុងមូលដ្ឋានតែប៉ុណ្ណោះ។ សម្រាប់អតិថិជនពីចម្ងាយ សូមជ្រើសរើសអ្នកស្តាប់ និងគោលនយោបាយបណ្តាញដែលមានបំណងឱ្យច្បាស់លាស់។ អ្នកស្តាប់សាធារណៈបែប wildcard មិនជំនួសការត្រួតពិនិត្យឥរិយាបថចូលទេ។

ប្រសិនបើសេវាមួយស្នើសុំព័ត៌មានសម្គាល់ ហើយមួយទៀតមិនស្នើសុំ សូមពិនិត្យការកំណត់មុនពាក្យបញ្ជាសេវានីមួយៗ ច្បាប់ក្រោយ flush ណាមួយ និងឃ្លាំងសម្ងាត់ផ្ទៀងផ្ទាត់។ ការផ្លាស់ប្តូរពាក្យសម្ងាត់មិនអាចជួសជុលសេវាដែលបានចាប់ផ្តើមក្រោមគោលនយោបាយខុសបានទេ។ ដូចគ្នាដែរ ការផ្លាស់ប្តូរគណនីប្រព័ន្ធប្រតិបត្តិការរបស់ daemon មិនបង្កើតអ្នកប្រើប្រូកស៊ីទេ។