Squid PROXY Protocol: Trust the Sender Before HTTP Access Checks

Use proxy_protocol_access to trust the relay supplying metadata, not to select allowed websites. In Squid 5–7, the check runs once after TCP setup on a require-proxy-header listener, before HTTP request headers are processed:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

Replace the example relay address and restrict network access to this listener. At this stage, Squid checks the actual TCP peer before accepting the supplied metadata. After acceptance, it uses the asserted client address for subsequent ACL checks and logging. Trusting a relay based on the client address it claims would reverse that order.

Keep http_access for the later client-source and destination permissions. Accepting metadata does not authorize website access, and a destination-domain ACL cannot answer the earlier sender-trust question.

Sender and receiver must agree on a supported PROXY-protocol version. A plain HTTP client cannot use this required-prefix listener as an ordinary proxy endpoint. If both forms are needed, use deliberately separate endpoints rather than duplicating the same listening address and port.

A trusted relay can influence address-based authorization through the client identity it supplies. Grant that ability only to the intended intermediary.