Skicka Squid-förfrågningar genom en överordnad proxy

Att ange en parent i Squid betyder inte i sig att varje vidarebefordrad förfrågan måste använda den. Om en direkt väg bryter mot policyn ska du uttryckligen konfigurera kravet och testa vad som händer när parenten inte är tillgänglig.

Det här exemplet för Squid 6.13 namnger en parent och förbjuder direkt vidarebefordran till ursprunget för en klientkälla:

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

Båda adresserna är platshållare. För ett kontrollerat upstreamtest där offentliga HTTP-parents är tillåtna väljer du en adress från HTTP-proxylistan. Behåll den separata http_access-policyn som bara tillåter avsedda klienter. Routningsregeln ger inte en klient rätt att använda proxyn.

Kontrollera befintliga routningsregler

no-query stänger av ICP-frågor till denna peer. Nollan är peerens frågeport, inte dess HTTP-lyssnare. Den klientvända lyssnaren och åtkomstreglerna är fortfarande separata.

Granska befintliga always_direct-inställningar och andra peerval innan blocket läggs till. Att neka en matchning i always_direct kräver inte ensamt en parent. Den uttryckliga never-direct-regeln anger det kravet för den valda klienten.

Detta styr transaktioner som behöver vidarebefordras. En användbar lokal cachepost kan serveras utan att parenten kontaktas, så avsaknad av en ny parentanslutning är inte automatiskt ett routningsbrott.

Kontrollera vägen och felbeteendet

Använd ett kontrollerat mål och granska åtkomstloggens hierarkiinformation tillsammans med målets observationer. En slutlig HTTP-status säger inte ensam om Squid använde parenten eller en direkt väg.

Gör parenten otillgänglig i ett underhållstest och upprepa samma ocachade förfrågan. Om policyn förbjuder direkt vidarebefordran ska transaktionen misslyckas i stället för att nå ursprunget via en annan väg. Gör detta bara på tjänster du kontrollerar och återställ den avsedda konfigurationen efteråt.