Squid sorğularını üst proksi vasitəsilə göndərin

Squid-də üst proksi elan etmək öz-özünə hər yönləndirilən sorğunun ondan istifadə etməli olduğu demək deyil. Birbaşa yol siyasəti pozursa, bu tələbi açıq qurun və üst proksi əlçatmaz olanda davranışı sınayın.

Squid 6.13 üçün bu nümunə bir üst proksi adlandırır və bir müştəri mənbəyinin origin-ə birbaşa yönləndirilməsini qadağan edir:

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

Hər iki ünvan yer tutucudur. Açıq HTTP üst proksilərə icazə verilən nəzarətli upstream sınağı üçün HTTP proksi siyahısından ünvan seçin. Yalnız nəzərdə tutulan müştəriləri buraxan ayrı http_access siyasətini saxlayın. Marşrut qaydası müştəriyə proksidən istifadə səlahiyyəti vermir.

Mövcud marşrut qaydalarını yoxlayın

no-query bu peer-ə ICP sorğularını söndürür. Sıfır peer-in sorğu portudur, onun HTTP dinləyicisi deyil. Müştəriyə baxan dinləyici və giriş qaydaları ayrı qalır.

Bloku əlavə etməzdən əvvəl mövcud always_direct parametrlərini və başqa peer seçimlərini nəzərdən keçirin. always_direct içində uyğunluğu rədd etmək öz-özünə üst proksi tələb etmir. Açıq never-direct qaydası seçilmiş müştəri üçün bu tələbi bildirir.

Bu, yönləndirmə tələb edən əməliyyatları idarə edir. Yararlı yerli keş qeydi üst proksi ilə əlaqə olmadan verilə bilər; buna görə yeni üst proksi bağlantısının olmaması avtomatik marşrut pozuntusu deyil.

Yolu və xəta davranışını yoxlayın

Nəzarət olunan təyinat istifadə edin və giriş jurnalının iyerarxiya məlumatını təyinat müşahidələri ilə tutuşdurun. Tək yekun HTTP statusu Squid-in üst proksi, yoxsa birbaşa yol işlətdiyini demir.

Texniki xidmət sınağında üst proksini əlçatmaz edib eyni keşlənməmiş sorğunu təkrarlayın. Siyasət birbaşa yönləndirməni qadağan edirsə, əməliyyat başqa yolla origin-ə çatmaq əvəzinə uğursuz olmalıdır. Bunu yalnız nəzarətinizdə olan xidmətlərdə edin və sonra nəzərdə tutulan konfiqurasiyanı bərpa edin.