ការប្រកាសប្រូកស៊ីមេក្នុង Squid តែប៉ុណ្ណោះមិនមានន័យថាគ្រប់សំណើបញ្ជូនបន្តត្រូវប្រើវាទេ។ បើផ្លូវផ្ទាល់រំលោភគោលការណ៍ សូមកំណត់តម្រូវការនោះច្បាស់ និងសាកល្បងពេលប្រូកស៊ីមេមិនអាចប្រើបាន។

សម្រាប់ Squid 6.13 ឧទាហរណ៍នេះដាក់ឈ្មោះប្រូកស៊ីមេមួយ ហើយហាមបញ្ជូនផ្ទាល់ទៅប្រភពសម្រាប់ប្រភពម៉ាស៊ីនភ្ញៀវមួយ៖

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

អាសយដ្ឋានទាំងពីរជាតម្លៃគំរូ។ សម្រាប់ការតេស្ត upstream គ្រប់គ្រងដែលអនុញ្ញាត HTTP ប្រូកស៊ីមេសាធារណៈ សូមជ្រើសពីបញ្ជី HTTP ប្រូកស៊ី។ រក្សាគោលការណ៍ http_access ដាច់ដោយឡែកដែលទទួលតែម៉ាស៊ីនភ្ញៀវចង់បាន។ ច្បាប់កំណត់ផ្លូវមិនផ្តល់សិទ្ធិប្រើប្រូកស៊ីឱ្យម៉ាស៊ីនភ្ញៀវទេ។

ពិនិត្យច្បាប់កំណត់ផ្លូវដែលមានស្រាប់

no-query បិទសំណួរ ICP ទៅ peer នេះ។ សូន្យជាច្រកសំណួររបស់ peer មិនមែនចំណុចទទួល HTTP ទេ។ ចំណុចទទួលខាងម៉ាស៊ីនភ្ញៀវ និងច្បាប់ចូលរបស់វានៅដាច់ដោយឡែក។

ពិនិត្យការកំណត់ always_direct ដែលមាន និងការជ្រើស peer ផ្សេងមុនបន្ថែមប្លុក។ ការបដិសេធការត្រូវគ្នាក្នុង always_direct មិនបង្ខំប្រូកស៊ីមេដោយខ្លួនឯងទេ។ ច្បាប់ never-direct ច្បាស់បង្ហាញតម្រូវការនេះសម្រាប់ម៉ាស៊ីនភ្ញៀវដែលជ្រើស។

វាគ្រប់គ្រងប្រតិបត្តិការដែលត្រូវបញ្ជូនបន្ត។ ធាតុ cache មូលដ្ឋានប្រើបានអាចផ្តល់ដោយមិនទាក់ទងប្រូកស៊ីមេ ដូច្នេះគ្មានការតភ្ជាប់ថ្មីទៅប្រូកស៊ីមេមិនមែនរំលោភផ្លូវដោយស្វ័យប្រវត្តិទេ។

ពិនិត្យផ្លូវ និងឥរិយាបថបរាជ័យ

ប្រើគោលដៅដែលគ្រប់គ្រង និងប្រៀបធៀបព័ត៌មានឋានានុក្រមក្នុងកំណត់ហេតុចូលជាមួយការសង្កេតគោលដៅ។ ស្ថានភាព HTTP ចុងក្រោយតែឯងមិនប្រាប់ថា Squid ប្រើប្រូកស៊ីមេ ឬផ្លូវផ្ទាល់ទេ។

ក្នុងការតេស្តថែទាំ ធ្វើឱ្យប្រូកស៊ីមេមិនអាចប្រើបាន ហើយស្នើសំណើដដែលដែលគ្មានក្នុង cache ឡើងវិញ។ បើគោលការណ៍ហាមបញ្ជូនផ្ទាល់ ប្រតិបត្តិការគួរបរាជ័យ ជំនួសទៅប្រភពតាមផ្លូវផ្សេង។ ធ្វើតែលើសេវាដែលអ្នកគ្រប់គ្រង ហើយស្តារការកំណត់ចង់បានក្រោយមក។

អត្ថបទពាក់ព័ន្ធ