Շարունակվող մուտքային հարցումները չեն ապացուցում, որ դրսի մարդիկ դեռ կարող են օգտվել պրոքսիից։ Հին վերջնակետերը կարող են մնալ հարցումների ցանկերում հասանելիության քաղաքականությունը փոխելուց հետո։ Ստուգեք վերանորոգումը ըստ այն բանի, թե ինչ է փոխանցվում.

  1. Կատարեք թույլատրված և չթույլատրված հարցումներ վերահսկվող նպատակակետին։
  2. Կարդացեք հասանելիության որոշումը և Squid-ի համար հիերարխիայի դաշտերը կարգավորված մատյանի ձևաչափով։
  3. Որոշեք՝ արգելված հարցումն իսկապես հասե՞լ է նպատակակետին։ TCP ընդունելը, HTTP հարցումը մերժելը և հաջորդ հարցումն ավարտելը տարբեր արդյունքներ են։
  4. Ստուգեք մյուս ակտիվ լսողներին և վիրտուալ հոսթերը, որպեսզի վերանորոգված քաղաքականության բլոկը այլ մուտք բաց չթողնի։

Միայն հակադարձ քարտեզագրմանը սպասարկող Apache-ի համար հաստատեք, որ ակամա ուղիղ պրոքսինգն անջատված է։ ProxyRequests Off-ը կարող է գոյակցել ProxyPass-ի հետ։

Միայն սխալի էջը ավելի թույլ ապացույց է, եթե չգիտեք, թե որ բաղադրիչն է այն ստեղծել։ Գործակալի արդյունքը, պրոքսիի որոշումը և նպատակակետում կատարված դիտարկումը պահեք միասին։

Եթե մերժված տրաֆիկը դեռ սպառում է ռեսուրսներ, նեղացրեք ցանցային հասանելիությունը և կառավարեք արագությունները և մատյանների պահպանումը։ Չկա հուսալի սպասման ժամանակ, որից հետո փորձերը պետք է դադարեն. ճիշտ փոխանցման որոշումներն են ընդունման չափանիշը։

Առնչվող հոդվածներ