ភ្ជាប់អតិថិជន SOCKS ទៅមេ HTTP CONNECT ដោយប្រើ 3proxy

កម្មវិធីត្រូវការ SOCKS។ សេវាផ្នែកខាងលើដែលបានអនុម័តរបស់អ្នកទទួលយក HTTP CONNECT។ ការដាក់ចំណុចបញ្ចប់ HTTP ក្នុងវាល SOCKS របស់កម្មវិធីមិនបកប្រែរវាងពិធីការទាំងពីរទេ។

ច្រកទ្វារអាចទទួល SOCKS ពីកម្មវិធី អានគោលដៅដែលបានស្នើ ហើយស្នើសុំពីមេ HTTP នូវផ្លូវរូង CONNECT ទៅគោលដៅនោះ។ បន្ទាប់មកវាបញ្ជូនលំហូររបស់កម្មវិធីតាមផ្លូវរូង។

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

ធ្វើឱ្យចំណុចប្រទាក់នីមួយៗច្បាស់លាស់

សម្រាប់ច្រកទ្វារដែលគាំទ្រការរៀបចំនេះ ប្រភេទមេរបស់វាមានសារៈសំខាន់។ ឯកសារ 3proxy បែងចែកមេ connect ពីមេដែលប្រើជាប្រូកស៊ីបញ្ជូន HTTP ធម្មតា។

ជាមួយអ្នកប្រើ 3proxy និងការផ្ទៀងផ្ទាត់ដែលមានស្រាប់ បំណែកផ្លូវក្នុងស្រុកតែមួយអាចមានទម្រង់នេះ៖

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

បំណែកនេះសន្មតថាគណនីត្រូវបានកំណត់រួចហើយ។ វាមិនបន្ថែមព័ត៌មានសម្គាល់ណាមួយដែលមេ HTTP ខ្លួនឯងត្រូវការទេ ហើយមិនជំនួសគោលនយោបាយចូលប្រើដែលមានស្រាប់ឡើយ។ សម្រាប់គោលដៅសាធារណៈលើផ្លូវដែលអនុញ្ញាតមេ HTTP សាធារណៈដោយគ្មានការផ្ទៀងផ្ទាត់ បញ្ជីប្រូកស៊ី HTTP ផ្តល់បេក្ខជនម៉ាស៊ីន និងច្រក។ ទុកព័ត៌មានសម្គាល់មេឱ្យអវត្តមានសម្រាប់សាខានោះ ហើយបញ្ជាក់ការអនុញ្ញាតសម្រាប់គោលដៅពិត។ គណនីរបស់ច្រកទ្វារខ្លួនឯងនៅតែក្នុងស្រុក។ ច្បាប់ parent ត្រូវបានភ្ជាប់ជាមួយច្បាប់ allow មុនតាមគំរូកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រងរបស់ 3proxy។

កម្មវិធីប្រើចំណុចបញ្ចប់ SOCKS ក្នុងស្រុក។ ច្រកទ្វារប្រើ HTTP CONNECT ឆ្ពោះទៅមេ។ មេនៅតែសម្រេចថាតើម៉ាស៊ីន និងច្រកគោលដៅដែលបានស្នើត្រូវបានអនុញ្ញាតឬអត់។

វិសាលភាពមានប្រយោជន៍នៅទីនេះគឺការដាក់ផ្លូវរូងលំហូរ TCP ធម្មតា។ ការភ្ជាប់ UDP របស់ SOCKS5 មិនក្លាយជាគាំទ្រដោយសារតែអ្នកស្តាប់ខាងមុខទទួល SOCKS5 នោះទេ។ មេ HTTP CONNECT មិនផ្តល់ការបញ្ជូន UDP ដែលត្រូវការដោយស្វ័យប្រវត្តិទេ។

HTTPS អាចនៅតែពីចុងដល់ចុងក្នុងផ្លូវនេះ។ ការបកប្រែរវាងចំណុចប្រទាក់ប្រូកស៊ីមិនត្រូវការធ្វើត្រាប់តាមគេហទំព័រគោលដៅទេ។ ការផ្ទៀងផ្ទាត់ទៅច្រកទ្វារ ទៅមេ និងទៅគេហទំព័រ នៅតែជាព័ត៌មានសម្គាល់ និងការផ្លាស់ប្តូរផ្សេងគ្នា។