Send Squid Requests Through a Parent Proxy

Declaring a parent in Squid does not by itself mean that every forwarded request must use it. If a direct route would violate your policy, configure that requirement explicitly and test what happens when the parent is unavailable.

For Squid 6.13, this example names one parent and forbids direct origin forwarding for one client source:

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

Both addresses are placeholders. For a controlled upstream test where public HTTP parents are permitted, choose an address from the HTTP proxy list. Keep the separate http_access policy that permits only your intended clients. The routing rule does not authorize a client to use the proxy.

Check the existing routing rules

no-query disables ICP queries to this peer. The zero is the peer's query port, not its HTTP listener. The client-facing listener and its access rules remain separate.

Review existing always_direct settings and other peer selections before adding this block. Denying a match in always_direct does not, on its own, require a parent. The explicit never-direct rule expresses that requirement for the selected client.

This governs transactions that need forwarding. A usable local cache entry can be served without contacting the parent, so the absence of a new parent connection is not automatically a routing violation.

Check the route and its failure behavior

Use a controlled destination and inspect the access log's hierarchy information alongside the destination's observations. A final HTTP status alone does not tell you whether Squid used the parent or a direct route.

In a maintenance test, make the parent unavailable and repeat the same uncached request. If policy forbids direct forwarding, the transaction should fail rather than reach the origin through another route. Perform this only on services you control, and restore the intended configuration afterward.