Squid сұрауларын жоғары прокси арқылы жіберу

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

Екі мекенжай да орынбасар. Ашық HTTP жоғары проксилер рұқсат етілген бақыланатын upstream сынағына HTTP прокси тізімінен мекенжай таңдаңыз. Тек жоспарланған клиенттерді өткізетін бөлек http_access саясатын сақтаңыз. Бағыттау ережесі клиентке прокси қолдану құқығын бермейді.

Бар бағыттау ережелерін тексеріңіз

no-query осы peer-ге ICP сұрауларын өшіреді. Нөл peer-дің сұрау порты, HTTP тыңдаушысы емес. Клиентке қараған тыңдаушы мен кіру ережелері бөлек қалады.

Блокты қоспас бұрын бар always_direct баптауларын және өзге peer таңдауларын қараңыз. always_direct ішінде сәйкестікті қабылдамау өздігінен жоғары прокси талап етпейді. Айқын never-direct ережесі таңдалған клиентке осы талапты көрсетеді.

Бұл беруді қажет ететін транзакцияларды басқарады. Жарамды жергілікті кэш жазбасын жоғары проксиге хабарласпай беруге болады; жаңа жоғары прокси қосылымының жоқтығы автоматты бағыттау бұзылысы емес.

Жолды және сәтсіздік әрекетін тексеріңіз

Бақыланатын мақсатты қолданып, кіру журналының иерархия деректерін мақсат бақылауымен салыстырыңыз. Тек соңғы HTTP күйі Squid жоғары проксиді ме, тікелей жолды ма қолданғанын айтпайды.

Қызмет көрсету сынағында жоғары проксиді қолжетімсіз етіп, сол кэштелмеген сұрауды қайталаңыз. Саясат тікелей беруге тыйым салса, транзакция басқа жолмен бастапқы серверге жетпей, сәтсіз аяқталуы керек. Мұны тек өзіңіз басқаратын қызметте істеп, соңынан қажетті конфигурацияны қалпына келтіріңіз.