Combine Squid myportname and src with Separate ACLs
Combine a named Squid listener with an allowed client network without putting two ACL types on the same definition.
The configuration looks plausible at a glance:
acl team_a myportname 3128 src 198.51.100.0/24
But an ACL definition has one type. Here, myportname is the type; adding the word src does not start a second test. The remaining words belong to the value list for the first type. That line does not express “this listener and this client network.”
Give each condition a name
Use a name for the listening socket and a separate source ACL. This excerpt uses documentation addresses, which must be replaced with addresses appropriate to the deployment:
http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24
http_access allow team_a_port team_a_clients
http_access deny all
Place the allow rule after the existing protections for unsafe destination ports, restricted CONNECT targets and management access. The excerpt illustrates the client/listener condition; it does not replace those protections.
Conditions on one http_access line are combined with AND. Two separate allow lines would admit either condition independently, which would change the policy considerably. Several values within one ACL normally provide alternatives for that single test.
Choose the exit separately
A matching listener can also be used by tcp_outgoing_address to choose a local source address. That is routing selection, not permission to use the proxy. An outgoing-address rule cannot make a denied request pass http_access.
If a multi-address configuration stops working after an upgrade, separate the evidence: a parse error points to configuration syntax; an access denial points to rule matching; a permitted request with the wrong exit points to outgoing selection or later NAT. Changing all three at once makes a small ACL mistake much harder to find.